Forem: Abhishek Dubey

Modern Bundlers Are Moving Beyond Webpack

Abhishek Dubey — Sat, 11 Oct 2025 16:36:57 +0000

Why Modern Bundlers Are Moving Beyond Webpack: Comparing Vite, Rspack, and Turbopack

Webpack has been the backbone of frontend development for over a decade. But as modern web apps grow bigger and faster, developers are running into build speed bottlenecks, complex configurations, and scaling headaches. Enter the new generation of bundlers: Vite, Rspack, and Turbopack.

In this post, we'll explore why the frontend world is slowly moving beyond Webpack, compare the modern alternatives, and help you decide which bundler fits your project today.

The Problem with Webpack Today

Webpack is powerful, but it comes with a few pain points in 2025:

Slow builds for large projects – incremental builds can take tens of seconds.
Complex configuration – modern apps often require dozens of loaders and plugins.
Tree shaking limitations – unused code sometimes sneaks into bundles.
Scaling challenges – micro-frontends, multi-repo setups, and monorepos can get messy.

Even seasoned engineers find themselves tweaking configs endlessly just to shave off a few seconds from build times.

Meet the Modern Bundlers

Vite

Written in Node.js + ESBuild
Dev server uses native ES modules → instant HMR
Super-fast development thanks to ESBuild and HMR (only changed modules update in the browser without full reload)
Production builds optimized with Rollup
Best for: SPA projects, React/Vue apps, developer experience focus

Rspack

Written in Rust
Drop-in Webpack alternative; supports most Webpack plugins
Fast builds thanks to parallelization and low-level optimizations
Best for: large projects needing Webpack compatibility but faster builds

Turbopack

Created by Vercel (Next.js team), written in Rust
Next-gen bundler: does incremental rebuilds, uses multiple CPU cores, and caches aggressively to handle large projects faster than Vite
Best for: Next.js projects, monorepos, high-scale production apps

Rollup (for libraries)

More library-focused than full-app bundlers
Built-in tree-shaking
Can output ES modules, CommonJS, or UMD → libraries work anywhere
Best for: reusable packages, libraries, or small frameworks

Key Differences

Feature	Webpack	Vite	Rspack	Turbopack	Rollup
Language	JS	JS + ESBuild	Rust	Rust	JS
Dev Server Speed	Medium	Fast	Fast	Super Fast	Medium
Production Build	Medium	Fast	Fast	Very Fast	Fast
Plugin Ecosystem	Huge	Growing	Webpack-compatible	Growing	Growing
Incremental Builds	No	Yes	Yes	Yes	No
Micro-frontend support	Limited	Limited	Webpack-compatible	Limited	Limited

When to Choose Which Bundler

Vite: Small to medium SPA, great dev DX, instant HMR
Rspack: Large legacy Webpack app, want faster builds, maintain plugin ecosystem
Turbopack: Next.js / monorepo / high-scale production builds
Rollup: Library-focused projects, reusable packages
Webpack: Legacy projects, massive plugin ecosystem, full control

Migration & Ecosystem Considerations

Migration Effort: Vite is easy for new projects; Rspack for legacy Webpack apps; Turbopack mostly tied to Next.js
Plugin Support: Rspack maintains Webpack plugin compatibility; Vite has its own ecosystem
Caveats: Some advanced Webpack plugins may not work on Vite/Turbopack; testing required

Conclusion

Webpack isn’t dead, but modern bundlers solve speed, dev experience, and scaling pain points. Choosing a bundler today is about project size, team needs, and future scaling, not just hype.

The future of frontend builds is Rust, ESBuild, Rollup, and incremental compilation. As apps grow, you’ll want a bundler that builds as fast as your code changes.

React Reconciliation, Fiber, and Virtual DOM Explained (Without the Jargon)

Abhishek Dubey — Tue, 07 Oct 2025 20:15:51 +0000

When you write React code, you usually just think in terms of state → UI.

But have you ever wondered how React efficiently updates the UI without repainting everything?

The secret sauce is Reconciliation, Fiber, and the Virtual DOM.

Let’s break it down step by step 👇

🧠 1. Virtual DOM: The Memory Blueprint

React doesn’t touch the real DOM directly every time you update state.

Instead, it builds a Virtual DOM — a lightweight JS object tree representing your UI.

Example UI:

<div id="app">
  <h1>Hello</h1>
  <button>Click</button>
</div>

Virtual DOM Representation:

{
  type: "div",
  props: { id: "app" },
  children: [
    { type: "h1", props: {}, children: ["Hello"] },
    { type: "button", props: {}, children: ["Click"] }
  ]
}

Each node has:

type → element/component type
props → attributes
children → nested nodes or text

Why it’s faster:

Updating JS objects in memory is much cheaper than updating the real DOM, which triggers:

style recalculation
layout reflow
repainting pixels

⚡ 2. React Diffing and Minimal DOM Updates

When you call setState, React doesn’t immediately touch the DOM.

It follows these steps:

Builds a new Virtual DOM.
Compares it with the old Virtual DOM (diffing).
Generates a patch with only the differences.

