Forem: Byte-Sized News

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.

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.

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.

Prompt. Generate. Ship. The Rise of Vibe Coding in 2025

Ishan Bagchi — Thu, 10 Apr 2025 21:12:13 +0000

“Describe what you want. The AI writes the code. You test and iterate.”

— Andrej Karpathy, 2025

What if you could build full features by just describing them in natural language? That’s not the future — that’s vibe coding, and it’s already reshaping how developers work.

In this post, let’s unpack what vibe coding is, how it works, the tools behind it, and what it means for the future of software development.

🤔 What Is Vibe Coding?

Coined by Andrej Karpathy, vibe coding refers to a new workflow where developers guide AI models to write code through iterative prompting.

It’s not just autocomplete. You describe what you want — UI components, APIs, logic — and the AI responds with working code. You then test it, adjust your prompt, and repeat until it clicks.

🧪 How It Works

Here’s what a typical vibe coding session might look like:

You prompt:

“Build a React component that displays a weather forecast using OpenWeatherMap API.”
AI responds:

Provides a full React component with fetch logic.
You iterate:

“Add loading state. Now switch to Tailwind for styling.”
AI updates the code. You deploy. Done.

It’s a mix of pair programming and creative direction — powered by AI.

🛠️ Tools That Enable Vibe Coding

Here are some tools making vibe coding a daily habit for developers:

Tool	Description
Cursor	A code editor like VS Code, with deep LLM integration
ChatGPT / Gemini / Claude	Prompt-based assistants for generating and explaining code
Replit Ghostwriter	In-browser coding with AI assistance
Continue.dev	Open-source AI pair programmer for your local IDE

✅ Why Devs Are Adopting It

Vibe coding isn’t just a gimmick — it’s already boosting productivity and creativity:

🚀 Speed: Quickly prototype features, components, or scripts
🎨 Creativity: Focus more on architecture and UX
🧠 Learning: Great for understanding new libraries or concepts
🧼 Boilerplate relief: No more writing repetitive code blocks

It turns your thoughts into code — and makes programming feel less like manual labor and more like creative flow.

⚠️ Caveats & Cautions

Despite the hype, vibe coding has its pitfalls:

🧱 Brittle logic: LLMs can hallucinate or use outdated APIs
🕵️‍♂️ Trust issues: You still need to read, test, and understand the code
🔐 Security flaws: LLMs might write insecure or inefficient implementations
🧹 Debugging pain: It’s harder to debug something you didn’t write from scratch

Vibe responsibly: AI is your assistant, not your QA team.

🧑‍💻 The Dev's Role Is Evolving

In the world of vibe coding, the skillset of a developer is shifting:

Old World	Vibe World
Code everything yourself	Prompt, review, refine
Memorize syntax	Understand concepts
Debug boilerplate	Curate and guide AI output
Write all tests	Ask AI to help write them, then validate

You're no longer just a coder — you're a code director.

🔮 Final Thoughts: Is Vibe Coding the Future?

Absolutely — but it’s not a replacement for developers. It’s an augmentation.

Vibe coding amplifies your productivity and creativity, but your fundamentals, judgment, and ability to reason through problems are still irreplaceable.

This is not about coding less — it’s about coding smarter.

The future isn’t typing faster — it’s thinking better.

💬 What’s Your Take?

Have you tried vibe coding yet? Are you using tools like Cursor, Replit, or ChatGPT to write actual production code? Share your experience in the comments.

🚀 GitHub SSH & "Repo Not Found": The Mistake That Took Me a Bit Too Long to Debug

Ishan Bagchi — Fri, 04 Apr 2025 16:47:31 +0000

“Hi ishan1! You've successfully authenticated, but GitHub does not provide shell access.”

Sound familiar? It definitely did to me. 🙃

🧩 The Confusing Error

So here I was, just trying to clone a private repository called the-project from GitHub using SSH:

git clone git@github.com:some-org/the-project.git

And then this happened:

ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

At first, I thought:

Maybe I typed the repo name wrong.
Maybe it was deleted.
Maybe I lost access?

But nope — everything was perfectly fine on GitHub.

Just to be sure, I checked my SSH authentication:

ssh -T git@github.com

It replied:

Hi ishan1! You've successfully authenticated, but GitHub does not provide shell access.

Wait a second — ishan1? I was expecting ishan2 (the account that actually had access to the-project).

🤦 The Realization: SSH Was Using the Wrong GitHub Account

