Bhoomit Ganatra’s Post

I just published my first npm package called Arc. It is a web framework for Node.js that I built from the ground up using TypeScript. Instead of just using Express, I wanted to see if I could build the whole engine myself using only the native http module and zero external dependencies. I spent a lot of time on the core logic writing a router that uses regex to handle dynamic paths like /user/:id and setting up a recursive next function so middlewares run in the right order. Since I wanted it to be a complete tool, I also built my own custom parsers for JSON, URL encoded data, and cookies. It also has built in logic for JWT auth, CORS, rate limiting, and a static file server. Building this taught me way more about how a backend actually handles data flow than just using a pre made library ever did. I am still adding to it. My next plans are to include request validation, dependency injection, and cluster support to make it even faster. If you are into low level Node.js or want to help build out the engine, you are more than welcome to contribute. If you want to see how the guts of a framework actually work, check out the code or try it out: NPM: https://lnkd.in/dPkTEjYZ GitHub: https://lnkd.in/dfmwM_Cb #NodeJS #TypeScript #OpenSource #Backend #Coding

Node.js is single-threaded. So why doesn’t your server freeze with 10,000 requests? This confused me for months — until I understood the event loop. Here’s the mental model that made it click The 4 pieces you need to understand 1. JS Engine (e.g. V8) Executes your JavaScript by parsing → compiling → running it, while managing memory (heap) and execution flow (call stack) 2. Call Stack A single-threaded execution stack where synchronous code runs one function at a time — if it’s occupied by heavy work, nothing else (including callbacks) can run 3. Web APIs / Node APIs (libuv) Background system that takes over async operations (timers, file system, network, DB), so the JS engine doesn’t block while waiting 4. Queues Hold ready callbacks — microtasks (Promises) are processed immediately after current execution, while task queue (timers/I/O) runs only when the stack is free 🔁 The rule everything follows 1. Run all synchronous code (call stack) 2. Execute ALL microtasks (Promises) 3. Execute ONE task (timers, I/O) 4. Repeat 🍽️ Mental model Node is a single chef Takes orders (requests) Hands off long work (async APIs) Keeps working instead of waiting Comes back when tasks are ready ⚠️ If the chef is stuck → everything stops #nodejs #javascript #nestjs #backend #softwareengineering

You write some JavaScript on the server side maybe a loop or some heavy processing. It works fine locally, no issues. You ship it to production and suddenly your senior calls saying the application feels laggy, slow, and sometimes even unresponsive. Why? Because that “small” piece of CPU-heavy code is running on the same main thread as your entire application. While it’s executing, the event loop can’t move forward no new requests, no timers, no completed I/O callbacks. Everything waits. Node.js didn’t suddenly become slow your code blocked the system that was supposed to keep things moving. But wait… Node.js is non-blocking, right? Yes, for I/O, not for CPU-bound tasks. I wrote a detailed blog breaking this down - how Node.js actually works, the event loop, execution order, and where things go wrong. Give it a read. https://lnkd.in/g6BXX_qQ #nodejs #eventloop #javascript #libuv

Following a discussion yesterday on the Frankenstein pattern. This is how I’ve been approaching it in practice. Develop your features outside your system as a self-contained environment , easy to work with, easy to reason about. Embed them back in with risks contained and testability less complex. This approach was initially built for PHP-based systems. Systems where adding a feature often means navigating templates, plugins, observers, and side effects. But something interesting happens when the feature is truly isolated. The same feature can be compiled differently. - As an embeddable bundle for PHP platforms - As a native component for modern environments like Next.js Same logic. Same behaviour. Different packaging. You are no longer building for a system. You are building around it. A concrete setup can look like this: - React / Vite / TypeScript for isolated frontend capabilities - Cloudflare Workers to cache and stabilise the GraphQL layer - API backends using PHP, Node, Python, or Go — depending on context If the feature fails, the system continues. For me, this is where the Strangler pattern becomes tangible. Not a rewrite. Not a migration plan. A series of isolated capabilities that gradually take responsibility. Curious how others are addressing this in practice — especially in larger organisations where the pressure to add “just one more feature” to the core is constant.

