Forem: Ishan Bagchi

The Scheduler API: Prioritising Work on the Main Thread

Ishan Bagchi — Thu, 19 Mar 2026 21:22:22 +0000

Every performance problem in the browser eventually traces back to the same crime: something blocked the main thread for too long.

The user clicked a button. The browser wanted to run the click handler, repaint the changed pixel, and move on. But before it could, your application decided this was a great time to parse a 4 MB JSON payload, diff a 3,000-node virtual DOM, and synchronously compute analytics. The animation dropped frames. The button felt broken. The user noticed.

We have spent years routing around this problem. Debouncing, throttling, Web Workers, requestIdleCallback, virtualizing long lists — all of them are, at their core, strategies to stop doing too much on the main thread at once.

The Scheduler API takes a different angle. It doesn't tell you to do less work. It lets you tell the browser which work matters right now and which can wait — and it actually enforces that.

Why The Old Solutions Fall Short

Before reaching for anything new, it's worth being honest about the tools that already exist.

`setTimeout(fn, 0)` — The Classic Lie

The canonical trick for "yielding to the browser" is wrapping work in a setTimeout with a zero-delay:

setTimeout(() => {
    doExpensiveWork()
}, 0)

This defers doExpensiveWork until after the current synchronous call stack clears, which buys the browser a slot to repaint. It works, in the same way a Band-Aid works on a broken leg. The problem is that setTimeout callbacks are scheduled into a single, undifferentiated queue. Your deferred analytics code and your deferred critical rendering code are both "just callbacks." There is no concept of importance.

There's also the historical floor: browsers clamp setTimeout delays to a minimum of 4ms after five nested calls, meaning you can't even rely on the zero-delay to mean "as soon as possible."

`requestIdleCallback` — The Right Idea, Wrong API

requestIdleCallback was a genuine step forward. It lets you schedule low-priority work for browser idle periods:

requestIdleCallback((deadline) => {
    while (deadline.timeRemaining() > 0 && tasks.length > 0) {
        tasks.shift()()
    }
})

You get a deadline object, you check how much time is left in the idle period, and you process work until it runs out. This prevents your background work from stealing time from user interactions.

But it has two cardinal limitations:

No priority system. requestIdleCallback is a binary: it's either "idle work" or "not idle work." There's no way to say "run this before that idle task, because it matters more."
Unreliable under load. When the main thread is busy, idle periods shrink or disappear entirely. Critical deferred work might literally never run during a heavy interaction-driven session.

`requestAnimationFrame` — The Wrong Abstraction

requestAnimationFrame is for animation. Specifically, it fires before each paint, giving you a reliable hook for writing to the DOM without causing layout thrash. Developers sometimes abuse it as a general "next-tick" mechanism.

// This works but it's wrong.
// rAF is not meant for non-visual work.
requestAnimationFrame(() => {
    processBatchOfNonVisualData()
})

Using rAF for non-rendering work wastes the 16ms animation budget on things that have nothing to do with the frame. It can actually cause jank by forcing non-visual computation into a time slot that was supposed to be reserved for drawing.

The common failure mode is the same across all three: no shared, priority-aware queue. Each of these APIs is its own island. The browser has no way to reason about relative importance across them.

That's the gap the Scheduler API is filling.

The Scheduler API

The Scheduler API provides a first-class, priority-aware task queue built directly into the browser. Its primary interface is scheduler.postTask().

scheduler.postTask(() => {
    doSomeWork()
})

At its most basic level, this looks identical to setTimeout(fn, 0). The difference is what's happening underneath. The task is registered with a userspace scheduler that understands priority levels, can abort tasks before they run, can have their priority changed after they're queued, and integrates correctly with the browser's own event loop priorities.

Browser support: Chromium-based browsers have shipped the Scheduler API since Chrome 94. Firefox has it behind a flag. Safari does not support it yet. For production use today, you will need either feature detection with a graceful fallback (covered below) or the WICG scheduler polyfill. The API is stable and the cross-browser gap is narrowing.

Priority Levels

Every task submitted to scheduler.postTask() has a priority. There are exactly three, and they map directly to the browser's own internal task prioritization:

Priority	Value	Roughly Equivalent To
Highest	`'user-blocking'`	Mouse/keyboard input handlers
Default	`'user-visible'`	`setTimeout(fn, 0)`
Lowest	`'background'`	`requestIdleCallback`

// High priority — treat this like user input
scheduler.postTask(() => updateCriticalUI(), { priority: 'user-blocking' })

// Default priority — non-urgent but visible work
scheduler.postTask(() => renderSecondaryContent(), { priority: 'user-visible' })

// Low priority — this can wait until the browser is truly idle
scheduler.postTask(() => sendAnalyticsEvent(), { priority: 'background' })

The browser enforces this ordering. A 'background' task will not preempt a 'user-blocking' one. If a high-priority task arrives while a lower-priority one is still queued, the high-priority work goes first.

That sounds like a table-stakes guarantee. But it's the first time the platform has given us an actual mechanism to express it.

Choosing the Right Priority

user-blocking should be reserved for work whose absence is directly visible to the user as a broken interaction. Rendering the direct result of a click. Updating a focused form field. If the user has to wait for this and the wait is noticeable, use user-blocking.

user-visible (the default) is for work that needs to happen soon, but can tolerate a single frame of delay. Data transformations that drive a chart update. Lazy populating a dropdown. Most of your "important but not critical" deferred work lives here.

background is for work the user will never directly observe in the immediate moment. Telemetry, prefetching, warming caches, building search indexes, syncing non-visible state. If it's fine to run in idle time, it belongs here.

`scheduler.postTask()` Returns a Promise

scheduler.postTask() returns a Promise that resolves with whatever your callback returns. That changes the ergonomics a lot.

const result = await scheduler.postTask(
    () => {
        return computeExpensiveValue(largeDataset)
    },
    { priority: 'background' },
)

console.log(result) // The computed value, available when the task completes

This means you can chain deferred work naturally, without deeply nested callbacks or manual coordination. You get the async/await model with the browser's scheduler underneath.

async function buildReportData(raw) {
    // Step 1: Parse — this is CPU heavy, keep it off the critical path
    const parsed = await scheduler.postTask(() => parseRawData(raw), {
        priority: 'background',
    })

    // Step 2: Aggregate — still background, can run after parse
    const aggregated = await scheduler.postTask(
        () => aggregateByDimension(parsed),
        { priority: 'background' },
    )

    // Step 3: Render the result — now it's visible work
    await scheduler.postTask(() => renderReport(aggregated), {
        priority: 'user-visible',
    })
}

Each step yields back to the browser between phases. User interactions that happen while the background processing is in flight still get priority. The report data will appear when the browser gets around to it, but it won't block a scroll or a click.

Aborting Tasks with `TaskController`

Deferred work is sometimes invalidated before it runs. A user navigates away. A filter changes before the previous filter's result has been computed. A component unmounts.

postTask was designed for this. You pass a signal derived from a TaskController, and you call .abort() when the work is no longer needed:

const controller = new TaskController({ priority: 'background' })

scheduler.postTask(() => buildLargeIndex(data), {
    signal: controller.signal,
})

// Later: the user's action has made this work irrelevant
controller.abort()

When .abort() is called, the promise returned by postTask rejects with an AbortError. You handle it the same way you would handle a cancelled fetch:

try {
    await scheduler.postTask(() => buildLargeIndex(data), {
        signal: controller.signal,
    })
} catch (err) {
    if (err.name === 'AbortError') {
        // Task was cancelled. This is expected, not an error.
        return
    }
    throw err
}

This isn't just a nice-to-have. Without explicit cancellation you can end up with a stale-result race condition — an invalidated background task finishing after a newer one and overwriting fresh data with stale results. It's the kind of bug that only appears under load and is miserable to track down.

Changing Priority Dynamically

TaskController gives you another capability that other scheduling primitives simply don't have: you can change the priority of a queued task after it's been submitted.

const controller = new TaskController({ priority: 'background' })

scheduler.postTask(() => preprocessSearchIndex(documents), {
    signal: controller.signal,
})

// User opens the search box — this work is now urgent
controller.setPriority('user-visible')

Think about what this means. The task was sitting quietly in the background doing preprocessing. The user opens search — now that work is suddenly relevant to something imminent. You don't cancel it and resubmit. You promote it in place.

The reverse works too. A task you thought mattered becomes irrelevant mid-flight. Demote it. Free up the headroom. The API was designed to support this kind of dynamic context, and it shows.

Delaying Tasks

postTask also accepts a delay option, which is a minimum delay in milliseconds before the task is eligible to run:

scheduler.postTask(() => prefetchNextPageData(), {
    priority: 'background',
    delay: 2000, // Don't even consider this for 2 seconds
})