Turns out, my machine was authenticating with the wrong SSH key — the one tied to ishan1, my personal GitHub account, instead of ishan2, which was the one invited to collaborate on the private repository the-project.

So of course GitHub said “Repo not found” — from ishan1's perspective, it really didn’t exist!

🛠️ The Fix: Use the Right SSH Key for the Right GitHub Account

If you’re juggling multiple GitHub accounts like I am, here’s the fix that worked for me:

1. 🔐 Generate a new SSH key for the correct GitHub account (`ishan2`):

ssh-keygen -t ed25519 -C "ishan2@example.com" -f ~/.ssh/id_ed25519_ishan2

2. ➕ Add that key to your SSH agent:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_ishan2

3. 📋 Add the public key to the `ishan2` GitHub account:

cat ~/.ssh/id_ed25519_ishan2.pub

Then go to GitHub → Settings → SSH and GPG Keys → New SSH Key, and paste it there.

4. 🧠 Set up a custom SSH host in `~/.ssh/config`:

Host github-ishan2
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_ishan2

5. ✅ Clone the repo using the custom alias:

git clone git@github-ishan2:some-org/the-project.git

Boom 💥 — this time, the correct SSH key was used, the correct GitHub identity (ishan2) was applied, and access to the private repo worked just like that.

🎯 Lesson Learned

I used to treat SSH as a one-time setup. Turns out, if you're managing multiple GitHub identities (say, ishan1 for personal and ishan2 for work or freelance), your config needs to be smart about which key to use.

If you get the "Repository not found" error while cloning a private repo, ask yourself:

Which GitHub user is this SSH key connected to?
Is it the right one?
Do I need a custom ~/.ssh/config setup?

✍️ Final Thoughts

SSH is amazing… until it silently logs you in as the wrong person 😅

If this post saves even one other developer from scratching their head for 30 minutes — it’s a win.

Feel free to copy this setup and tweak the names for your own accounts. In my case, it was ishan1 vs ishan2, and a private repo called the-project. Yours might be different, but the fix remains the same.

Balancing Work and Learning: How to Keep Up With New Tech Without Overloading Yourself

Ishan Bagchi — Sun, 30 Mar 2025 18:25:54 +0000

The tech industry evolves at a breakneck speed, with new frameworks, languages, and best practices emerging constantly. As a developer, staying relevant requires continuous learning, but balancing this with work responsibilities (and a personal life) can feel overwhelming. So, how do you stay updated without burning out? Let's explore some practical strategies to manage both effectively.

1. Prioritize What to Learn

With an endless sea of new technologies, the key is to prioritize what is most relevant to your career and interests.

Assess Your Career Goals

Are you aiming for a promotion, a job switch, or deeper expertise in your current role?
Choose technologies that align with your goals rather than chasing every new trend.

Follow the 80/20 Rule

Focus on the 20% of technologies that will give you 80% of the impact.
If you’re a React developer, learning about performance optimization and server-side rendering might be more useful than dabbling in an entirely new framework.

2. Integrate Learning Into Your Work

Rather than separating learning and work, blend them together for efficiency.

Work on Real Projects

If your job allows, introduce new technologies into your current projects incrementally.
Example: If you want to learn TypeScript, start integrating it into small components in an existing JavaScript codebase.

Contribute to Open Source

Find an open-source project using the technology you want to learn and start contributing.
This provides hands-on experience while collaborating with the community.

3. Use Smart Learning Techniques

Make the most of the limited time you have.

Learn in Small, Consistent Chunks

Instead of trying to grasp an entire framework in a weekend, dedicate 30-60 minutes daily.
Use techniques like spaced repetition and active recall for better retention.

Leverage Online Resources Wisely

Follow high-quality newsletters, YouTube channels, and blogs.
Use platforms like Frontend Masters, Pluralsight, or Udemy for structured learning.
Podcasts are great for passive learning during commutes or workouts.

4. Avoid Burnout With a Structured Approach

Overloading yourself with too much learning can lead to burnout. Keep it balanced.

Set Realistic Learning Goals

Break down learning objectives into achievable steps.
Example: "Learn the basics of Go in 4 weeks" rather than "Master Go as quickly as possible."

Schedule Learning Sessions

Treat learning like an important meeting on your calendar.
Even 3 focused sessions per week can lead to steady progress.

Take Breaks & Unplug

The brain needs time to process new information.
Take breaks between learning sessions, and don’t feel guilty about taking days off from learning.

5. Engage With the Developer Community

Surrounding yourself with other learners and experienced developers can accelerate learning.