Example:

<!-- Before -->
<button>Click</button>

<!-- After -->
<button>Submit</button>

React sees only the text changed and updates button.textContent in the DOM.

The DOM is dumb — it just follows commands.

✅ You could manually update the DOM, but in complex apps that quickly becomes unmanageable.

🧩 3. Batching Updates

React groups multiple updates together in a process called batching.

This prevents unnecessary re-renders.

Pre-React 18:

Batching happened only inside React event handlers.

Example:

function handleClick() {
  setCount(c => c + 1);
  setName("Alex");
}

Both updates happen together → one render

React 18+ (Automatic Batching):

Now, batching works everywhere, even inside async code.

Example:

setTimeout(() => {
  setCount(c => c + 1);
  setName("Alex");
}, 0);

Both updates inside the timeout are batched → one render, not two.

Bottom line: fewer renders → smoother UI.

🧵 4. Fiber: Making Large Trees Responsive

For huge UI trees, diffing everything at once can freeze the page.

React Fiber fixes that.

How Fiber works:

Breaks work into units: Each component is a “unit of work.”
Incremental rendering: React processes a few nodes, pauses, then continues.
Yielding: React temporarily pauses work so the browser can handle input, scrolling, or animations.
Priority system:
- High: typing, animations
- Low: timers, transitions (startTransition() for low-priority updates)

💡 Analogy:

Old React = lifting 1000 kg of UI in one go → UI freezes.

Fiber = lifting 50 kg, take a break, continue → smooth experience.

🚀 5. Virtual DOM Skip / Compile Updates Directly

Some frameworks like Svelte or Solid go beyond React’s Virtual DOM idea.

They skip the diffing step entirely.

They:

Track exactly which state affects which node
Compile your code to direct DOM updates

Example:

function updateCount(newCount) {
  button.textContent = newCount;
}

No runtime diffing → direct DOM manipulation → blazing fast.

🧾 Key Takeaways

Virtual DOM → memory-efficient blueprint of the UI
Reconciliation → minimal DOM updates after diffing
Batching → multiple state updates grouped into one render
Fiber → incremental rendering, yielding, and priority control
Virtual DOM skip / compile updates → direct DOM updates for peak performance

React may seem like magic, but now you know the mechanics behind its efficiency.

Understanding this helps you write faster, smoother, and more predictable React apps.

Short summary:

💬 Did this make React’s internals a bit clearer?

Drop a comment — I’d love to know which part clicked for you!

JavaScript Web Workers: Keep Your UI Smooth and Snappy

Abhishek Dubey — Thu, 01 May 2025 02:04:53 +0000

🧵 JavaScript Is Single‑Threaded… Until It’s Not

JavaScript is often referred to as a single‑threaded language. But what does that mean?

In simple terms, being single‑threaded means JavaScript can only use one CPU core at a time, typically referred to as the main thread. All your logic, UI rendering, event handling—everything—runs here. It does this using the event loop, which lets JavaScript execute asynchronous operations (like timers or network requests) without completely blocking the thread.

Here’s the catch: just because JavaScript is single‑threaded doesn’t mean everything has to run on the main thread.

🛠️ Tasks That Don’t Run on the Main Thread

Some operations—like setTimeout, fetch, or DOM events—are offloaded to the browser’s Web APIs or the system. Once they finish, they queue up a callback to be executed by the event loop.

console.log('Start');
setTimeout(() => console.log('Timeout finished'), 1000);
console.log('End');

Even though setTimeout is called early, its callback is deferred, letting other code keep running. This is concurrent, not parallel.

💡 So… Why Do We Even Need Another Thread?
Fair question. If async code and the event loop are already powerful, why introduce more complexity?

Because some tasks are CPU‑intensive—they need raw computation and can take a long time. Examples include:

Complex mathematical calculations
Image or video processing
Parsing massive data sets
Matrix multiplication

If you run these directly on the main thread, your UI will freeze. No clicks, no scrolls, no animations—just pain.

Enter the big guns, WEB WORKERS!!!

⚙️ Enter: Web Workers

Web Workers are background scripts that run in a separate thread from the main JavaScript execution thread.

They let you do heavy computation without touching the main thread, so your UI stays smooth and interactive.

🧠 Think of Web Workers as JS-powered background employees. You send them a task, they work on it without bothering the main UI, and when they're done—they report back.

✅ Key Points

Run on a separate thread
Can’t access the DOM directly
Communicate via postMessage / onmessage
Available in both browsers and Node.js

🧪 Example: Web Worker in Node.js

// worker.js
const { parentPort } = require('worker_threads');

parentPort.on('message', (data) => {
  const result = data.a + data.b;
  parentPort.postMessage(result);
});

// main.js
const { Worker } = require('worker_threads');

const worker = new Worker('./worker.js');
worker.postMessage({ a: 10, b: 20 });

worker.on('message', (result) => {
  console.log('Result from worker:', result);
});

🧮 Browser Demo: Matrix Multiplication in a Web Worker

Let’s build a simple browser demo:

Input box to enter a number (e.g., 5)
Submit button
Toggle: “Use Web Worker” ON/OFF
On submit:
- Generate two random N×N matrices
- Multiply them inside a Web Worker (if toggle ON) or on the main thread (if toggle OFF)
- Display time taken

👉 React App Structure

/*
File: src/App.jsx
*/
import React, { useState, useRef } from "react";
import MatrixWorker from "./matrixWorker?worker";

const worker = new MatrixWorker();
function App() {
    const [size, setSize] = useState(5);
    const [useWorker, setUseWorker] = useState(true);
    const [timeTaken, setTimeTaken] = useState(null);
    const workerRef = useRef(null);

    const randomMatrix = (n) =>
        Array.from({ length: n }, () =>
            Array.from({ length: n }, () => Math.floor(Math.random() * 10))
        );

    const multiplyMatrices = (A, B) => {
        const n = A.length;
        const C = Array.from({ length: n }, () => Array(n).fill(0));
        for (let i = 0; i < n; i++) {
            for (let j = 0; j < n; j++) {
                for (let k = 0; k < n; k++) {
                    C[i][j] += A[i][k] * B[k][j];
                }
            }
        }
        return C;
    };

    const handleMultiply = () => {
        const n = Number(size);
        const matA = randomMatrix(n);
        const matB = randomMatrix(n);
        const start = performance.now();

        if (useWorker) {
            if (!workerRef.current) {
                workerRef.current = new MatrixWorker();
            }
            workerRef.current.postMessage({ matA, matB });
            workerRef.current.onmessage = (e) => {
                const duration = (performance.now() - start).toFixed(2);
                setTimeTaken(`${duration} ms (Web Worker)`);
            };
        } else {
            multiplyMatrices(matA, matB);
            const duration = (performance.now() - start).toFixed(2);
            setTimeTaken(`${duration} ms (Main Thread)`);
        }
    };

    return (
        <div style={{ padding: "2rem", fontFamily: "sans-serif" }}>
            <h1>Matrix Multiplication Demo (React)</h1>
            <div style={{ marginBottom: "1rem" }}>
                <label>
                    Matrix size:
                    <input
                        type="number"
                        value={size}
                        min={1}
                        onChange={(e) => setSize(e.target.value)}
                        style={{ marginLeft: "0.5rem",width: "4rem" }}
                    />
                </label>
                <label style={{ marginLeft: "1rem" }}>
                    Use Web Worker:
                    <input
                        type="checkbox"
                        checked={useWorker}
                        onChange={(e) => setUseWorker(e.target.checked)}
                        style={{ marginLeft: "0.5rem" }}
                    />
                </label>
            </div>
            <button onClick={handleMultiply} style={{ padding: "0.5rem 1rem" }}>
                Multiply
            </button>
            {timeTaken && (
                <p style={{ marginTop: "1rem" }}>Done in {timeTaken}</p>
            )}
        </div>
    );
}

export default App;

/*
File: src/matrixWorker.js
*/

self.onmessage = function (e) {
    const { matA, matB } = e.data;
    const n = matA.length;
    const C = Array.from({ length: n }, () => Array(n).fill(0));
    for (let i = 0; i < n; i++) {
        for (let j = 0; j < n; j++) {
            for (let k = 0; k < n; k++) {
                C[i][j] += matA[i][k] * matB[k][j];
            }
        }
    }
    postMessage(C);
};

🧪 Try It Yourself

To really feel the difference, try multiplying two 1500 x 1500 matrices using both options:

✅ With Web Worker — your UI stays responsive, the "Multiply" button works, and the browser doesn’t freak out.
❌ Without Web Worker — you’ll notice the UI freezes up completely until the computation is done.

Why? Because your main thread is busy doing math and has no time to update the UI, handle clicks, or even blink.

This is exactly why Web Workers exist — to offload heavy computation without blocking your app's user experience.

🛠 Other Ways to Offload Heavy Computation

Web Workers aren't the only way to avoid locking up the UI. Here are a few other techniques and tools:

WebAssembly (Wasm)

Compile C, C++, or Rust to run high-performance code in the browser. Great for math-heavy tasks.
GPU.js

Leverage your GPU for parallel computations using WebGL. Perfect for things like image processing or large matrix operations.
Service Workers

Mostly used for caching and background sync, but can also handle some async logic (not for CPU-heavy stuff though).
setTimeout / requestIdleCallback

For breaking up large loops into chunks and letting the UI breathe in between.
Backend offloading (API calls)

If the task is too intense for the browser, do it server-side in Python, Go, etc., and just send the result back.

🧠 Bottom line: Don't block the main thread. Ever. Keep it snappy, keep it async, and keep your users happy.

🎉 Conclusion & Next Steps

Web Workers let you offload CPU‑heavy tasks to a separate thread, keeping your UI responsive. Play with the demo, tweak it, and drop it into your next project!
Want to go deeper? Try integrating Web Workers into a real project — like animations, data visualization tools, or AI models running in the browser.

Happy coding—now go make your apps buttery smooth. 🚀

aaa

Abhishek Dubey — Thu, 01 May 2025 02:02:23 +0000

aaa