This is subtly different from setTimeout. With setTimeout, the callback fires after the delay, full stop. With postTask, the delay sets a floor on when the task becomes eligible, but the actual execution still respects the priority queue. A user-blocking task that arrives after the delay would still preempt this background task.

It's a minimum delay, not a scheduled time.

A Practical Pattern: The Task Queue with Chunking

One of the most effective patterns with the Scheduler API is breaking a large synchronous loop into scheduled chunks. The naive version blocks the main thread for the duration of the loop:

// ❌ This processes 10,000 items synchronously.
// Nothing else can run until it's done.
function processAll(items) {
    for (const item of items) {
        processItem(item)
    }
}

The scheduler.yield() proposal (part of the same spec) is the cleanest answer here, but until it ships everywhere, you can approximate it with postTask:

async function processInChunks(items, chunkSize = 50) {
    const chunks = []
    for (let i = 0; i < items.length; i += chunkSize) {
        chunks.push(items.slice(i, i + chunkSize))
    }

    for (const chunk of chunks) {
        await scheduler.postTask(
            () => {
                for (const item of chunk) {
                    processItem(item)
                }
            },
            { priority: 'background' },
        )
    }
}

Each chunk is a separate background task. Between chunks, the browser handles input, runs higher-priority work, and repaints. The total wall-clock time for all the processing is slightly longer than the synchronous version. But the interaction latency — how long the user waits for a response after clicking — drops. That's the trade-off worth making, and with postTask you can actually express it cleanly.

Composing with React

If you're in a React codebase, this integrates cleanly with useEffect. The pattern is nearly identical to how you'd cancel a fetch inside an effect — a controller, a signal, and cleanup on return:

function useBackgroundProcessor<T>(data: T[], processor: (item: T) => void) {
    useEffect(() => {
        const controller = new TaskController({ priority: 'background' })
        let cancelled = false

        async function run() {
            const chunkSize = 100
            for (let i = 0; i < data.length; i += chunkSize) {
                if (cancelled) break

                const chunk = data.slice(i, i + chunkSize)

                try {
                    await scheduler.postTask(
                        () => {
                            chunk.forEach(processor)
                        },
                        { priority: 'background', signal: controller.signal },
                    )
                } catch (err) {
                    if ((err as Error).name === 'AbortError') return
                    throw err
                }
            }
        }

        run()

        return () => {
            cancelled = true
            controller.abort()
        }
    }, [data, processor])
}

The useEffect cleanup cancels in-flight tasks and prevents the processor from starting new chunks after unmount. If your component remounts before the previous run finishes, you get a fresh controller and a clean slate.

How This Relates to React's Concurrent Mode

React 18 introduced concurrent rendering — the ability to interrupt and resume render work, deprioritize updates, and yield to more urgent interactions. React's internal scheduler is a userspace implementation of basically this same concept: priority lanes, preemption, interruptible work.

So — are they redundant? No. The scope is different.

React's scheduler only knows about React's own render work. The browser Scheduler API handles any JavaScript task you give it, React or not. Background data processing, analytics pipelines, search indexing — none of that passes through React's scheduler, but it can all go through scheduler.postTask.

They don't step on each other. React handles its own rendering priority internally. You reach for scheduler.postTask for everything happening outside the render pipeline.

Feature Detection and Fallbacks

For production use, you need a fallback strategy for browsers that haven't shipped the API yet. The simplest approach is feature-detecting at callsites:

function scheduleTask(callback, options = {}) {
    if ('scheduler' in globalThis && 'postTask' in scheduler) {
        return scheduler.postTask(callback, options)
    }

    // Graceful degradation.
    // Background tasks become setTimeout; blocking tasks run synchronously.
    const { priority = 'user-visible', delay = 0 } = options
    if (priority === 'user-blocking') {
        return Promise.resolve(callback())
    }
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            try {
                resolve(callback())
            } catch (e) {
                reject(e)
            }
        }, delay)
    })
}

This is not a perfect polyfill — setTimeout doesn't respect the same priority ordering — but it's a reasonable approximation that degrades to the existing behavior rather than throwing. For a stricter cross-browser implementation, the WICG Polyfill is the reference implementation maintained alongside the spec.

When Not to Reach For This

A few places I've seen this misused — and at least one of them was in my own code.

Don't reach for it when work genuinely needs to be synchronous. If a click must produce an immediate, perceptible result, yielding to the event loop is the wrong move. You'll introduce a visible delay where there was none. Update the DOM synchronously, then defer any secondary work that can wait.

It's not a substitute for a Web Worker. This one trips people up. Moving CPU-heavy work — image processing, parsing, cryptography — to a background task defers when it runs, but when it does run, it still blocks the main thread. A task that takes 200ms and is scheduled as background will still drop frames when it fires. Off-thread is categorically different from low-priority.

Don't over-chunk. postTask has overhead. Splitting 10,000 items into 10,000 individual tasks costs more in coordination than it saves in responsiveness. 50–100 items per chunk, targeting the 4–8ms range per task, is a reasonable starting point. Measure your actual processing time — don't guess.

The Takeaway

The main thread isn't going anywhere. Web Workers are useful but they don't touch the DOM, and most UI work happens where the DOM lives. That's not changing.

What we've always lacked is a way to be precise about what matters when. setTimeout(fn, 0) is a blunt instrument — it says "run this eventually." The Scheduler API gives you the ability to say "run this before that, but after those, and here's how to reach me if things change."

That's not an incremental improvement. It's a different abstraction for expressing intent.

The browser support situation means you'll need a fallback for now. But the API is stable, Chromium has shipped it for years, and the rest of the ecosystem is catching up. It's worth understanding before you need it — because when you do need it, you'll really need it.

Building a Table of Contents Sidebar Without a Library

Ishan Bagchi — Mon, 09 Mar 2026 14:41:02 +0000

Long posts need navigation. If a reader lands halfway through a blog and wants to jump to a specific section, a wall of text with no landmarks is hostile. So I decided to add a table of contents sidebar to The Log.

I had one constraint: no library. The implementation had to be vanilla JS, composable with the existing Astro layout, and small enough that I could reason about every line of it.

Here is what I built and how.

The Shape of the Thing

The sidebar sits to the left of the article. It is sticky, it stays in view as you scroll. Each heading in the post becomes a link. The currently-visible section gets highlighted in gold, tracking your reading position in real time.

On viewports narrower than 1080px it disappears entirely. The post column is too wide on mobile for a sidebar to make sense.

The HTML

The structure is minimal. An <aside> with a label, a small heading, and an empty <nav>. The nav is intentionally empty at markup time, JavaScript fills it in after the page loads.

<aside class="toc-sidebar" aria-label="Table of contents">
  <p class="toc-title">On this page</p>
  <nav class="toc"></nav>
</aside>

The <aside> sits as a flex sibling of the <article> inside <main>. The post wrapper becomes a flex row:

.post-wrapper {
    display: flex;
    justify-content: center;
    align-items: flex-start;
    gap: 3rem;
}

The Sticky CSS

Sticky sidebars have one requirement: the parent must not have overflow: hidden. Beyond that, the setup is straightforward.

.toc-sidebar {
    width: 190px;
    flex-shrink: 0;
    position: sticky;
    top: 5rem;
    max-height: calc(100vh - 7rem);
    overflow-y: auto;
    scrollbar-width: none;
}

top: 5rem respects the sticky header. max-height with overflow-y: auto means long tables of contents scroll independently of the page, the sidebar never grows taller than the viewport. scrollbar-width: none hides the scrollbar without removing the scrollability.

The link styles use a left border as the visual rail:

.toc-link {
    display: block;
    font-family: var(--font-mono);
    font-size: 0.72rem;
    padding: 0.25rem 0;
    padding-left: 0.75rem;
    border-left: 1px solid var(--color-border);
    color: var(--color-text-muted);
    opacity: 0.55;
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
}

.toc-link.toc-active {
    color: var(--color-gold);
    opacity: 1;
    border-left-color: var(--color-gold);
}

H3 links get a deeper inset to convey hierarchy:

.toc-h3 {
    padding-left: 1.35rem;
    font-size: 0.68rem;
}

The JavaScript

The JS runs once on page load and does four things.

1. Collect headings. Query every h2 and h3 inside .prose, skip if there are none, and remove the sidebar.

const headings = Array.from(
    document.querySelectorAll<HTMLElement>('.prose h2, .prose h3'),
)

if (headings.length === 0) {
    sidebar.remove()
    return
}

2. Ensure IDs exist. Astro's markdown renderer adds IDs to headings automatically, but MDX or custom components might not. I generate a fallback slug just in case.

headings.forEach((h) => {
    if (!h.id) {
        h.id = (h.textContent ?? '')
            .trim()
            .toLowerCase()
            .replace(/[^a-z0-9]+/g, '-')
            .replace(/^-|-$/g, '')
    }
})