Join Developer Groups & Meetups

Engage with local or online communities (Discord servers, Reddit, LinkedIn groups, etc.).

Teach What You Learn

Write blogs, create tutorials, or explain concepts to a colleague.
Teaching reinforces learning and helps build credibility in the community.

6. Use AI & Tools to Accelerate Learning

AI and automation can help reduce the time spent searching for solutions.

Use AI Assistants

Tools like ChatGPT, GitHub Copilot, and Tabnine can help you learn faster by suggesting code snippets and explanations.

Automate Repetitive Tasks

Free up time by automating repetitive coding or deployment processes.
Example: Use CI/CD pipelines instead of manually deploying projects every time.

7. Find the Right Balance

At the end of the day, the goal is consistent progress, not perfection.

Recognize When to Slow Down

If learning feels like a chore, take a step back and reassess your approach.
It’s okay to pause and resume learning when you’re ready.

Celebrate Small Wins

Completed a course? Solved a bug using a new concept? Celebrate those moments!
Small wins keep motivation high and reinforce long-term learning habits.

Conclusion

Balancing work and continuous learning as a developer is challenging, but with the right approach, it’s absolutely manageable. Prioritize relevant skills, integrate learning into your work, pace yourself, and leverage the community. Most importantly, enjoy the process—because learning should feel exciting, not exhausting!

I Don’t Trust JavaScript. Here’s Why console.log("Hello") Returned undefined

Ishan Bagchi — Mon, 24 Feb 2025 17:56:06 +0000

As a developer, I’ve seen some bizarre things, but nothing made me question reality more than this:

console.log("Hello"); 
// Output: Hello
//         undefined

Wait… what? Why is JavaScript showing undefined after logging "Hello"? Did I break something? Is the universe glitching?

Turns out, JavaScript isn’t broken—it’s just JavaScript.

Why Does `console.log()` Return `undefined`?

1. `console.log()` Prints but Doesn't Return Anything

In JavaScript, console.log() outputs to the console but has no return value—so it returns undefined by default.

Example:

const result = console.log("Hello");
console.log(result); // undefined

Here, "Hello" gets printed, but console.log() itself doesn’t return anything useful—hence, result is undefined.

2. The Browser Console Reveals the Truth

When you type console.log("Hello") directly in the browser console, it prints "Hello" and then shows undefined as the return value:

Hello
undefined

The undefined isn’t part of console.log(). It’s just the console displaying what the function returned.

3. The "Return Trap" in Functions

If you call console.log() inside a function and log its output, you'll see the same behavior:

function sayHello() {
  console.log("Hello");
}

console.log(sayHello()); 
// Logs: Hello
// Then: undefined

Since sayHello() doesn't return anything, console.log(sayHello()) first prints "Hello" and then logs undefined.

4. When Things Get Weird: Overriding `console.log()`

For the truly paranoid, here’s how JavaScript can gaslight you:

console.log = () => undefined;
console.log("Hello"); // Nothing prints!

If console.log() is redefined (by accident or an evil teammate), it won’t even log anything. Now that’s a true nightmare!

Final Thoughts

JavaScript didn’t lie—it just has some quirks that make you question your sanity. console.log() is a tool for debugging, not for returning values. So next time you see undefined, just remember: it’s not a bug, it’s a feature.

Axios Cheat Sheet: A Quick Guide for Developers

Ishan Bagchi — Sun, 23 Feb 2025 07:45:28 +0000

Axios is a powerful and easy-to-use HTTP client for JavaScript, commonly used in frontend and backend applications for making HTTP requests. This cheat sheet covers the most commonly used features and best practices.

1. Installation

Install Axios using npm, yarn, or a CDN:

# Using npm
npm install axios

# Using yarn
yarn add axios

# Using a CDN
<script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script>

2. Making GET Requests

import axios from 'axios';

axios.get('https://jsonplaceholder.typicode.com/posts')
  .then(response => console.log(response.data))
  .catch(error => console.error(error));

3. Making POST Requests

axios.post('https://jsonplaceholder.typicode.com/posts', {
    title: 'Axios Cheat Sheet',
    body: 'This is a sample post request.',
    userId: 1
  })
  .then(response => console.log(response.data))
  .catch(error => console.error(error));

4. PUT and PATCH Requests

PUT replaces the entire resource:

axios.put('https://jsonplaceholder.typicode.com/posts/1', {
    title: 'Updated Title',
    body: 'Updated body text.',
    userId: 1
  })
  .then(response => console.log(response.data))
  .catch(error => console.error(error));

