Bun replaced 4 tools in my stack — here's what actually held up and what didn't

Deveshwar Jaiswal — Sun, 19 Apr 2026 11:40:00 +0000

Vishwakarma is the divine architect in Vedic tradition. He doesn't fight battles or write
laws. He builds the instruments that others use to do those things — weapons for the gods,
chariots for the heroes, the celestial city of Dwaraka. His work is invisible in the final
story because it's structural.

That's Bun.

What Bun actually is

Not a Node killer. Not a React competitor. Not a framework.

Bun is a runtime that also ships as a package manager, a bundler, and a test runner — all
from one binary, with one install, and one config surface. Its value isn't that it makes
your app faster. It's that it removes the toolchain you were managing around your app.

What changed when I switched

My baseline stack before Bun: Node, npm, esbuild, Jest. Four tools. Four version pins.
Four separate failure modes in CI. The kind of setup that's industry-standard and quietly
expensive to maintain.

After switching to Bun:

CI install time dropped. Not purely because of speed — because there's one process
fetching and linking dependencies instead of npm orchestrating multiple sub-processes.

The config surface shrank. No separate Jest config, no esbuild config, no .nvmrc
to keep in sync with CI. One runtime, one set of assumptions.

Hot reload in dev got faster. Consistent, not dramatic. The kind of improvement that
compounds over a workday.

Where the hype is accurate

The benchmark numbers are real — in benchmarking conditions. HTTP throughput, cold start
time, install speed. If those are your bottlenecks, Bun helps.

The TypeScript support is native. No ts-node, no esbuild wrapper, no compilation step in
dev. You write .ts and it runs. That alone removes a category of configuration friction.

Where I'd push back

The 3x speed claims are benchmarking conditions, not production conditions. In a
containerised environment with real I/O — database calls, external APIs, filesystem ops —
the gap narrows. Still faster. Not 3x faster.

Native addon compatibility is not complete. The Node compatibility layer has improved
significantly in the last year, but anything touching native Node addons (N-API, node-gyp)
needs to be tested before you commit. Don't assume.

Alpine Linux / musl libc. Bun's Linux binary targets glibc. If your Docker images are
Alpine-based, you'll need to swap to a Debian-based image. Minor friction, worth knowing
before you're debugging it in production.

Who should switch now

Greenfield TypeScript projects with no native addon dependencies
Side projects and internal tools where you control the full stack
Anyone whose CI bottleneck is actually npm install time

Who should wait

Projects with deep native module dependencies
Teams where Node expertise is load-bearing and switching cost is high
Anything running on musl unless you're willing to change your base image

The Vishwakarma frame

Vishwakarma doesn't appear in the climax of the Mahabharata. He built the instruments
that made it possible. That's the right mental model for a runtime.

Bun didn't write your application. It's not trying to. It built the forge.

👉 Full write-up →

Building something with tight performance requirements and want a second opinion on the
stack → I work with teams on this.

The JS Event Loop Has a Model Gap, Here's What Most Tutorials Don't Show You

Deveshwar Jaiswal — Mon, 13 Apr 2026 12:45:36 +0000

The standard explanation of the JavaScript Event Loop goes like this: there's a call stack,
there's a queue, and when the stack is empty the loop pulls the next item from the queue.

That model isn't wrong. It's incomplete in ways that will eventually burn you.

What the standard explanation misses

1. The microtask queue is not part of the loop cycle in the way the task queue is

Most diagrams show two queues with different priorities. The actual model is different.

After every task completes, the runtime runs the microtask checkpoint. This checkpoint
drains the microtask queue completely — including any microtasks queued by microtasks — before
the event loop selects the next task.

setTimeout(() => console.log('task'), 0);

Promise.resolve()
  .then(() => {
    console.log('microtask 1');
    return Promise.resolve();
  })
  .then(() => console.log('microtask 2'));

console.log('sync');

Output: sync → microtask 1 → microtask 2 → task

The setTimeout callback doesn't run until every microtask — including chains — has settled.

2. The render step sits between tasks, not between microtasks

The browser's render pipeline (style recalc, layout, paint) runs between tasks. Not between
microtasks.

This means: a long Promise chain is as harmful to your frame rate as a long synchronous
function. No heavy computation required. If you're queueing work in Promises and wondering
why your animations stutter, this is likely the reason.

3. `setTimeout(fn, 0)` and `Promise.resolve().then(fn)` are different lanes

Not different speeds. Different lanes with different rules.

setTimeout → task queue. One per loop iteration. Render can happen before the next one.
Promise.resolve().then → microtask queue. Entire chain runs before the loop advances.

Swapping one for the other is not a performance micro-optimisation. It changes execution
semantics.

The mental model I use

I mapped this to Vedic karma and dharma — unconventional framing, but it makes the model stick.

Every async operation you schedule is karma: a consequence set in motion, deferred but
not cancelled. The event loop is dharma: the rule governing when consequences are processed.

Call stack = the present moment. One thing at a time.
Microtask queue = urgent karma. Drains immediately after the present resolves.
Task queue = future karma. Waits for a full loop cycle.
Render step = the breath between cycles. Can be held by urgent karma flooding.

It's a mnemonic layer, not a replacement for reading the WHATWG HTML spec. But it's why
the model stuck for me in a way no diagram had managed.

Interactive visualizer

I built a step-by-step visualizer: write any snippet, step through execution, and watch
every queue animate in real time. Microtask drain, render step timing, task queue behaviour
— all visible.

👉 Try the interactive visualizer →

If you're building production frontend and want to dig into performance or architecture →
I'm available for hire.

Forem: Deveshwar Jaiswal