3. Build the links. For each heading, create an anchor, assign the right class for H2 vs H3, and append it to the nav. The click handler smooth-scrolls to the target rather than letting the browser jump.

headings.forEach((h) => {
    const a = document.createElement('a')
    a.href = `#${h.id}`
    a.textContent = h.textContent ?? ''
    a.className = `toc-link ${h.tagName === 'H3' ? 'toc-h3' : 'toc-h2'}`
    a.addEventListener('click', (e) => {
        e.preventDefault()
        document
            .getElementById(h.id)
            ?.scrollIntoView({ behavior: 'smooth', block: 'start' })
    })
    toc.appendChild(a)
})

4. Track the active section. This is where it gets interesting.

Why IntersectionObserver, Not a Scroll Listener

The naive approach is to listen to the scroll event and check which heading is nearest the top of the viewport on every tick. That fires hundreds of times per second. Even with throttling, you are doing DOM measurements on a hot path.

IntersectionObserver inverts the model. Instead of polling the scroll position, you declare interest in specific elements and the browser tells you when they cross a threshold, asynchronously, off the main thread.

const observer = new IntersectionObserver(
    (entries) => {
        const visible = entries
            .filter((e) => e.isIntersecting)
            .sort((a, b) => a.boundingClientRect.top - b.boundingClientRect.top)

        if (visible.length > 0) setActive((visible[0].target as HTMLElement).id)
    },
    { rootMargin: '0px 0px -70% 0px' },
)

headings.forEach((h) => observer.observe(h))

The rootMargin: '0px 0px -70% 0px' shrinks the effective viewport from the bottom by 70%. This means a heading only counts as "visible" when it is in the top 30% of the screen, which matches the intuition of "I am currently reading this section."

The callback receives all intersection changes in a batch, so I sort by boundingClientRect.top to find the topmost one and activate it.

No scroll listeners. No throttling. No requestAnimationFrame. The browser handles the scheduling.

The Scroll Offset Fix

One side effect of a sticky header: clicking a TOC link scrolls the heading directly to the top of the viewport, behind the header. The fix is one CSS property:

.prose h2,
.prose h3 {
    scroll-margin-top: 5.5rem;
}

scroll-margin-top is specifically designed for this. When the browser scrolls an element into view, whether via scrollIntoView(), a hash link, or a :target selector, it adds this margin on top. The element ends up 5.5rem below the top edge instead of flush with it.

The Result

The whole thing is about 60 lines of JavaScript and no npm install. It degrades cleanly, if JS is off, the sidebar exists in the HTML but stays empty, and the post is entirely readable without it. On narrow screens, it is hidden and the post layout is unchanged.

The most interesting part of the implementation was the decision not to throttle. IntersectionObserver is not a scroll listener with better manners, it is a fundamentally different primitive. The browser is in charge of firing it, which means it never competes with the user's scroll for main thread time.

That is the kind of constraint I like. Not "do the fast version of the bad approach." Do the approach where the problem does not exist.

Breaking Free from the Render Cycle: Event-Driven Frontend Architecture

Ishan Bagchi — Sun, 08 Mar 2026 20:05:58 +0000

React encourages a very specific mental model: data flows top-down.

Parents pass props to children, state is lifted to common ancestors, and the UI updates predictably when that state changes. This works beautifully for most applications.

But large dashboards expose a limitation.

React assumes data flows like a tree.

Real-world dashboards behave more like a network.

Independent widgets need to communicate with each other without necessarily sharing a direct parent-child relationship. When the "React way" forces you to lift state near the root just so two distant components can talk, the render cycle can quickly become expensive.

Imagine a dashboard with:

12 charts
3 large data tables
8 filter controls
multiple sidebar widgets

A single filter change lifts state near the root.

Even if only two charts care about that filter, React still needs to walk through the component tree during reconciliation. The render cost grows with the size of the tree, not with the number of components that actually care about the change.

The result is a large render blast radius triggered by a tiny interaction.

This is where an Event-Driven Architecture can help.

Instead of forcing all communication through React state, components can broadcast events and subscribe to the ones they care about.

The browser already provides a perfect mechanism for this.

The Native Solution: `CustomEvent`

The DOM has had an event system for decades. We can leverage the native CustomEvent API to implement a lightweight client-side pub/sub event bus.

In simple terms:

React state is like passing a note through a classroom row by row.

Events are like making an announcement over a speaker.

Only the people who care will react.

This approach decouples components while keeping the UI responsive.

1. Building a Type-Safe Event Bus

We start by defining an event map in TypeScript. This ensures that both publishers and subscribers agree on the structure of the event payload.

// eventBus.ts

type EventMap = {
    FILTER_CHANGED: { category: string; value: string[] }
    WIDGET_EXPANDED: { widgetId: string }
    DATA_REFRESH_REQUESTED: void
}

export const EventBus = {
    dispatch<K extends keyof EventMap>(event: K, detail?: EventMap[K]) {
        const customEvent = new CustomEvent(event, { detail })
        window.dispatchEvent(customEvent)
    },

    subscribe<K extends keyof EventMap>(
        event: K,
        callback: (data: EventMap[K]) => void,
    ) {
        const handler = (e: Event) => callback((e as CustomEvent).detail)

        window.addEventListener(event, handler)

        return () => window.removeEventListener(event, handler)
    },
}

This gives us two powerful guarantees:

Decoupled communication between components
Type safety, preventing mismatched event payloads

If someone dispatches an incorrect payload, TypeScript will catch it before runtime.

2. Broadcasting an Event (Publisher)

A filter component deep inside a sidebar can broadcast an update without knowing which components depend on it.

// SidebarFilter.tsx

import { EventBus } from './eventBus'

export function SidebarFilter() {
  const handleSelection = (category: string, value: string[]) => {
    EventBus.dispatch('FILTER_CHANGED', { category, value })
  }

  return (
    // filter UI
  )
}

This action triggers no React re-renders by itself.
It simply emits a browser event.

3. Subscribing to the Event (Consumer)

A chart widget somewhere else on the page can subscribe to that event and update its own local state.

// RevenueChartWidget.tsx

import { useEffect, useState } from 'react'
import { EventBus } from './eventBus'

export function RevenueChartWidget() {
  const [filters, setFilters] = useState<string[]>([])

  useEffect(() => {
    const unsubscribe = EventBus.subscribe('FILTER_CHANGED', (data) => {
      if (data.category === 'revenue') {
        setFilters(data.value)
      }
    })

    return () => unsubscribe()
  }, [])

  return (
    // chart UI that re-renders only when needed
  )
}

The key idea here is isolation.

Only the component that subscribes to the event updates.
The rest of the dashboard remains untouched.

Instead of a root-level state update triggering a wide render pass, only interested components react.

When This Pattern Works Well

Event-driven communication is not meant to replace React state entirely. React state is still the best tool when data directly drives UI structure.

However, events shine in specific scenarios:

Independent Dashboard Widgets

When multiple charts or widgets need to react to global filters without re-rendering the surrounding layout.

Toast Notifications

A deep API utility can emit an event like SHOW_TOAST_SUCCESS without passing callback functions through multiple component layers.

Cross-Framework Communication

If you're building micro-frontends, DOM events become a universal communication layer.

A React component can dispatch an event.
A Vue component can subscribe.
A plain JavaScript module can react.

The browser itself becomes the integration layer.

Tradeoffs to Consider

Event-driven systems introduce flexibility, but they also introduce complexity.

Harder Debugging

With React props and state, data flow is explicit.

Events introduce indirect communication:

Component A emits an event
Component B reacts
Component C updates later

Tracing that chain can be less obvious.

Event Overuse

If every interaction becomes an event, the system can quickly resemble a message broker.

Too many events can create hidden coupling between parts of the application.

Like any architectural pattern, moderation matters.

The Takeaway

Frameworks like React help us render UI efficiently.

But architecture is really about how information moves through the system.

Sometimes the cleanest solution is not more state, more context, or another store library. Sometimes the browser already provides the simplest tool.

By leveraging native DOM events, you can reduce coupling between components, limit unnecessary renders, and build dashboards that remain responsive even under heavy interaction.

React manages rendering.

Events manage communication.

Understanding when to use each is what separates component coding from frontend architecture.

AI in Frontend Development: The New Copilot

Ishan Bagchi — Mon, 17 Nov 2025 17:43:48 +0000

There was a time when front-end developers spent hours wrestling with CSS quirks, pixel-perfect layouts, and browser inconsistencies. Now, AI can do much of that heavy lifting—writing styles, generating components, and even optimizing user experience (UX) through intelligent feedback loops.

We’re not talking about the future. It’s already happening.

Let’s explore how AI is quietly reshaping the world of frontend development, and how you can use it as your copilot, not your replacement.