PATCH updates only specific fields:

axios.patch('https://jsonplaceholder.typicode.com/posts/1', {
    title: 'Partially Updated Title'
  })
  .then(response => console.log(response.data))
  .catch(error => console.error(error));

5. DELETE Requests

axios.delete('https://jsonplaceholder.typicode.com/posts/1')
  .then(response => console.log('Deleted successfully'))
  .catch(error => console.error(error));

6. Setting Headers

axios.get('https://jsonplaceholder.typicode.com/posts', {
  headers: {
    'Authorization': 'Bearer YOUR_ACCESS_TOKEN',
    'Content-Type': 'application/json'
  }
})
.then(response => console.log(response.data))
.catch(error => console.error(error));

7. Handling Query Parameters

axios.get('https://jsonplaceholder.typicode.com/posts', {
  params: {
    userId: 1
  }
})
.then(response => console.log(response.data))
.catch(error => console.error(error));

8. Using Axios Instances

const apiClient = axios.create({
  baseURL: 'https://jsonplaceholder.typicode.com',
  timeout: 1000,
  headers: { 'Authorization': 'Bearer YOUR_ACCESS_TOKEN' }
});

apiClient.get('/posts')
  .then(response => console.log(response.data))
  .catch(error => console.error(error));

9. Handling Errors Gracefully

axios.get('https://jsonplaceholder.typicode.com/posts/invalid')
  .then(response => console.log(response.data))
  .catch(error => {
    if (error.response) {
      console.error('Server responded with:', error.response.status);
    } else if (error.request) {
      console.error('No response received:', error.request);
    } else {
      console.error('Error setting up request:', error.message);
    }
  });

10. Interceptors for Request and Response

axios.interceptors.request.use(config => {
  console.log('Request sent at:', new Date().toISOString());
  return config;
}, error => Promise.reject(error));

axios.interceptors.response.use(response => {
  console.log('Response received:', response);
  return response;
}, error => Promise.reject(error));

11. Cancelling Requests

const controller = new AbortController();
axios.get('https://jsonplaceholder.typicode.com/posts', { signal: controller.signal })
  .then(response => console.log(response.data))
  .catch(error => console.error(error));

// Cancel the request
controller.abort();

12. Concurrent Requests

axios.all([
  axios.get('https://jsonplaceholder.typicode.com/posts/1'),
  axios.get('https://jsonplaceholder.typicode.com/posts/2')
])
.then(axios.spread((post1, post2) => {
  console.log('Post 1:', post1.data);
  console.log('Post 2:', post2.data);
}))
.catch(error => console.error(error));

Conclusion

Axios isn't just another HTTP client—it's your digital henchman, fetching data, sending payloads, and handling errors like a seasoned assassin. Whether you're on the frontend or backend battlefield, this cheat sheet arms you with the firepower to dominate API interactions. Keep it close, or risk drowning in a sea of failed requests and endless debugging nightmares.

Forem: Byte-Sized News

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

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

A Tiny Example

Backend (Node.js)

Frontend

Updating Charts in Real-Time

But What Happens When The Connection Drops?

Security Matters Too

Optimizing Data Flow

Wrapping Up

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

The Basic Case: Hardcoding Nested Arrays

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

The Hidden Trap: Shared References

The Solution: Create a New Array for Each Slot

Using Array.from()

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

Demonstration

Summary Table

Key Takeaways

Real-World Example: Initializing a 2D Matrix

Conclusion

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

📦 The Basics: What Do ^ and ~ Mean?

✅ ^ (Caret)

✅ ~ (Tilde)

⚠️ Why It Matters: The Hidden Dev Trap

💡 When to Use What

🧰 Pro Tips

🧪 A Real-World Example

🧵 Final Thoughts

🙌 Found this helpful?

ESLint is Dead, Long Live Biome?

What is Biome?

Key Features of Biome:

Why Are Devs Moving Away from ESLint?

`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`

Using `Array.from()`

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

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

✅ `^` (Caret)

✅ `~` (Tilde)

1. 🔐 Generate a new SSH key for the correct GitHub account (`ishan2`):

3. 📋 Add the public key to the `ishan2` GitHub account:

4. 🧠 Set up a custom SSH host in `~/.ssh/config`:

Why Does `console.log()` Return `undefined`?

1. `console.log()` Prints but Doesn't Return Anything

4. When Things Get Weird: Overriding `console.log()`