GitHub owns npm, but the npmjs.com site was stagnant with many unresolved issues. In January, Daniel Roe launched npmx.dev, an alternative frontend that quickly gained thousands of contributors and addressed many requests. npmx.dev supports URL swapping for easy transition. This competition pushed npmjs.com to improve, recently adding dark mode and fixing long-standing issues. https://lnkd.in/gmVRw9FV #javascript #frontend #npm #npmx

Most React tutorials are still teaching 2020 patterns. In 2026, the ecosystem has shifted dramatically: React 19 is stable, the compiler handles most memoization automatically, and useEffect should be a last resort — not your go-to for data fetching, derived state, or event responses. This guide walks you from project setup to production-ready patterns, with a cheat sheet you can bookmark. #react #web #frontend #next #frontend #performance #javascript #tips #typescript #nextjs

🚫 Stop using JSON.parse(JSON.stringify()) for deep cloning! It’s slow, breaks Dates, Maps, undefined, and more. Modern JS has better options like structuredClone(). If you're still using the old way in Angular or JS apps, you're risking bugs & performance issues. Read the blog & upgrade your approach 👇 #Angular #JavaScript #WebDevelopment #Frontend #CodingTips #Performance

Most developers still deep clone objects like this: JSON.parse(JSON.stringify(data)) It works. Until it doesn't. Dates become strings. Functions vanish. undefined disappears silently. Circular references throw an error. There's a native alternative that actually handles these cases — and most developers don't know it exists. One caveat: structuredClone() doesn't clone functions or class instances — it's designed for data, not behavior. But for 90% of real-world cases, that's exactly what you need. Available natively in all modern browsers and Node.js 17+ — no library required. Are you still using JSON tricks for deep cloning? 👇 #JavaScript #WebDevelopment #Frontend #JS #SoftwareEngineering

End-to-end type safety isn’t a myth. 🛡️ Bridge Laravel and Vue with Spatie’s Laravel Data. Generate TypeScript types from PHP classes. ◆ No more `any` ◆ Autocomplete for Inertia props ◆ Safer refactoring #Laravel #TypeScript #VueJS #WebDev

⏳ 9 years. That's how long it took JavaScript to admit that new Date() was broken. Temporal just reached Stage 4. It's officially in ECMAScript 2026. Already shipping in Firefox and Chrome. TypeScript 6.0 includes the types. V8 14.4 turned it on by default, which means the next Node.js major gets it native with no flag. 🔥 Why this matters JavaScript Date has been a joke since 1995. Month indexes start at 0. Mutation everywhere. No time zone support. DST math that silently lies to you. Every team has written a Date wrapper at 2am. Every project pulls in a 70KB date library. That era is ending. 🧠 What Temporal gives you • Immutable date/time objects. No more accidental mutations. • Built-in time zones. Real zones, not offsets. DST-aware arithmetic that works. • Clear separation of concerns: PlainDate, PlainTime, PlainDateTime, ZonedDateTime, Instant, Duration. Each type means one thing. • Non-Gregorian calendars supported natively. • No more "is this UTC or local?" guessing game. Before: const meeting = moment.tz("2026-05-03 10:00", "Europe/Paris"); const inNY = meeting.clone().tz("America/New_York"); After: const meeting = Temporal.ZonedDateTime.from({ year: 2026, month: 5, day: 3, hour: 10, timeZone: "Europe/Paris" }); const inNY = meeting.withTimeZone("America/New_York"); No clone. No mutation. No surprises. ✅ What you can delete from package.json • moment (deprecated for years, still installed everywhere) • date-fns (for most cases) • luxon • dayjs • that custom Date helper nobody wants to own Keep them if you ship to browsers older than 2025 or Node older than 26. Everywhere else, start migrating. What library are you killing first - moment, date-fns, or that hand-rolled Date util in your repo? 👇 #javascript #typescript #nodejs #ecmascript #temporal #webdev #frontend #backend #tc39 #fullstack