1. Writing CSS Like Magic

CSS used to be the part of frontend work that developers either loved or loathed. Between specificity battles, responsive breakpoints, and dark mode variants, managing styles is time-consuming. AI tools are stepping in to make it easier.

AI-Powered CSS Generation

Tools like Galileo AI, Uizard, and Locofy can generate clean, semantic CSS from plain text or Figma designs. You describe what you need—“a responsive card with rounded corners and a gradient background”—and the AI spits out the code.

Even GitHub Copilot or ChatGPT can now produce complex layouts in seconds, understanding your design intent better than a typical autocomplete.

Example:
Type this into your AI copilot:

“Create a two-column grid with a sidebar that collapses on mobile and a sticky header.”

You’ll instantly get a React component with CSS Grid or Tailwind utilities ready to go.

The key here isn’t automation, it’s acceleration. AI doesn’t replace design thinking; it simply clears away repetitive work so you can focus on what actually matters: user experience.

2. Generating Components on the Fly

Frontend frameworks like React, Vue, and Svelte are component-driven. Every button, modal, or navbar is a reusable unit. AI now helps scaffold these components faster—and smarter.

Design-to-Code Revolution

Imagine uploading your design system or Figma file to a tool like Locofy, TeleportHQ, or Anima. The AI automatically converts it into production-ready React components with props, responsive behavior, and even accessibility features baked in.

It doesn’t stop at static UI either. AI model-based tools can predict patterns—like when to use useState, how to handle form validation, or when a certain component should use memoization for performance.

It’s as if your copilot has already reviewed hundreds of codebases and learned every best practice, so you don’t have to reinvent the wheel each time.

Example:

You sketch a “Product Card” in Figma.
AI identifies:

Image → <img> tag
Title → <h2>
Description → <p>
Price → dynamic prop
“Add to Cart” → <Button> component

And just like that, your visual design becomes a fully functional, ready-to-edit component.

3. UX Optimization Through Intelligence

This is where AI moves from being a helper to becoming a strategic advisor. It’s not just generating pixels, it’s learning from them.

AI-Driven UX Insights

Modern analytics tools infused with AI, like Hotjar, Amplitude, and FullStory, don’t just record sessions. They analyze behavior patterns to identify friction points.

AI can highlight where users hesitate, rage-click, or drop off entirely. Instead of manually sifting through heatmaps, you get actionable insights like:

“Users are abandoning the checkout at the address form—try auto-suggestion or reducing the number of fields.”

Even A/B testing is evolving—AI can auto-generate variations of your UI and test them in real time, picking the version with higher engagement or conversion.

Conversational UX

Chatbots are evolving too. Tools like Voiceflow and BotPress help integrate conversational interfaces that feel less robotic and more human. AI models are now capable of tailoring responses based on user sentiment, location, or previous interactions—bridging the gap between frontend design and user psychology.

4. Personalization: The Next Big Leap

AI thrives on context. With enough behavioral data, it can personalize interfaces dynamically—changing layouts, color palettes, or even copy depending on user preference.

Think of Netflix’s UI, which rearranges thumbnails based on your habits, or Spotify’s playlists, which adapt to your mood. This same personalization logic is slowly trickling into mainstream web apps.

Frameworks like Next.js or Remix already allow server-side personalization, and pairing them with AI engines that learn user behavior opens up endless creative potential.

Imagine a portfolio website that learns which projects users interact with and reorganizes them to match the visitor’s interests. That’s not science fiction, it’s the future of user-centered design.

5. The Human Touch Still Matters

Despite the impressive capabilities of AI, it doesn’t understand nuance, emotion, or storytelling—at least, not yet. A website that feels right still needs a developer’s intuition.

AI can give you a “beautiful layout,” but it can’t yet replace the small, human decisions that make an interface delightful—how a hover feels, how a transition lands, or how microcopy reassures the user.

AI is a copilot, not a captain. The developer’s job isn’t going away; it’s evolving from building to curating, orchestrating, and enhancing.

6. How to Leverage AI in Your Workflow

If you’re a frontend developer, here’s how you can ride this wave effectively:

Use GitHub Copilot or Codeium to scaffold components faster.
Convert Figma to code using Anima, Locofy, or Uizard.
Let ChatGPT or v0.dev refine your UI copy or accessibility text.
Analyze UX with Hotjar AI or Amplitude Insights.
Automate design tokens and theme generation with Galileo AI or Vercel v0.

Don’t resist AI, train it on your style. Feed it your component patterns, preferred libraries, and design systems. The better it understands your workflow, the more useful it becomes.

Final Thoughts

Frontend development has always been about balance—between logic and creativity, structure and fluidity. AI isn’t taking that away; it’s amplifying it.

The smartest developers in the coming years won’t be the ones who write every line of CSS by hand—they’ll be the ones who know what to automate, when to trust AI, and how to refine its output.

In the end, AI won’t replace frontend developers. It’ll just make the best ones superhuman.

What Actually Happens When You Type a URL in the Browser?

Ishan Bagchi — Tue, 11 Nov 2025 20:25:07 +0000

Imagine you’re at your desk, maybe with a little mug of tea, and you open your browser. You type www.google.com, hit Enter, and in what feels like a heartbeat, you’re staring at the Google homepage.

Simple, right?

Here’s the thing: behind that one keystroke lies a chain reaction, a series of machines, protocols, translations, negotiations, all secretly working together so you can see a web page. It’s less magic, more engineering, but still pretty magical when you think about it.

Step 1: The URL — Your Digital Address

When you typed https://www.google.com, you essentially said:

“Browser, take me to the house called google.com using the secure road (HTTPS).”

Breaking it down:

Protocol: https:// – tells the browser how to speak to the server (securely).
Domain name: www.google.com – tells it where to go.
Path/query (might be something like `/search?q=…” but not in our simple example) – tells it what exactly to fetch inside that domain.

Once you hit Enter, your browser thinks: “Okay, got the address. Now how do I get there?”

Step 2: DNS – The Internet’s Phonebook

Your browser doesn’t know “google.com” as a house, it knows numbers (IP addresses). So it uses the Domain Name System (DNS) to translate the friendly name into an IP.
Here’s a link diving into how DNS works: What is DNS – Cloudflare
And another good read: How DNS works – freeCodeCamp

Roughly this happens:

The browser checks its cache to see if it already knows the IP.
If not found, the OS checks its cache.
If still no, the request goes to the ISP’s DNS resolver which starts querying the DNS hierarchy (root servers → TLD servers → authoritative name servers) to find the IP. (GeeksforGeeks)
Once the IP is found, your browser has a destination.

Step 3: Establishing a Connection – TCP Handshake

With the IP in hand, your browser knocks on the server’s door using TCP (Transmission Control Protocol). It’s a three-way handshake: browser says “hi,” server replies “hi,” browser says “let’s talk.” This establishes reliable communication.
We often gloss over this, but the handshake ensures both sides are ready and synchronised.

Step 4: Adding a Layer of Security – TLS Handshake

Since we used https://, there’s another handshake: the Transport Layer Security (TLS) handshake. This explains:

The server presents a certificate to prove “I am who I say I am.”
Browser and server agree on encryption keys so the data transfer is private and secure.

Once that’s done, your browser and the server can talk securely.

Step 5: Making the Request – The HTTP Request

Now we’re ready. Your browser says something like:

“Server at the IP I found, please send me your homepage.”

That’s an HTTP request (Hypertext Transfer Protocol). If you’re curious, check this link: HTTP Requests and Responses: A Beginner’s Guide
And a more canonical source: MDN – HTTP Messages

The request includes:

Method (GET, POST, etc)
Path (which page or resource)
Headers (browser type, language, cookies)
Possibly a body (for POST requests)

Step 6: Server Response – The HTML Arrives

The server processes your request and sends back an HTTP response. It includes:

A status code (200 = OK, 404 = Not Found, etc.)
Response headers (type of content, caching rules, etc)
The body (which, for our case, is the HTML of the Google homepage) You can explore What is HTTP? – W3Schools for details.

Step 7: Rendering – Painting the Page

Your browser now has a blueprint (the HTML, CSS, JS, images…) and it starts building:

Parse the HTML to build the DOM (Document Object Model).
Parse CSS to figure out layout and styles.
Run JS to add interactivity.
Download images/fonts/videos as needed.
Render all of this visually so you see the page.

This is where the magic of “appears instantly” happens.

Step 8: Optimization, Caching & the Background Work

Even after you see the page, work continues:

The browser caches resources (so next time it'll load faster).
DNS entries may be kept in cache too.
The server might have chosen a data-centre close to you (via load-balancing/CDNs) so the journey was short. These optimisations are why websites feel snappy.

Step 9: Click, New URL, Repeat

When you click a link or type another URL, the process essentially repeats — but thanks to caching and persistent connections, parts of it are faster now.

Final Thought

Typing a URL is deceptively simple. Under the hood it triggers a global ballet of protocols, machines, translation services and security layers, so you can get your webpage, often within milliseconds. Next time a page loads with no hiccup, take a moment to appreciate how many invisible actors just did their job.

Your SSR Isn’t Fast — Hydration Is Dragging It Down

Ishan Bagchi — Sun, 09 Nov 2025 20:32:25 +0000

Imagine you’re on a slow mobile network, scrolling through the news on your phone. The page loads instantly — text, images, layout all appear right away. Visually, it seems ready. You tap “Read more.”

Nothing happens.

A second tap. Still nothing. Then suddenly the page springs to life and behaves normally.

What you just experienced is the hidden cost of hydration — the process modern frameworks use to “wake up” server-rendered HTML in the browser. It’s clever, it has served us well, but it’s far from lightweight.

This article explores why hydration is computationally expensive and how partial hydration offers a more efficient path forward.

Understanding Hydration

Server-side rendering (SSR) allows users to see the interface immediately by delivering HTML first. However, HTML on its own is static — it cannot handle clicks, form inputs, or interactive components.

Hydration is the browser’s process of:

Downloading the JavaScript bundle
Parsing and executing it
Rebuilding the UI tree in memory
Matching it to the existing DOM
Attaching event listeners and restoring state

In simple terms, the browser receives a fully-rendered page, but then re-renders the application internally to attach behavior. The UI looks complete, but it’s not truly functional until hydration finishes.

Why Hydration Is Expensive

Hydration introduces performance overhead because the browser ends up doing more work than necessary. It renders the UI twice — first on the server for visual output, then again on the client to attach interactivity — and that cost becomes noticeable as applications scale.

1. Large JavaScript Bundles

Even though the HTML arrives fully rendered, hydration still requires sending down the entire JavaScript bundle responsible for building the UI.

This includes framework code, component logic, routing, state management, and event handlers — essentially the same resources a client-side SPA would load.

So instead of “SSR saves work,” you're shipping HTML and a full client runtime.

More JavaScript means:

Higher network transfer impact (especially on slow or unstable networks)
Longer download and decompression time
More memory usage right after page load

SSR gets pixels on the screen faster, yes — but hydration delays when those pixels become useful.

2. Heavy CPU Work

Once downloaded, the browser must parse, compile, and execute the JavaScript — and that’s where the CPU load hits.

Parsing and executing JavaScript isn't free. It blocks the main thread, the same thread responsible for:

Animations
Scrolling
Input responsiveness
Layout and paint operations

On modern laptops, this cost may feel small. On mid-range Android phones or older devices, it's painful. A page that looks ready turns sluggish simply because JavaScript hasn’t finished bootstrapping yet.

3. Duplicate Rendering Work

SSR gives the browser a complete DOM tree. But hydration doesn’t reuse that DOM directly.
The framework rebuilds its virtual component tree in JavaScript, reconciles it, and then attaches behaviors to the existing DOM nodes.

It’s like assembling the same puzzle twice — once on the server and once inside the user's device — just to verify the pieces fit.

That duplicated effort wastes:

CPU cycles
Memory
Startup time

The UI is already there — the browser just has to re-understand it.

4. Hydrating Everything, Even Static Content

Traditional hydration approaches treat every part of the page as potentially interactive. The framework walks through the entire DOM — even sections that will never change or respond to input.

Static blocks like:

Article text
Footer content
Product descriptions
Banner images

all get swept into the hydration process simply because they live inside a component tree.

This is equivalent to activating every circuit in a building even if most rooms won’t be used.

Most pages don’t need to hydrate 100% of their UI, yet traditional hydration does exactly that.

5. Delayed Interactivity and Perceived Lag

Until hydration completes, the interface is visually present but functionally incomplete. Buttons exist, but they may not respond. Input fields appear ready, but keystrokes don’t register immediately.

This gap between first paint and usable interface damages user trust.

Developers see it as a “hydration window.”
Users see it as:

“The site is slow”
“This button doesn’t work”
“Is my phone freezing?”
“Why hasn’t the menu opened yet?”

It affects core metrics like Time to Interactive (TTI) and Interaction to Next Paint (INP), and ultimately shapes how users perceive your product.

The Bottom Line

Hydration solves an important problem — fast HTML rendering with rich interactivity — but it does so by making the browser redo work it already received from the server.

The result: pages that arrive fast, but become usable slowly.

Partial hydration and modern approaches aim to cut out this redundancy, enabling only the parts that truly need JavaScript to hydrate — and only when necessary.

Partial Hydration: A More Targeted Approach

Partial hydration addresses this problem by only hydrating components that truly need interactivity.

Instead of rehydrating the entire page, the browser focuses on smaller, isolated “islands” of interactive functionality — like navigation menus, search bars, or carousels — while leaving static content untouched.

Benefits include:

Less JavaScript sent to the browser
Reduced CPU usage and faster processing
Faster time-to-interactive (TTI)
Better performance on low-end devices
A more efficient rendering pipeline overall

In other words, the browser hydrates only where necessary, rather than everywhere by default.

Real-World Adoption

Many modern frameworks are embracing this model:

Astro: Islands architecture, zero-JS by default
Qwik: Resumability — skips hydration entirely
SvelteKit: Compiles away much runtime overhead
Next.js (App Router): Server components reduce hydration scope
Solid: Extremely fine-grained, selective hydration

The trend is clear: ship less JavaScript, hydrate less, and push more execution back to the server.

The Shift in Frontend Thinking

For years, the industry moved toward increasingly complex client-side JavaScript. We treated the browser as the primary execution environment.

That tide is turning.

The new direction emphasizes:

Minimal client-side JavaScript
Server-driven interfaces
Progressive enhancement
Distributed and selective interactivity

The goal isn’t to remove interactivity — it’s to be strategic about where it’s needed.

Conclusion

Hydration was an essential stepping stone in modern web architecture. It allowed us to combine server-rendered speed with client-side richness. But as applications grow and devices vary widely in capability, we can no longer afford to hydrate everything by default.

Partial hydration — and the evolution beyond it — reflects a smarter, more efficient approach:

Deliver the UI quickly.
Hydrate only what the user interacts with.
Avoid unnecessary work in the browser.

It’s a shift toward performance, practicality, and user-first engineering — a cleaner and more sustainable direction for the future of frontend development.

Real-Time Chart Updates: Using WebSockets To Build Live Dashboards

Ishan Bagchi — Sat, 08 Nov 2025 18:34:40 +0000

Imagine you're glued to your laptop, watching the final seconds of a live auction. Bids shoot up every second. You're sweating, hovering over the button, waiting for the latest price. But instead of seeing updates instantly, you keep smashing refresh like it's 2007. By the time the price changes, someone else has already won.

That used to be the reality of real-time data on the web.

Before WebSockets, the browser had one way to stay updated: keep asking the server every few seconds. Polling. It worked, but barely. It was wasteful, slow, and honestly, a little embarrassing for the modern web.

Then WebSockets showed up in 2011 and flipped the script. A persistent connection. Two-way communication. Real-time data without spammy refresh loops. Suddenly the web could behave more like a trading terminal and less like a fax machine.

If you're building dashboards, analytics tools, gaming UIs, IoT displays, or anything that needs to update the moment data changes, WebSockets become your best friend.

Let’s walk through how this works and how you can get started.

Why Real-Time Matters

A dashboard that updates once every 10 seconds isn’t a dashboard — it’s a slideshow.

The modern expectation is instant feedback. Crypto charts moving by the millisecond. Social analytics ticking up in real time. Live order books, multiplayer game states, collaborative editors… the web feels alive now.

To keep up, we need tech that streams information continuously, not drip-feeds it through constant HTTP requests.

That’s where WebSockets shine. You open one connection and keep it open. No more “Hey server, any updates? No? Okay see you in 3 seconds.”

How WebSockets Actually Work

The simplest way to explain it:

Browser knocks on server’s door saying: “Let’s stay connected.”
Server agrees.
Now both can talk whenever they want — no repeated knocking.

It’s basically a WhatsApp call between client and server instead of sending texts every few seconds asking “You there?”

A Tiny Example

Let's keep this simple and build the smallest real-time setup we can — no frameworks, no fancy tooling. Just a server sending numbers and a browser receiving them. Once you see the basic flow, scaling it up becomes way less intimidating.

Backend (Node.js)

const WebSocket = require('ws');

const server = new WebSocket.Server({ port: 8080 });

server.on('connection', socket => {
  console.log('Client connected');

  setInterval(() => {
    const price = (Math.random() * 100).toFixed(2);
    socket.send(JSON.stringify({ price }));
  }, 1000);
});

Frontend

const socket = new WebSocket('ws://localhost:8080');

socket.onmessage = (event) => {
  const data = JSON.parse(event.data);
  updateChart(data.price);
};

Cool, so now we've got a data stream. Next question — what do we do with it? Most of the time, we’re not printing raw numbers to the console… we’re visualizing them.

Updating Charts in Real-Time

Now comes the fun part — charts.

Libraries like:

Chart.js
Highcharts
Plotly
Recharts (if you're working in React)
Apache ECharts

All support dynamic updates.

Example using Chart.js:

function updateChart(price) {
  myChart.data.labels.push(Date.now());
  myChart.data.datasets[0].data.push(price);

  if (myChart.data.labels.length > 100) {
    myChart.data.labels.shift();
    myChart.data.datasets[0].data.shift();
  }

  myChart.update('none');
}

A couple of pro tips you’ll thank yourself for later:

Trim old data — browsers don't love 10,000 live points sitting around.
Skip animations for real-time speed.
Sync with requestAnimationFrame if updates are rapid.

But What Happens When The Connection Drops?

Because it will drop. Networks aren't perfect, servers restart, people switch Wi-Fi.

Reconnect logic saves you here:

function connect() {
  const socket = new WebSocket('ws://localhost:8080');

  socket.onclose = () => {
    console.log('Disconnected. Reconnecting...');
    setTimeout(connect, 2000);
  };

  socket.onerror = () => socket.close();
}

connect();

Silent recovery = happy users.

Security Matters Too

A persistent connection means persistent risks if you're careless. Keep things safe:

Use wss:// instead of ws://
Validate tokens before opening a socket
Sanitize incoming messages (browser can receive data too!)
Disconnect inactive or abusive clients
Never trust client input — ever

WebSockets give power. Power attracts trouble.

Optimizing Data Flow

Real-time doesn’t mean “blast the browser 1000 times a second”. Be thoughtful:

Send only changes, not entire data dumps
Consider binary formats like Protocol Buffers, MessagePack, FlatBuffers
Compress where it makes sense
Batch updates if single-tick precision isn’t needed

Real-time is more about perception than raw throughput.

If a user can't tell the difference between 50 updates/second and 5 updates/second, choose 5.

Less noise, more clarity.

Wrapping Up

WebSockets took the web from “refresh to see updates” to “updates arrive before you blink”. With a small learning curve and a massive payoff, they're one of those tools every modern developer should have in their kit.

The moment you see your first chart move in real time without a refresh, it's hard to go back.

Build something live. Stream something. Turn data into motion. It's a little addictive — in a good way.

Dark Patterns in Modern Web UX: The Subtle Manipulations We Fall For Every Day

Ishan Bagchi — Mon, 08 Sep 2025 20:48:21 +0000

The web is full of clever designs that nudge us to click, sign up, or buy things we didn’t originally intend to. Some of these are smart UX choices. Others? They fall into the murky world of dark patterns, design tactics crafted to manipulate rather than guide.

The tricky part is that most people don’t even notice when they’re being steered. Let’s break down some of the most common modern dark patterns, with real-world examples and illustrative mockups.

1. The “Free Trial” That Isn’t Free

You sign up for a free trial, thinking you’ll cancel before the billing date. Except the cancellation button is buried behind multiple menus, or worse, you have to call customer support to cancel. The design isn’t broken—it’s intentional friction.

Example: Streaming platforms and SaaS products that make cancelation a multi-step scavenger hunt.
Why it works: Most people procrastinate or get frustrated midway, meaning the company earns another billing cycle.

2. Confirmshaming

This is when the “No” option in a modal is phrased to guilt-trip you. Instead of “No thanks,” you’re faced with something like: “No, I don’t care about saving money.”

Example: Pop-ups on e-commerce sites pushing for newsletter sign-ups with insulting declines.
Why it works: Guilt is a strong motivator. Even if users don’t sign up, they remember the emotional sting.

3. Disguised Ads

Ads that look like regular content, download buttons, or navigation links. You click thinking you’re moving forward in your task, only to land on an ad page.

Example: File-sharing sites with multiple green “Download” buttons, only one of which actually works.
Why it works: Visual misdirection. Humans scan for familiar shapes and colors, and advertisers exploit that.

4. Forced Continuity

This one’s sneaky: you sign up with your card details for something “free,” but the charges start without warning and there’s no clear reminder before renewal.

Example: Subscription apps where “trial” silently rolls into payment without upfront alerts.
Why it works: Inattention. Users forget dates, and companies design it that way.

5. Roach Motel

It’s easy to get in, but painfully hard to get out. Sign-ups are one-click, but cancelations require email confirmations, hidden menus, or long waiting periods.

Example: Gym memberships are the offline equivalent, but plenty of apps do this too.
Why it works: Sunk cost fallacy. Users who’ve invested time are more likely to stay, even unhappily.

6. Misdirection with Design

A button styled to draw your eye toward the less favorable option. For example, a bright, bold “Accept All” cookie button versus a faint, gray link for “Manage Preferences.”

Example: Cookie consent banners across Europe post-GDPR.
Why it works: Eye-tracking studies show people instinctively click the boldest, brightest option.

7. Hidden Costs

You’re about to check out, but in the final step, extra fees appear: service charges, “convenience” fees, or unexplained surcharges.

Example: Ticketing websites that add “processing fees” just before you pay.
Why it works: Users are already invested and less likely to abandon after spending time filling carts.

8. Social Proof Manipulation

You see “100 people are viewing this right now” or “Only 2 left in stock.” Sometimes true, often fake. It creates artificial urgency.

Example: Travel booking sites showing “5 people booked this room in the last hour.”
Why it works: Fear of missing out (FOMO) drives quick, less rational decisions.

Why Dark Patterns Persist

Dark patterns survive because they work. They exploit human psychology—loss aversion, FOMO, laziness, and guilt. For businesses, the short-term gains are obvious: higher conversions, more subscriptions, fewer cancellations.

But the long-term cost is trust. Users who feel tricked don’t just leave; they tell others. Entire Reddit threads and Twitter storms exist just to call out shady UX practices.

Designing Without the Darkness

Not all nudges are bad. Encouraging users to finish onboarding, making checkout smoother, or highlighting safer options are good UX nudges. The difference is intent: are you helping users succeed, or tricking them into something they didn’t want?

A transparent, ethical design might not maximize conversions overnight, but it builds loyalty. In an era where trust is currency, that’s worth far more.

Closing Thoughts

The next time you see a “limited time offer” or feel suspiciously guilty clicking “No thanks,” pause and ask yourself: Is this helping me, or manipulating me?

Dark patterns thrive on invisibility. By naming and recognizing them, we take back some control. And if you’re a designer or developer; remember, you’re shaping not just clicks, but trust.

Event Bubbling and Capturing in JavaScript: The Complete Guide

Ishan Bagchi — Fri, 05 Sep 2025 22:27:04 +0000

Click a button inside a div inside a section, and suddenly JavaScript has a choice to make: which element should handle the event first?

That journey, where an event travels through layers of the DOM before and after reaching its target, is called event propagation. If you’re writing modern JavaScript, understanding this flow isn’t optional. It’s the difference between code that “just works” and code that’s clean, predictable, and easy to extend.

Let’s walk through it.

What is Event Propagation?

Every time you click, press a key, or interact with the DOM, the event doesn’t just “happen” on the element you touched. Instead, it follows a path through the DOM tree in a well-defined order.

Propagation has three phases:

Capturing Phase (Event Capture)
The event starts from the top (document → html → body → …) and travels downward until it reaches the target.
Target Phase
The event lands on the actual element you interacted with (like a button or link).
Bubbling Phase (Event Bubble)
The event then travels back upward from the target, through its ancestors, until it returns to the top of the tree.

Here’s a visual that shows the entire journey:

In this diagram:

The straight arrows down the middle represent the capturing phase, where the event travels from the top of the DOM (document, html, body, section, p) down to the actual target element (a).
The yellow box around the <a> element shows the target phase, the point where the event has reached the clicked element itself.
The curved red arrows on the right represent the bubbling phase, where the event moves back up through the ancestors of the target (p → section → body → html → document).

Event Bubbling

Most events in JavaScript bubble by default. That means the event fires on the target element first, then climbs back up to its ancestors.

Example: Bubbling in Action

<div id="parent" style="padding: 20px; background: lightblue;">
  Parent Div
  <button id="child">Click Me</button>
</div>

<script>
  document.getElementById("parent").addEventListener("click", () => {
    console.log("Parent Div clicked");
  });

  document.getElementById("child").addEventListener("click", () => {
    console.log("Button clicked");
  });
</script>

If you click the button:

The button logs: “Button clicked”.
Then the parent logs: “Parent Div clicked”.

That’s bubbling in action: the event bubbles up from the child to its parent.

Event Capturing

Capturing is the opposite direction: the event is “caught” on its way down before it even hits the target.

To listen during the capture phase, pass a third argument (true) to addEventListener.

Example: Capturing in Action

<div id="parent" style="padding: 20px; background: lightgreen;">
  Parent Div
  <button id="child">Click Me</button>
</div>

<script>
  document.getElementById("parent").addEventListener(
    "click",
    () => {
      console.log("Parent Div captured the click");
    },
    true // Enable capturing
  );

  document.getElementById("child").addEventListener("click", () => {
    console.log("Button clicked");
  });
</script>

Clicking the button now produces:

“Parent Div captured the click” (captured on the way down).
“Button clicked” (target phase).

Stopping Propagation

Sometimes you don’t want the event to keep traveling, like when a modal’s background is clickable, but you don’t want the click to close the modal if it happens inside the modal itself.

JavaScript gives you two tools:

event.stopPropagation() → halts further travel up or down the DOM tree.
event.stopImmediatePropagation() → does the same but also prevents other handlers on the same element from firing.

Example

child.addEventListener("click", (event) => {
  console.log("Button clicked");
  event.stopPropagation(); // Parent won’t log anything
});

Why Does This Matter?

This isn’t just academic detail, it’s practical.

Event Delegation: Instead of adding a click listener to every li in a list, you attach one listener to the ul and let bubbling tell you which li was clicked. This saves memory and simplifies code.
Global Interception: Capturing lets you intercept events before they reach their targets, useful for logging, blocking certain actions, or building frameworks.
Cleaner Modals & Dropdowns: Controlling propagation prevents accidental clicks from closing UI components.

Propagation is the backbone of nearly every advanced UI pattern you’ve used on the web.

Recap

Events flow in three phases: capture → target → bubble.
Browsers default to bubbling unless you explicitly use capturing.
Use true in addEventListener to listen in the capturing phase.
Use stopPropagation() when you want to contain the event.

Closing Thought

Every time you click a button, JavaScript isn’t just running your handler,it’s walking that event through the DOM, like a courier making stops along a delivery route. Mastering event bubbling and capturing means you’re not just reacting to clicks; you’re controlling the journey itself.

Once you internalise this, features like event delegation, modals, and complex UI interactions stop feeling like hacks, and start feeling like extensions of the DOM’s natural flow.

Creating Arrays of Arrays (Nested Arrays) in JavaScript: Common Pitfalls and Best Practices

Ishan Bagchi — Fri, 01 Aug 2025 20:45:27 +0000

Working with arrays of arrays—often referred to as "nested arrays" or "2D arrays"—is a common requirement in JavaScript when dealing with matrices, grids, or tabular data. However, the way we initialize these structures can introduce subtle bugs if we’re not careful! In this post, we’ll walk through the right and wrong ways to create arrays of arrays in JavaScript, explain why certain pitfalls occur, and show you best practices for robust code.

The Basic Case: Hardcoding Nested Arrays

Suppose we want to create a simple nested array with two empty arrays:

const arr = [[], []];

This works perfectly if you know the number of inner arrays in advance. Each sub-array is independent, and you can safely push data into one without affecting the other.

The Dynamic Case: Creating a Random-Length Array of Arrays

What if you don’t know ahead of time how many inner arrays you need? For example, suppose you want to create an array of len empty arrays, where len is determined at runtime.

A common first attempt might look like this:

const len = 5; // Suppose len is 5
const arr = new Array(len).fill([]);

At first glance, this seems reasonable: new Array(len) creates an array with len empty slots, and .fill([]) fills each slot with an empty array.

The Hidden Trap: Shared References

However, this approach can cause unexpected behavior! The problem is that .fill([]) fills every slot with the same array instance:

const arr = new Array(3).fill([]);
arr[0].push(1);
console.log(arr); 
// Output: [[1], [1], [1]]

Uh-oh! When you modify arr[0], you end up modifying every sub-array, because all elements of arr point to the exact same array in memory.

This happens because in JavaScript (and many other languages), arrays and objects are reference types. The value [] is a reference to a specific array object, and fill([]) copies that reference into every slot.

The Solution: Create a New Array for Each Slot

To avoid this, you should create a new empty array for each position. You can do this using .map() or .from():

Using `Array.from()`

const len = 5;
const arr = Array.from({ length: len }, () => []);

Here, the second argument to Array.from is a mapping function that returns a new empty array for each slot, so each sub-array is unique.

Using `.map()` (after `.fill()`)

Alternatively, you can chain .map() after .fill():

const len = 5;
const arr = new Array(len).fill().map(() => []);

new Array(len).fill() creates an array of len undefineds.
.map(() => []) replaces each undefined with a new array.

Demonstration

const arr = Array.from({ length: 3 }, () => []);
arr[0].push(1);
console.log(arr); 
// Output: [[1], [], []]

Now, each inner array is independent!

Summary Table

Approach	Are sub-arrays independent?	Example Output
`[[], []]`	Yes	`[[1], []]` (after `arr[0].push(1)`)
`new Array(len).fill([])`	No (shared reference)	`[[1], [1], [1]]`
`Array.from({length: len}, () => [])`	Yes	`[[1], [], []]`
`new Array(len).fill().map(() => [])`	Yes	`[[1], [], []]`

Key Takeaways

Don’t use .fill([]) to create nested arrays—you’ll end up with shared references!
Use Array.from({ length: n }, () => []) or .map(() => []) to ensure each sub-array is unique.
Remember: objects and arrays in JavaScript are reference types. Assignment or .fill() with an object/array copies the reference, not the value.

Real-World Example: Initializing a 2D Matrix

Suppose you want a 5x5 grid of zeros:

const size = 5;
const matrix = Array.from({ length: size }, () =>
  Array.from({ length: size }, () => 0)
);
console.log(matrix);

Each row and each cell is independent—perfect for grid-based algorithms, games, or spreadsheets!

Conclusion

While it’s easy to create arrays of arrays in JavaScript, it’s just as easy to fall into the shared reference trap with .fill([]). By understanding how references work and initializing each sub-array independently, you’ll write safer, more predictable code.

Happy coding!

The Tiny Symbols That Can Break Your App: ^ vs ~ in package.json

Ishan Bagchi — Sun, 15 Jun 2025 13:44:52 +0000

If you've ever opened a package.json file and wondered what those mysterious ^ and ~ symbols before version numbers mean, you're not alone. They might look innocent, but these tiny symbols can cause unexpected bugs, broken builds, and production headaches.

Let’s understand the difference between ^ and ~, and uncover how they can become hidden traps in your JavaScript/TypeScript projects.

📦 The Basics: What Do `^` and `~` Mean?

In a package.json, these symbols are used for semantic versioning (semver), a way of defining compatible versions for dependencies.

✅ `^` (Caret)

Example: "react": "^18.2.0"
Meaning: Accept minor and patch updates, but not major.
Range: >=18.2.0 <19.0.0

It updates your package to the latest version within the same major version.

✅ `~` (Tilde)

Example: "react": "~18.2.0"
Meaning: Accept patch updates only, not minor or major.
Range: >=18.2.0 <18.3.0

⚠️ Why It Matters: The Hidden Dev Trap

Let’s say you’re working in a team, and your teammate installs a package with ^. A few weeks later, a new minor version is released; maybe with a breaking change (yes, that happens even when it shouldn’t). Now, your teammate’s environment works differently than yours, and your build breaks.

This is what we call a "dependency drift."
You didn’t change the code, but it broke anyway. That’s the hidden trap.

💡 When to Use What

Symbol	Use Case	Pros	Cons
`^`	Rapid development / libraries	Gets bug fixes & features	Might introduce breaking bugs
`~`	Production apps	Safer, more predictable	Slower adoption of new features
None (exact version)	Mission-critical builds	Fully stable	No updates unless changed manually

🧰 Pro Tips

Use a lockfile (package-lock.json, yarn.lock, etc.) – Always commit it to avoid version inconsistencies across environments.
Use npm ci instead of npm install in CI – It strictly follows the lockfile.
Run regular audits – Tools like npm audit or yarn audit help spot issues early.
Consider ~ for critical packages like react, express, nestjs, etc., where stability is more important than frequent updates.

🧪 A Real-World Example

// package.json
{
  "dependencies": {
    "axios": "^1.4.0"
  }
}

A week later, 1.5.0 is released, and it slightly changes request behavior. Your staging build starts failing. If you'd used ~1.4.0, you’d have avoided this until explicitly updating.

🧵 Final Thoughts

Those tiny ^ and ~ symbols can make or break your app, literally. Don’t just copy-paste dependencies blindly. Understand them. Choose wisely based on your project type and stability needs.

If you’ve ever been bitten by a surprise update, share your story. Let's make dependency management less of a minefield for everyone.

🙌 Found this helpful?

If this saved you from future bugs, consider giving it a share or following me for more web dev tips.
Have questions? Drop them in the comments, I’d love to hear your thoughts!

ESLint is Dead, Long Live Biome?

Ishan Bagchi — Sun, 25 May 2025 08:14:05 +0000

In the world of JavaScript and TypeScript development, ESLint has long been the undisputed champion of linting. For over a decade, it has helped developers catch bugs, enforce style consistency, and ensure code quality across teams and open-source projects. But in 2025, a new contender is shaking the foundations of frontend tooling: Biome.

So, is ESLint really dead? And what makes Biome worthy of replacing it?

Let's dig in.

What is Biome?

Biome is an all-in-one toolkit for formatting, linting, and more. Developed by the same minds behind Rome (a now-discontinued full-stack JavaScript toolchain), Biome is laser-focused on performance, speed, and simplicity. It's written in Rust, making it blazing fast compared to its JavaScript-based counterparts.

Key Features of Biome:

Built-in Formatter (like Prettier)
Built-in Linter (like ESLint)
Zero Config Setup
Rust-powered speed
Typed lint rules with native TypeScript support
Single binary, zero dependencies

Why Are Devs Moving Away from ESLint?

While ESLint is powerful and deeply entrenched in modern JS tooling, it's also become complex and fragile:

Plugin Hell: ESLint setups often depend on a forest of plugins and shared configs. Conflicts are common, especially with newer frameworks or language features.
Performance: Written in JavaScript, ESLint can feel sluggish on large codebases.
Toolchain Overload: Many projects use ESLint for linting, Prettier for formatting, and TypeScript for type-checking — leading to redundant rules, duplicated effort, and slow CI pipelines.

How Biome Solves These Problems

Biome’s core philosophy is to reduce complexity and boost performance:

No more plugin juggling — Biome ships with sensible defaults.
The formatter and linter share a unified AST, avoiding conflicts.
It processes both JS and TS natively, without needing separate configs.
Being written in Rust, it's lightning-fast, even on large monorepos.

In-Depth Cool Features of Biome:

1. Autofix on Save by Default

Biome comes with powerful autofix capabilities that trigger automatically. No need to configure extra scripts — it just works.

2. Integrated Project Linting

Biome is aware of your project context — meaning it can lint based on workspace rules, project structure, and TS config with minimal setup.

3. High Parallelization

Thanks to Rust’s concurrency model, Biome can lint and format files in parallel with blazing speed, outperforming JS-based tools even on multicore systems.

4. JSON & TOML Support

Beyond JS and TS, Biome also supports linting and formatting for JSON and TOML files, making it a true monorepo-friendly tool.

5. Built-in CI Reporter

Biome offers built-in CI-friendly output formats and summary flags to cleanly integrate with your pipeline logs without third-party tooling.

6. No Need for Prettier

Biome’s built-in formatter provides deterministic formatting without needing to pair it with Prettier — eliminating a major point of friction.

7. Actionable, Fixable Suggestions

Biome doesn't just show you problems — it fixes them safely. Take this real-world example:

complexity/useFlatMap.js:2:1 lint/complexity/useFlatMap  FIXABLE

  ✖ The call chain .map().flat() can be replaced with a single .flatMap() call.

    1 │ const array = ["split", "the text", "into words"];
  > 2 │ array.map(sentence => sentence.split(' ')).flat();
      │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    3 │

  ℹ Safe fix: Replace the chain with .flatMap().

    1  │ const array = ["split", "the text", "into words"];
    2  │ - array.map(sentence => sentence.split(' ')).flat();
       │ + array.flatMap(sentence => sentence.split(' '));
    3  │

This level of feedback, combined with inline fix previews, makes Biome feel less like a linter and more like a coding assistant.

Biome vs ESLint + Prettier

Feature	ESLint + Prettier	Biome
Setup Time	Moderate to High	Very Low
Config Complexity	High	Low
Performance	Moderate	High (Rust)
Plugin Dependency	High	None / Built-in
Formatting Support	Separate tool (Prettier)	Built-in
TS Integration	Indirect (via parser)	Native
JSON/TOML Support	Limited	Built-in
Fix Suggestions	Varies	Safe, Built-in, Inline

Is It Ready for Production?

As of mid-2025, Biome is stable and production-ready for many use cases. Major projects are adopting it — especially those that value fast CI pipelines and simple developer onboarding. However, there are still some caveats:

ESLint still offers more mature plugin ecosystems, especially for niche frameworks.
If your team has heavy custom rule requirements, Biome might still be catching up.
Migrating an existing ESLint setup may take some tweaking.

Should You Switch?

Here’s a quick decision guide:

Use Biome If...	Stick with ESLint If...
You're starting a new project	You rely on advanced, custom lint rules
You want a fast, single-tool setup	You need specific ESLint plugins
Your team prefers convention over config	You have deeply integrated ESLint workflows
You’re working with JSON/TOML formats	You rely heavily on ESLint plugin ecosystem
You want smart autofixes and reports	Your team has invested heavily in ESLint

Final Thoughts

Biome represents the next wave of frontend tooling — fast, unified, and zero-config. While ESLint isn’t dead (yet), it’s no longer the only serious player in the game. If Biome’s growth continues and its ecosystem expands, it could very well become the new standard in JavaScript linting.

So, is ESLint dead?

Not quite.

But the future? It might just be Biome.

Have you tried Biome yet? Share your experience with the community — or tell us why you're still team ESLint.

Forem: Ishan Bagchi

The Scheduler API: Prioritising Work on the Main Thread

Why The Old Solutions Fall Short

setTimeout(fn, 0) — The Classic Lie

requestIdleCallback — The Right Idea, Wrong API

requestAnimationFrame — The Wrong Abstraction

The Scheduler API

Priority Levels

Choosing the Right Priority

scheduler.postTask() Returns a Promise

Aborting Tasks with TaskController

Changing Priority Dynamically

Delaying Tasks

A Practical Pattern: The Task Queue with Chunking

Composing with React

How This Relates to React's Concurrent Mode

Feature Detection and Fallbacks

When Not to Reach For This

The Takeaway

Building a Table of Contents Sidebar Without a Library

The Shape of the Thing

The HTML

The Sticky CSS

The JavaScript

Why IntersectionObserver, Not a Scroll Listener

The Scroll Offset Fix

The Result

Breaking Free from the Render Cycle: Event-Driven Frontend Architecture

The Native Solution: CustomEvent

1. Building a Type-Safe Event Bus

2. Broadcasting an Event (Publisher)

3. Subscribing to the Event (Consumer)

When This Pattern Works Well

Independent Dashboard Widgets

Toast Notifications

Cross-Framework Communication

Tradeoffs to Consider

Harder Debugging

Event Overuse

The Takeaway

AI in Frontend Development: The New Copilot

1. Writing CSS Like Magic

AI-Powered CSS Generation

2. Generating Components on the Fly

Design-to-Code Revolution

Example:

3. UX Optimization Through Intelligence

AI-Driven UX Insights

Conversational UX

4. Personalization: The Next Big Leap

5. The Human Touch Still Matters

6. How to Leverage AI in Your Workflow

Final Thoughts

What Actually Happens When You Type a URL in the Browser?

Step 1: The URL — Your Digital Address

Step 2: DNS – The Internet’s Phonebook

Step 3: Establishing a Connection – TCP Handshake

Step 4: Adding a Layer of Security – TLS Handshake

Step 5: Making the Request – The HTTP Request

Step 6: Server Response – The HTML Arrives

Step 7: Rendering – Painting the Page

Step 8: Optimization, Caching & the Background Work

Step 9: Click, New URL, Repeat

Final Thought

Your SSR Isn’t Fast — Hydration Is Dragging It Down

Understanding Hydration

Why Hydration Is Expensive

1. Large JavaScript Bundles

2. Heavy CPU Work

3. Duplicate Rendering Work

4. Hydrating Everything, Even Static Content

5. Delayed Interactivity and Perceived Lag

The Bottom Line

Partial Hydration: A More Targeted Approach

Real-World Adoption

The Shift in Frontend Thinking

Conclusion

Real-Time Chart Updates: Using WebSockets To Build Live Dashboards

Why Real-Time Matters

How WebSockets Actually Work

`setTimeout(fn, 0)` — The Classic Lie

`requestIdleCallback` — The Right Idea, Wrong API

`requestAnimationFrame` — The Wrong Abstraction

`scheduler.postTask()` Returns a Promise

Aborting Tasks with `TaskController`

The Native Solution: `CustomEvent`

Using `Array.from()`

Using `.map()` (after `.fill()`)

📦 The Basics: What Do `^` and `~` Mean?

✅ `^` (Caret)

✅ `~` (Tilde)