Direct answer: The next/image component requires either width and height props or a fill prop to function correctly. When using fill, omitting the sizes prop causes the browser to default to 100vw — treating the image as full-viewport-width and downloading the largest available version. On high-resolution desktop screens this means unnecessarily large image downloads. Providing accurate sizes values tells the browser the actual rendered size of the image, allowing it to download a much smaller, appropriately sized version.

We were facing slow image loading across parts of our application. My first instinct was CDN caching — we weren’t caching images through a CDN the way we were with other static assets, and due to cost constraints that wasn’t going to change immediately.

But it felt too slow to be explained by CDN caching alone. A missing cache header adds latency, but what I was seeing felt heavier than that. So I dug deeper.

What I found was that our next/image components had two distinct problems: some were missing width and height props entirely, and the ones using fill had no sizes prop on any of them. Once I understood what those props actually do under the hood, the slowness made complete sense.

What next/image Actually Does

Before getting into the props, it’s worth understanding what the next/image component gives you over a plain <img> tag — because this context makes the props make more sense.

next/image automatically:

• Converts images to modern formats like WebP (significantly smaller than JPEG or PNG)
• Generates multiple resized versions of the image at different widths
• Lazy loads images by default — only downloading when they approach the viewport
• Prevents Cumulative Layout Shift (CLS) by reserving space before the image loads

The key phrase is “generates multiple resized versions.” Next.js builds a srcset — a list of the same image at different widths — and the browser picks which one to download based on the device’s screen width and pixel density.

The props you pass directly control how intelligently that selection happens.

The First Problem: Missing width and height

Some of our images had neither width nor height nor fill. This is an error — next/image requires one or the other.

What width and height do:

These props define the intrinsic dimensions of the image in pixels. They serve two purposes:

1. They prevent layout shift. The browser knows how much space to reserve before the image loads, so nothing jumps around. This directly improves your CLS score.
2. They anchor the generated srcset. Next.js uses the width value as the largest size to generate, and creates smaller variants from there.

// ✅ Correct — fixed dimensions
<Image src="/hero.jpg" alt="Hero image" width={800} height={450} />

Without these, Next.js doesn’t know the intended size of the image, can’t generate an appropriate srcset, and can’t reserve layout space. You get a console error and undefined behaviour.

The Second Problem: fill Without sizes

The rest of our images were using the fill prop — which is the right choice when an image needs to fill its parent container rather than have fixed pixel dimensions. Common use cases are hero sections, card thumbnails, and background images.

// fill — the image stretches to fill its parent
<div style=>
  <Image src="/banner.jpg" alt="Banner" fill style= />
</div>

fill works correctly. But without a sizes prop alongside it, something problematic happens.

What sizes does and why it matters:

When Next.js generates a srcset for an image, it creates multiple versions at different widths. The browser then has to choose which one to download. To make that choice, it needs to know how wide the image will actually be rendered on screen.

Here’s the problem: the browser makes this decision before the page’s CSS has loaded and been applied. It doesn’t yet know that your image is inside a two-column grid, or that it’s constrained to a 400px sidebar. All it knows is the viewport width.

So without a sizes hint from you, it falls back to the safest assumption: the image will be as wide as the viewport — 100vw.

On a 1440px desktop screen with a 2x Retina display, 100vw means the browser targets a 2880px wide image. Even if the image is only rendered at 400px. The result is downloading an image up to 7x larger than necessary.

This is confirmed in Next.js’s own documentation — if you don’t specify a sizes value on an image with the fill property, a default value of 100vw is used, and the browser selects an image that is the same size or larger than the viewport.

How sizes fixes this:

sizes is a hint to the browser describing how wide the image will actually appear at different viewport widths. It uses the same media query syntax as CSS.

// Image that's full-width on mobile, half-width on desktop
<Image
  src="/banner.jpg"
  alt="Banner"
  fill
  sizes="(max-width: 768px) 100vw, 50vw"
  style=
/>

Now the browser knows: on screens narrower than 768px, the image is full width — download accordingly. On wider screens, the image is half the viewport — download a smaller version.

For a 1440px desktop screen with sizes="50vw", the browser targets a 720px image (or 1440px on Retina) instead of 2880px. That’s a dramatically smaller file.

Desktop vs Mobile: Where the Problem Hits Hardest

The missing sizes problem is worse on desktop than mobile — but for a reason that’s slightly counterintuitive.

On mobile, viewport widths are smaller (typically 375–430px). Even with the 100vw default, the browser is selecting images for a ~400px wide screen. The mismatch between “actual render size” and “assumed viewport size” is smaller, so the wasted bytes are less severe.

On desktop, viewports are 1280–1920px, and many devices are high-DPI (2x or 3x pixel ratio). The browser targets viewport width × pixel ratio — so a 1440px screen at 2x means targeting a 2880px image. If your image is actually rendered at 300px (say, a card thumbnail in a grid), you’re downloading nearly 10x more data than needed.

This is why the slowness was more noticeable in grid layouts and multi-column designs than on single-column mobile views.

The sizes Prop in Practice

Here are the patterns we used to fix our images:

Full-width hero image:

<Image
  src="/hero.jpg"
  alt="Hero"
  fill
  sizes="100vw"
  style=
/>

Image in a two-column grid:

<Image
  src="/card.jpg"
  alt="Card"
  fill
  sizes="(max-width: 768px) 100vw, 50vw"
  style=
/>

Image in a three-column grid:

<Image
  src="/thumbnail.jpg"
  alt="Thumbnail"
  fill
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
  style=
/>

Image in a fixed-width sidebar:

<Image
  src="/profile.jpg"
  alt="Profile"
  fill
  sizes="240px"
  style=
/>

The values don’t need to be pixel-perfect. A reasonable approximation is enough — the browser uses them to select from a pre-generated srcset, and picking the next size up is always acceptable. What you’re avoiding is the browser treating a 240px sidebar image as a full-viewport image.

A Quick Reference for All the Props

What Actually Fixed the Slowness

After adding proper width and height to fixed images and sizes to all fill images, the improvement was noticeable — especially in grid layouts on desktop.

The CDN caching issue was real and still on the list to address. But it wasn’t the primary cause. The browser was downloading images 5–10x larger than necessary on every page load, on every device, on every visit — cached or not. Fixing the props reduced the image payload significantly before any caching optimisation was even applied.

The lesson: next/image gives you a lot for free, but it can only optimise based on what you tell it. Without width/height, it doesn’t know the image’s intended size. Without sizes, it assumes full-viewport. Both omissions lead to the same outcome — oversized images served to every user.

Frequently Asked Questions

Why are my Next.js images loading slowly despite using next/image? The most common causes are missing width and height props on fixed images, or a missing sizes prop on images using fill. Without sizes, the browser defaults to assuming the image is full-viewport-width and downloads the largest available version — even if the image is only rendered at a fraction of that size.

What does the sizes prop do in next/image? sizes tells the browser how wide the image will actually be rendered at different viewport widths, using media query syntax. The browser uses this to pick the most appropriate version from Next.js’s auto-generated srcset. Without sizes on a fill image, the browser defaults to 100vw and downloads the largest available version. With width and height, omitting sizes generates only a fixed 1x and 2x srcset — which works, but providing sizes unlocks a fuller responsive srcset for more precise optimisation.

What is the difference between fill and width/height in next/image? width and height define fixed pixel dimensions for the image. fill makes the image stretch to fill its parent container — useful for responsive layouts where the image should cover a variable-sized area. When using fill, the parent must have position: relative set, and you should always add a sizes prop to prevent oversized image downloads.

Does missing sizes affect mobile or desktop more? Desktop is affected more severely. Mobile viewports are narrower, so the gap between “assumed full-viewport size” and “actual render size” is smaller. On desktop, especially high-DPI screens where the browser targets viewport width × pixel ratio, the mismatch can result in images 5–10x larger than what’s actually rendered.

When should you use the priority prop on next/image? Use priority on any image that is the Largest Contentful Paint (LCP) element — typically the main hero image or the first visible image above the fold. priority disables lazy loading and preloads the image, improving LCP scores. Avoid using it on below-the-fold images as it defeats the purpose of lazy loading.

Co-written with AI.

Direct answer: In React, when a dynamically imported component suspends, it throws a Promise up the component tree until the nearest Suspense boundary catches it. If a nested modal has no local Suspense boundary, its suspension can bubble up and trigger a loading skeleton for an entirely unrelated parent component — even one that was already fully loaded. The fix is ensuring every dynamic import has its own local Suspense boundary via a loading option.

I was working on a feature that involved opening a modal deep inside a page. The modal was dynamically imported — standard practice for keeping the initial bundle small. Everything looked fine until I noticed something that made no sense:

Opening the modal was making a completely separate part of the page — one that had already loaded — flash back to its skeleton loader.

My mental model at the time was simple: once a component loads, it stays loaded. You see the skeleton once, the component appears, and that’s it. The skeleton is gone forever.

That assumption was wrong. And understanding why it was wrong taught me more about how React works under the hood than almost anything else I’ve encountered.

What Dynamic Imports Actually Do Under the Hood

To understand the bug, you need to understand what dynamic() in Next.js — or React.lazy() in plain React — actually does at runtime.

When you write:

const PreApproveModal = dynamic(() => import('./PreApproveModal'), {
  loading: () => null,
});

React doesn’t just “load the component lazily.” It does something very specific: it throws a Promise.

When your code tries to render <PreApproveModal /> and the JavaScript chunk for that component hasn’t been downloaded yet, React throws a Promise as an exception up the component tree. This is not a metaphor — it literally uses JavaScript’s throw mechanism.

React then walks up the component tree looking for the nearest <Suspense> boundary. When it finds one, it renders that boundary’s fallback prop while it waits for the Promise to resolve — meaning while the chunk downloads. Once the chunk is ready, React re-renders the component normally.

The { loading: () => null } option in dynamic() is shorthand for Next.js automatically wrapping that component in a <Suspense fallback={loading()}> boundary. It’s a local catch for the thrown Promise — right at the source.

The Bug: What Was Actually Happening

Here’s a simplified version of the component tree I was working with:

// RecipientsContent — loaded dynamically with a skeleton
const RecipientsContent = dynamic(() => import('./RecipientsContent'), {
  loading: () => <StepContentSkeleton />,
});

// PreApproveModal — loaded dynamically, loading option commented out
const PreApproveModal = dynamic(() => import('./PreApproveModal'), {
  // loading: () => null   <-- this was commented out
});

function Page() {
  return (
    <RecipientsContent>
      <PreApproveModal isOpen={isOpen} />
    </RecipientsContent>
  );
}

The chain of events when I opened the modal:

1. <PreApproveModal /> tries to render for the first time
2. Its JavaScript chunk hasn’t downloaded yet — React throws a Promise
3. React walks up the tree looking for the nearest <Suspense> boundary to catch it
4. There’s no local boundary around PreApproveModal — the loading option was commented out
5. The Promise keeps bubbling up the tree
6. It hits the <Suspense> boundary created by RecipientsContent’s { loading: () => <StepContentSkeleton /> }
7. React hides the entire RecipientsContent tree and shows <StepContentSkeleton /> while the modal chunk downloads

The result: opening a small modal caused the entire parent section — already fully rendered, already fully loaded — to disappear and show its skeleton again.

Why My Mental Model Was Wrong

My assumption was: once a component loads, it stays loaded. The skeleton only appears once.

This is true for the component that’s already loaded. RecipientsContent itself was not re-downloading. Its chunk was already in the browser.

But Suspense doesn’t work at the chunk level. It works at the render level. When a Promise is thrown anywhere inside a Suspense boundary’s subtree — from any child, at any depth — React unmounts the entire subtree and shows the fallback. It doesn’t matter that most of that subtree was already loaded and rendered. The entire boundary resets.

The key insight: Suspense boundaries don’t protect against re-showing their fallback. They catch any suspension from any descendant, at any time, regardless of whether those descendants were previously loaded.

Once I understood that, the bug made complete sense.

Why It Stopped When I Changed Things

Uncommenting { loading: () => null } on the modal:

const PreApproveModal = dynamic(() => import('./PreApproveModal'), {
  loading: () => null, // ← this creates a local Suspense boundary
});

Now when PreApproveModal throws its Promise, there’s a local <Suspense fallback={null}> boundary right around it to catch it. The Promise never bubbles up. RecipientsContent never sees it. The skeleton never appears. The modal renders null briefly while its chunk downloads, then appears — and the rest of the page stays perfectly intact.

Removing { loading: () => <StepContentSkeleton /> } from RecipientsContent:

Without a boundary on RecipientsContent, the bubbling Promise skips past it entirely and travels up to the next boundary — the page level or wherever the next <Suspense> lives. You stop seeing StepContentSkeleton because that specific boundary no longer exists to catch it. But the suspension is still happening — it’s just caught higher up.

The Fix and the Principle Behind It

The fix is straightforward:

// Always give deeply nested dynamic imports their own boundary
const PreApproveModal = dynamic(() => import('./PreApproveModal'), {
  loading: () => null, // renders nothing while loading — modal isn't visible yet anyway
});

const HeavyTooltip = dynamic(() => import('./HeavyTooltip'), {
  loading: () => null,
});

const SidePanel = dynamic(() => import('./SidePanel'), {
  loading: () => <SidePanelSkeleton />,
});

The principle: every dynamically imported component should own its Suspense boundary. Not just the top-level ones. Especially the small, deeply nested ones — modals, tooltips, drawers — because those are the ones most likely to be opened after the page has already rendered, and their suspension has the furthest to bubble before it hits something.

For components where no visible loading state makes sense — a modal that isn’t visible until it opens — loading: () => null is the right choice. It creates the boundary, catches the suspension locally, renders nothing while loading, and lets everything else on the page continue undisturbed.

Visualising the Suspense Tree

Here’s how the component tree looks before and after the fix:

Before (broken):

<Page>
  <Suspense fallback={<StepContentSkeleton />}>   ← RecipientsContent's boundary
    <RecipientsContent>                            ← already loaded ✓
      <PreApproveModal />                          ← throws Promise 💥
        (no local boundary — Promise bubbles up)
    </RecipientsContent>
  </Suspense>                                      ← catches it here
                                                   → hides ALL of RecipientsContent
                                                   → shows StepContentSkeleton ❌

After (fixed):

<Page>
  <Suspense fallback={<StepContentSkeleton />}>   ← RecipientsContent's boundary
    <RecipientsContent>                            ← stays rendered ✓
      <Suspense fallback={null}>                   ← PreApproveModal's local boundary
        <PreApproveModal />                        ← throws Promise 💥
      </Suspense>                                  ← caught here locally ✓
                                                   → renders null briefly
                                                   → RecipientsContent untouched ✓
    </RecipientsContent>
  </Suspense>

What This Taught Me

The bug came from a gap between how I thought React lazy loading worked and how it actually works.

I thought of dynamic imports as a one-time cost — the component loads, the skeleton disappears, and from that point on the component behaves like any other. In terms of the chunk download, that’s true. But in terms of Suspense, the boundary doesn’t know or care whether the chunk was previously loaded. It only knows whether something inside its subtree is currently suspended.

The moment I understood that Suspense boundaries catch thrown Promises from any descendant regardless of load history, the entire behaviour became predictable. And once behaviour is predictable, bugs stop being mysterious.

Every dynamic import is a potential Promise throw. Give it a boundary close enough to catch it before it reaches something you don’t want interrupted.

Frequently Asked Questions

What is React Suspense bubbling? Suspense bubbling is what happens when a component throws a Promise — the standard mechanism for React lazy loading — and there is no local Suspense boundary to catch it. The Promise travels up the component tree until it reaches the nearest ancestor Suspense boundary, which then unmounts its entire subtree and shows its fallback UI.

Why does a skeleton appear again for a component that was already loaded? A Suspense boundary catches any suspension from any descendant, at any time. Even if the parent component itself is fully loaded, a child component suspending inside its tree causes the entire Suspense subtree to unmount and show the fallback. The parent’s load state is irrelevant — what matters is whether any descendant is currently suspended.

What does { loading: () => null } do in Next.js dynamic imports? It creates a local Suspense boundary around the dynamically imported component with null as the fallback. When the component suspends while its chunk downloads, the suspension is caught locally and renders nothing. This prevents the suspension from bubbling up to a parent Suspense boundary and disrupting already-rendered parts of the page.

How does React.lazy work under the hood? When a lazily imported component renders before its JavaScript chunk has downloaded, React throws a Promise as an exception. React catches this using the nearest Suspense boundary up the component tree and renders the boundary’s fallback UI. When the Promise resolves — meaning the chunk has downloaded — React re-renders the component normally.

When should you use loading: () => null vs a real skeleton in dynamic imports? Use loading: () => null for components that are not visible until triggered by user action — modals, drawers, tooltips, popovers. They don’t need a visible loading state because the user triggered them and the download is typically fast. Use a real skeleton for components that are visible on initial render — page sections, content areas — where the user needs a placeholder while the content loads. Also use a real skeleton for any component that is genuinely heavy to download, regardless of when it appears — if the chunk is large enough that the user will notice a delay, a skeleton gives them feedback that something is on its way.

Co-written with AI.

Direct answer: Functions and classes are not competing tools — they solve different problems. Functions excel at stateless logic, composition, and modern UI patterns. Classes excel at encapsulating long-lived state, modelling domain entities, and memory-efficient instantiation at scale. The difference comes down to how JavaScript manages memory through the prototype chain, and what your specific use case actually demands.

Look at modern software development and a pattern is hard to miss.

React — the most widely used frontend framework — moved decisively away from class components toward functional components with Hooks. The community followed without much resistance.

Django — one of the most battle-tested backend frameworks in existence — started with only function-based views. Class-based views came later, and to this day a vocal segment of experienced Django developers argue the tradeoff wasn’t worth it — that the inheritance chains made code harder to follow than the boilerplate they replaced.

JavaScript itself has been trending toward functional patterns for years. Closures, higher-order functions, map, filter, reduce — these are the idioms that define modern JS.

So the reasonable question to ask is: if functions vs classes is a debate, and functions keep winning in practice — why do classes still exist at all?

The answer isn’t that classes are legacy code waiting to be deprecated. It’s that functions and classes solve genuinely different problems — and understanding which problem each solves requires going a level deeper than syntax.

What Is the Difference Between a Function and a Class in JavaScript?

Ask most developers and you’ll get the standard answer: classes are for encapsulation and abstraction — bundling state and behaviour together, hiding internal details, modelling real-world entities.

Functions are more flexible and composable — great for pure logic, transformations, utility work.

That’s not wrong. But it’s incomplete. Because the obvious follow-up is: can’t functions do encapsulation too?

Yes. They can. And that’s where things get interesting.

Can Functions Replace Classes? Closures and Encapsulation Explained

Before ES6 introduced the class keyword in 2015, JavaScript had no native class syntax. Developers who needed encapsulation and private state used closures — functions that trap variables inside their lexical scope and expose only what they choose to expose.

Here’s the same bank account implemented two ways:

The Class approach:

class BankAccount {
  #balance = 0; // # makes it a truly private field

  deposit(amount: number) {
    this.#balance += amount;
  }

  getBalance() {
    return this.#balance;
  }
}

The Closure / Factory Function approach:

function createBankAccount() {
  let balance = 0; // Trapped in the closure — inaccessible from outside

  return {
    deposit(amount: number) {
      balance += amount;
    },
    getBalance() {
      return balance;
    }
  };
}

const account = createBankAccount();
account.deposit(100);
console.log(account.getBalance()); // 100
// balance is completely inaccessible from outside

Both achieve the same result. Both hide internal state. Both expose only controlled methods.

So again — why do classes exist?

The Real Difference: Memory Allocation and the JavaScript Prototype Chain

This is where most explanations stop being vague and start being precise.

When you use the factory function approach, JavaScript creates a new set of function definitions in memory every single time you call createBankAccount. Each instance gets its own copy of deposit and getBalance — distinct function objects, each allocated separately in the heap.

const account1 = createBankAccount();
const account2 = createBankAccount();

console.log(account1.deposit === account2.deposit); // false — different function objects

Here’s what the memory heap actually looks like with 3 instances:

[ Heap Memory ]

account1 ---> { deposit: [Function Ref A], getBalance: [Function Ref B] } ---> Closure (balance: 0)
account2 ---> { deposit: [Function Ref C], getBalance: [Function Ref D] } ---> Closure (balance: 0)
account3 ---> { deposit: [Function Ref E], getBalance: [Function Ref F] } ---> Closure (balance: 0)

If deposit contains 100 lines of logic, those 100 lines exist 3 times in memory. With 10,000 instances, they exist 10,000 times.

Classes solve this with the JavaScript prototype chain. When you define a class, its methods are created exactly once — on the class’s prototype object. Every instance created with new simply holds a lightweight reference pointing back to those shared methods.

const user1 = new BankAccount();
const user2 = new BankAccount();

console.log(user1.deposit === user2.deposit); // true — same function object

Memory heap with 3 instances using a class:

[ Heap Memory ]

account1 ---> { #balance: 0 } ---\
account2 ---> { #balance: 0 } ----> [ BankAccount.prototype ] ---> { deposit: [Single Fn], getBalance: [Single Fn] }
account3 ---> { #balance: 0 } ---/

No matter how many instances you create, the method logic exists exactly once. Every instance just holds a pointer to it.

This is the real reason classes exist at scale. Not syntax preference. Not OOP philosophy. Memory efficiency through the prototype chain.

JavaScript Classes Are Just Syntactic Sugar — You Can Do the Same with Functions

This is the part that shows you understand JavaScript’s actual engine, not just its syntax.

The class keyword is syntactic sugar. Under the hood, JavaScript has always been prototype-based — there are no "real" classes like Java or C++. Before 2015, developers achieved the same memory efficiency manually using constructor functions and .prototype:

function BankAccount(initialBalance) {
  this._balance = initialBalance;
}

// Methods on the prototype — shared across all instances in memory
BankAccount.prototype.deposit = function(amount) {
  this._balance += amount;
};

BankAccount.prototype.getBalance = function() {
  return this._balance;
};

const a = new BankAccount(0);
const b = new BankAccount(0);

console.log(a.deposit === b.deposit); // true — same reference

Same memory layout as a class. Methods defined once, shared via prototype.

But notice the catch: to use prototype methods, internal state has to live on this — meaning this._balance is technically accessible from outside. You lose the strict privacy that closures give you.

This is the core trade-off between functions and classes in JavaScript:

Modern ES6 classes with private fields (#property) are essentially the language finally letting you have both at the same time — true encapsulation and prototype-based memory efficiency. That’s the problem the class keyword actually solved.

The Django Story: Why Function-Based Views Came First

This same tension played out visibly in Django’s history — and it’s a useful real-world case study for the functions vs classes debate.

Django originally started with only function-based views because they are simple and explicit: a function receives an HTTP request, does something, returns a response. Clean, readable, no ceremony.

The problem wasn’t that functions were bad. The problem was repetition. A typical list view, a create view, a detail view — they all shared the same structural pattern: query the database, handle the request method, render a template, return a response. Writing that boilerplate from scratch for every view across a large application was tedious and error-prone.

Class-based views, introduced in Django 1.3, brought inheritance to address this. Subclass ListView, override a couple of attributes, get a fully working paginated list view in two lines.

But the criticism followed: the inheritance chains made implicit code flow harder to follow than the boilerplate they replaced. Django developers who preferred functions argued the complexity wasn’t a fair trade for the saved lines. It’s a debate that’s still active in the Django community today.

Django’s evolution mirrors the broader argument perfectly: functions are simpler and more readable, classes offer reusability through inheritance — but that reusability comes with cognitive overhead.

Why React Moved from Class Components to Functional Components

React’s journey went in the opposite direction — starting with class components and moving back to functions — and it’s equally instructive.

Early React required class components for any component that needed state or lifecycle methods. Functions were only for purely presentational components that received props and rendered HTML.

The problems with React class components accumulated:

• The this keyword behaved unpredictably — methods had to be manually bound in constructors
• Logic for the same feature was split across componentDidMount, componentDidUpdate, and componentWillUnmount
• Sharing stateful logic between components required render props and higher-order components, creating deeply nested, hard-to-read trees

React Hooks solved this by bringing state and side effects into functions — without this binding issues and without splitting related logic across lifecycle methods. The same feature’s logic could now live together, in one plain function.

The shift wasn’t because functions are fundamentally superior to classes. It was because for UI components with localised, short-lived state, functions with Hooks are dramatically cleaner for this specific use case.

When to Use Functions vs Classes in JavaScript: A Practical Guide

The answer isn’t a universal rule — it’s a set of questions to ask about what your code actually needs to do.

Use a function when:

• The logic is stateless — input goes in, output comes out, no memory between calls
• You’re building UI components (functional components + hooks are the modern standard)
• You want maximum composability — small pieces of logic combining into larger ones
• You’re writing utility code, data transformations, or pure calculations

Use a class when:

• You need an entity that holds state across a long lifecycle — a database connection, an API client, a game object, a session
• You’ll create many instances of the same thing and memory efficiency matters
• You’re modelling a domain entity with behaviour — ShoppingCart, UserSession, HttpClient
• You’re working in a framework built around classes — NestJS, for example, uses classes and decorators as its core architectural pattern

The mental shortcut: functions for actions, classes for things.

A function calculates tax, validates a form, fetches data. A class is a bank account, is an HTTP client, is a user session — something that persists, manages its own state, and has a lifecycle.

Summary

The industry’s move toward functions isn’t a rejection of classes — it’s a recognition that most day-to-day code is stateless logic and UI rendering, where functions genuinely are the simpler tool.

But when you need to create thousands of instances of something that holds state across a lifecycle, the prototype-based memory efficiency of classes is not a stylistic preference. It’s a practical necessity.

Functions and classes aren’t competing paradigms. They’re complementary tools — each optimised for a different problem. Knowing which problem you’re solving is the skill.

Frequently Asked Questions

What is the difference between a function and a class in JavaScript? A function is a reusable block of code that takes inputs and returns outputs. A class is a blueprint for creating objects that bundle state and behaviour together. The key technical difference is that class methods are shared across all instances via the prototype chain, while closure-based factory functions create new method copies for each instance.

When should you use a class instead of a function in JavaScript? Use a class when you need to create multiple instances of something that maintains its own state across a lifecycle — like a database connection, API client, or game entity. Classes are more memory-efficient at scale because methods are defined once on the prototype and shared across all instances.

Can JavaScript functions replace classes entirely? Technically yes — closures can encapsulate private state, and constructor functions can use prototypes for memory efficiency. But ES6 classes with private fields (#) combine both benefits cleanly. For long-lived, stateful entities created at scale, classes remain the pragmatic choice.

What is the JavaScript prototype chain? The prototype chain is JavaScript’s mechanism for sharing properties and methods between objects. Class methods are defined once on the constructor’s prototype. When an instance calls a method, JavaScript looks it up on the prototype rather than the instance itself — meaning the method exists in memory exactly once regardless of how many instances exist.

Why did React move from class components to functional components? Class components required manual this binding, split related logic across multiple lifecycle methods, and made stateful logic reuse awkward. React Hooks brought state and side effects into functional components cleanly, eliminating this issues and keeping related logic together.

Why did Django start with function-based views and add class-based views later? Django started with function-based views for their simplicity and explicitness. Class-based views were added in Django 1.3 to reduce repetitive boilerplate through inheritance. However, many experienced Django developers argue the inheritance chains introduced more cognitive complexity than the boilerplate savings justified.

What is the memory difference between closures and classes in JavaScript? With closure-based factory functions, each instance gets its own copy of every method — creating duplicate function objects in memory. With classes, methods are defined once on the prototype and referenced by all instances. For thousands of instances, classes are significantly more memory-efficient.

Co-written with AI.

Direct answer: Switching DNS (e.g. from Google’s 8.8.8.8 to Cloudflare’s 1.1.1.1) can fix Valorant ping spikes because different DNS servers resolve the game domain to different regional server IPs. Changing the destination IP forces your ISP to build a fresh network route — one that may bypass a congested or broken path that was causing the spike. It doesn’t always work, and spikes can happen on any DNS at any time.

If you’ve spent any time in gaming forums looking for ways to fix high ping in Valorant, you’ve probably seen this advice thrown around:

“Bro just switch to 8.8.8.8” or “No no, 1.1.1.1 is way better”

And the bizarre thing is — it sometimes works. Ping goes from spiking at 180ms to sitting clean at 40ms, just because you changed two numbers in your network settings.

I faced the exact same thing. I was mid-match in Valorant when my ping started spiking hard. Gunfights that should have been clean were getting me killed on my screen while my character was already dead on the server’s. Someone suggested switching DNS to Cloudflare — 1.1.1.1. I was sceptical. DNS is just a phonebook, what could it possibly have to do with in-game ping?

But I tried it. The spikes disappeared. Ping went stable.

From that point it became my go-to fix. But here’s the thing — it doesn’t always work. Sometimes I’d switch to Cloudflare and still get spikes. Sometimes the spikes would come back on Cloudflare an hour later. Sometimes switching back to Google fixed it, sometimes it didn’t.

That inconsistency is what pushed me to actually understand what’s happening. Because if you understand why it sometimes works, you also understand why it sometimes doesn’t.

The answer is far more interesting than “Cloudflare is faster.”

Does DNS Actually Affect Ping in Valorant?

Before anything else — DNS itself doesn’t affect your in-game ping once you’re connected to a match. Let’s be clear about that.

DNS is a phonebook. You type playvalorant.com, your computer asks a DNS server “what’s the IP address for this?”, gets an answer, and then connects directly to that IP. The DNS server is out of the picture the moment it hands you the address.

So if DNS doesn’t sit in the middle of your game connection, why does switching it sometimes change your ping?

Because different DNS servers can give you different IP addresses for the same game.

That one sentence is the entire answer. Everything below is explaining why.

1. What Is Anycast Routing and How Does It Affect Valorant?

Most people picture 8.8.8.8 as a single Google server sitting somewhere. It isn’t.

Both use a technology called Anycast routing. With Anycast, hundreds of server nodes across the world all share the exact same IP address. When your computer sends a request to 8.8.8.8, your ISP looks at your location and routes you to whichever Google node is geographically or topologically closest to you.

The same principle applies to Valorant’s game servers. Riot doesn’t run one server in one place — they have regional deployments across multiple data centers and infrastructure providers. Multiple IP addresses, multiple edge locations, all serving the same game.

So when you ask a DNS server “where is Valorant?”, it doesn’t just look up a single fixed answer. It figures out which regional deployment to point you to. And Google and Cloudflare make that decision differently — which brings us to the key technical reason behind all of this.

2. Why Do Google DNS and Cloudflare Give Different IPs for Valorant?

Google DNS uses an extension called EDNS Client Subnet (ECS). When you ask Google for Valorant’s server address, Google passes a masked version of your IP address to Riot’s authoritative DNS server. Riot’s system uses this to identify your approximate region and ISP, and returns the IP of the edge server most suitable for you — let’s call it Edge Server A.

Cloudflare, by contrast, is privacy-focused and deliberately does not support ECS. This is confirmed in Cloudflare’s own documentation — 1.1.1.1 does not send the EDNS Client Subnet header to authoritative servers, by design. When you ask Cloudflare the same question, Riot’s system doesn’t see your IP at all — it only sees Cloudflare’s Anycast node IP. Without location context, it makes a different routing decision and may return Edge Server B instead.

You aren’t hitting a proxy versus a main server. You aren’t getting a faster or slower version of Valorant. You’re simply being handed two different regional IP addresses — two different data center targets that both serve Valorant, but sit on completely different network paths from your machine.

You → Google DNS  →  Riot sees your region via ECS   →  Returns IP for Edge Server A
You → Cloudflare  →  Riot sees Cloudflare's IP only  →  Returns IP for Edge Server B

3. How Does Switching DNS Actually Fix a Ping Spike?

When your ping is spiking on Google DNS, it usually means the network path between your ISP and Edge Server A has become congested. Somewhere along the route — an overloaded internet exchange point, a saturated fiber link, a bad intermediate hop — packets are being delayed or dropped.

[Your PC] --(Congested Path / Bad Node)--> [Edge Server A]  ❌ High ping, packet loss

When you switch to Cloudflare, two things happen:

1. Cloudflare resolves Valorant’s domain to Edge Server B — a different IP, a different data center
2. Your machine builds a fresh connection to this new destination, and your ISP routes you down a different network path to reach it

Because Edge Server B is on a different network leg entirely, your traffic bypasses the broken, congested node that was causing the spikes.

[Your PC] --(Clean, Uncongested Path)--> [Edge Server B]  ✓ Stable ping

The DNS switch didn’t speed anything up. It rerouted you to a destination that happens to have a cleaner path from where you are right now.

4. Why Does Switching DNS Not Always Fix the Spike?

This is the part most guides don’t explain — and it’s where the real picture gets honest.

Switching DNS is not a fix. It’s a gamble on whether the new network path is cleaner than the old one. And there’s no guarantee it will be.

The new route can be just as bad. Edge Server B might be on a network path that’s also congested right now. You’ve just swapped one bad highway for another.

The spike might not be routing at all. If the congestion is inside your ISP’s own network — between your modem and their core backbone — both DNS options share that segment. Switching DNS changes the destination, but not the local bottleneck.

Riot’s servers can themselves be under load. If the edge server you’re resolving to is experiencing high player volume or infrastructure issues, your ping will spike regardless of which DNS handed you that IP.

TTL expiration can change things mid-session. Every DNS record has a Time To Live — an expiration timer. When your cached Valorant IP expires, your DNS re-resolves the domain and may return a different server instance. If that new instance is under load, your ping spikes even though you didn’t change anything.

This is why the experience feels random. The DNS switch sometimes works because it happens to route you around a specific problem at that specific moment. It’s not a reliable fix — it’s a controlled re-roll of your network path.

The Full Picture: DNS → IP → Network Path → Ping

1. You query DNS  →  DNS returns an IP based on its routing logic (ECS or no ECS)
2. Your machine connects to that IP  →  ISP picks a network path to reach it
3. Ping is determined by  →  the quality of that path at that moment
4. Switching DNS  →  changes the destination IP  →  ISP builds a new path  →  may bypass congestion

DNS choice → destination IP → network path → ping.

None of this is about which DNS server is inherently “faster” or “better for gaming.” It’s about the knock-on effect of being handed a different destination, which forces a new route, which may or may not be cleaner than the previous one at that point in time.

Frequently Asked Questions

Does changing DNS reduce ping in Valorant? Not directly. DNS doesn’t sit in the path of your in-game connection. But switching DNS can resolve Valorant to a different regional server IP, which forces your ISP to build a new network route. If the new route avoids congested or broken network paths, your ping may improve.

Should I use Google DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1) for gaming? Neither is universally better. Google uses EDNS Client Subnet to route you based on your location, often giving you a geographically closer server. Cloudflare does not use ECS by design, which can result in a different — sometimes cleaner — network path. If one is causing spikes, switching to the other forces a re-route that may bypass the congestion.

Why does my Valorant ping spike even after switching DNS? Because the spike may not be caused by your network path to the game server. Congestion inside your ISP’s own network, high load on Riot’s servers, or TTL-triggered re-resolution to a loaded server instance can all cause spikes that DNS switching won’t fix.

What is EDNS Client Subnet (ECS)? EDNS Client Subnet is a DNS extension used by Google DNS that passes a masked version of your IP address to the authoritative DNS server. This allows services like Valorant to return a regionally appropriate server IP. Cloudflare deliberately does not implement ECS in order to protect user privacy.

What is Anycast routing? Anycast is a network addressing method where multiple servers share the same IP address. Requests to that IP are automatically routed to the nearest or most optimal node. Both Google DNS and Cloudflare DNS use Anycast, as do large-scale game server providers like Riot.

Why does switching back to Google DNS sometimes fix the ping again? Because network routing is dynamic. A route that was congested an hour ago may be clear now, and the route that was clean may now be saturated. Switching DNS forces your ISP to re-evaluate the path to a new destination — which at that moment may happen to be cleaner.

Co-written with AI.

Direct answer: UTF-8 is a variable-width character encoding that converts Unicode code points into bytes. It uses 1 byte for ASCII characters, up to 4 bytes for emojis and rare symbols. It is the dominant encoding on the web because it is space-efficient, backward-compatible with ASCII, and can represent every character in existence.

You’ve typed this line dozens of times without thinking about it:

<meta charset="UTF-8">

It sits at the top of every HTML file. Every tutorial tells you to put it there. Nobody really explains what UTF-8 character encoding actually means — or why it matters beyond copy-pasting it blindly.

I didn’t truly understand it until a bug involving emojis and a CSV download forced me to.

The Bug That Started This

I was adding an emoji picker to an existing message input feature. Nothing fancy — users type messages, optionally add an emoji, and the messages get stored. There was also an existing feature that let users download all messages as a CSV file, which they’d open in Excel.

The feature worked. Or so I thought.

When I tested it end-to-end, I noticed something strange in the downloaded CSV: some emojis displayed correctly in Excel, and some showed up as garbled nonsense — strange boxes, question marks, or completely wrong characters.

Same code. Same download function. Some emojis fine, some broken.

I had no idea where to start.

The Fix — and the Questions It Raised

The fix eventually came down to two small additions to the CSV download logic:

const BOM = encodeDownloadFileInUTF8 ? ["\uFEFF"] : [];

const csvBlob = new Blob([...BOM, data || blob], {
  type: `text/csv;${encodeDownloadFileInUTF8 ? "charset=utf-8;" : ""}`,
});

Two things were added:

1. A mysterious "\uFEFF" prepended to the file — called a BOM
2. charset=utf-8 added to the MIME type

Both were added. The emojis rendered correctly in Excel.

But I refused to just move on without understanding why. What is a BOM? What does charset=utf-8 actually tell the browser? And why were only some emojis broken in the first place?

Answering those questions meant going all the way back to basics — to how computers represent text at all.

How Does a Computer Store a Letter?

Here’s something that seems obvious once you hear it, but nobody spells out clearly:

Computers only understand numbers. Everything in memory — images, videos, code, text — is ultimately stored as binary digits: ones and zeros.

A number like 65 is easy. In binary it’s 01000001. Done.

But what about the letter "A"? You can’t directly convert a character to binary the way you can a number. A character isn’t a number — it’s a symbol.

So how does it work?

The answer is: we agreed on a map.

What Is a Character Set? ASCII and Unicode Explained

A character set (or charset) is essentially a lookup table. It maps every character — letters, digits, punctuation, symbols — to a unique number. Once a character has a number, that number can be converted to binary, and the machine can store it.

The two most important character sets:

ASCII was one of the earliest and simplest. It maps 128 characters to numbers 0–127. The letter "A" is 65. "B" is 66. A space is 32. It covers the basic English alphabet, digits, and common punctuation — nothing more.

Unicode is the modern, universal standard. Instead of 128 characters, it maps over 140,000 of them — every letter from every human language, mathematical symbols, and yes, emojis. The 😊 emoji, for example, is Unicode code point U+1F60A. In JavaScript, you can verify this:

"A".charCodeAt(0);   // 65  — the number Unicode (and ASCII) maps "A" to
"😊".codePointAt(0); // 128522 — the number Unicode maps this emoji to

So the character set answers: “What number does this character correspond to?”

But there’s a second question: “How do we actually store that number in bytes?”

That’s where encoding comes in.

What Is UTF-8 and How Does It Work?

UTF-8 is not a character set. It’s an encoding — a set of rules for turning Unicode code point numbers into actual bytes that get written to memory or a file.

Here’s the key insight that makes UTF-8 clever:

• Simple characters (basic English letters, digits) that have small code point numbers get stored in 1 byte
• Characters from other languages and accented letters use 2 or 3 bytes
• Emojis and rare symbols use 4 bytes

This is what “variable-width encoding” means. UTF-8 uses as few bytes as necessary for each character.

"A"  → code point 65     → UTF-8: 1 byte  → 01000001
"é"  → code point 233    → UTF-8: 2 bytes → 11000011 10101001
"中" → code point 20013  → UTF-8: 3 bytes → 11100100 10111000 10001101
"😊" → code point 128522 → UTF-8: 4 bytes → 11110000 10011111 10011000 10001010

This is why UTF-8 became the dominant encoding for the web. It’s backward-compatible with ASCII (the first 128 characters encode identically), space-efficient for English text, and capable of representing every character in existence.

When you write <meta charset="UTF-8"> at the top of your HTML, you’re telling the browser: “When you read this file’s bytes, decode them using UTF-8 rules.”

Without that declaration, the browser guesses. And when it guesses wrong, characters break.

Why Were Only Some Emojis Breaking in the CSV?

Now that the foundation is set, we can diagnose exactly what was happening.

The CSV was being generated and downloaded without explicitly declaring its encoding. Excel, when it opens a CSV, also has to guess the encoding. And Excel’s default assumption — especially on Windows — is not UTF-8. It often defaults to a legacy encoding like Windows-1252, which only handles 256 characters.

Here’s why only some emojis broke:

• Simple emojis that happened to fall within the range Excel’s legacy encoding could interpret showed up fine — by accident
• Emojis with 4-byte UTF-8 sequences that fell completely outside the legacy encoding’s range came out as garbage

It wasn’t a random bug. It was entirely predictable once you understand encoding.

The Fix, Explained

Two things were added to the code. They look similar in purpose but operate at completely different layers — and only one of them actually fixed the bug.

What Is a BOM (Byte Order Mark) and Why Does It Fix Excel?

const BOM = encodeDownloadFileInUTF8 ? ["\uFEFF"] : [];
const csvBlob = new Blob([...BOM, data || blob], { ... });

BOM stands for Byte Order Mark. It’s a special invisible character (U+FEFF) prepended to the very start of a file.

To understand what the BOM actually is, you need a tiny bit of backstory.

When a number takes up multiple bytes in memory, there are two valid ways to arrange those bytes — most significant byte first (big-endian) or least significant byte first (little-endian). Both are legitimate. But if the reader doesn’t know which order was used, they’ll misread the number entirely.

UTF-16 and UTF-32 store characters in multi-byte chunks, so byte order matters for them. The character U+FEFF was placed at the very start of files so that readers could detect which byte order was used — if they read it as FE FF it’s big-endian, if they read it as FF FE it’s little-endian. That’s where the name Byte Order Mark comes from.

UTF-8 doesn’t actually need this. It processes one byte at a time and builds up characters using its own rules, so byte order is never ambiguous. The BOM has no technical purpose in UTF-8.

But it got repurposed as a convention. When \uFEFF is encoded in UTF-8, it produces a specific three-byte sequence at the start of the file: EF BB BF. Excel on Windows recognises these exact bytes as a signal meaning “this file is UTF-8.” It has nothing to do with byte order anymore — Excel just looks for those three bytes, and if it finds them, it stops guessing and decodes the whole file as UTF-8.

The BOM is what actually fixed the bug. It survives the journey from browser to disk to Excel because it lives inside the file itself — not in any header or metadata that gets stripped away.

Does charset=utf-8 in the MIME Type Fix the Problem?

type: `text/csv;charset=utf-8;`

This tells the browser — and any application that reads MIME types — that the content is encoded in UTF-8.

But here’s the honest reality: for the specific bug we were fixing, this alone would not have helped.

When a user downloads a CSV and opens it by double-clicking, Excel on Windows doesn’t see the MIME type. That information exists at the HTTP/browser layer and gets lost the moment the file is saved to disk. Excel never gets a chance to read it.

So why add it at all? Because not everything that reads your file is Excel:

• A Python script processing the CSV programmatically will read the MIME type and decode correctly
• An API consuming the file will respect it
• A browser rendering the CSV directly will use it
• It documents intent — any tool that does respect MIME types will handle the file correctly

Think of it this way:

The MIME type tells tools that ask what encoding this is. The BOM tells tools — like Excel — that don’t bother asking.

For this bug, if you had to pick just one: the BOM was the fix. The charset=utf-8 was the right thing to add alongside it — but it was good practice, not the cure.

The Mental Model, Simplified

Character  →  [Character Set]  →  Code Point Number  →  [Encoding]  →  Bytes in memory/file

   "A"     →    Unicode        →        65            →    UTF-8     →   01000001
   "😊"    →    Unicode        →      128522          →    UTF-8     →   4 bytes

• Character Set (Unicode): gives every symbol a unique number
• Encoding (UTF-8): defines how to turn that number into actual bytes
• BOM (\uFEFF): a signal baked into the file’s bytes — survives to disk, read by Excel
• charset=utf-8: a signal in the MIME/HTTP layer — read by browsers and programmatic tools, but lost when the file is saved locally

What to Take Away

The next time you see <meta charset="UTF-8"> or charset=utf-8 in a content type header, you’ll know exactly what it’s doing. It’s not boilerplate. It’s a contract — you’re telling every tool in the chain: “Here’s the encoding I used to write these bytes. Please use the same rules to read them.”

When that contract is missing or mismatched, text breaks. Sometimes obviously, sometimes only for edge cases like 4-byte emoji sequences that a legacy encoding never anticipated.

A small invisible character at the start of a file fixed my bug. Now I’ll never forget what it means.

Frequently Asked Questions

What is UTF-8 encoding? UTF-8 is a variable-width character encoding system that converts Unicode code points into bytes. It uses 1 byte for basic ASCII characters and up to 4 bytes for emojis and rare symbols. It is the most widely used encoding on the web.

What is the difference between a character set and an encoding? A character set (like Unicode or ASCII) maps characters to unique numbers called code points. An encoding (like UTF-8) defines the rules for converting those code point numbers into actual bytes stored in memory or files. UTF-8 is an encoding of the Unicode character set.

Why does <meta charset="UTF-8"> need to be in every HTML file? Without it, the browser has to guess how to interpret the file’s bytes. If the guess is wrong, characters render as garbage — especially accented letters, non-Latin scripts, and emojis. Declaring charset=utf-8 tells the browser exactly which rules to use.

What is a Byte Order Mark (BOM) and when do you need it? A BOM (\uFEFF) is a special invisible character prepended to a file’s bytes. In UTF-8 files, it encodes as EF BB BF and signals to applications like Excel on Windows that the file is UTF-8 encoded. It is particularly important when generating CSVs that users will open in Excel, since Excel does not reliably read the MIME type charset declaration after a file is saved to disk.

Why do only some emojis break in Excel CSVs? Excel on Windows defaults to a legacy encoding (like Windows-1252) when opening CSVs without explicit encoding signals. Emojis that happen to fall within that legacy encoding’s range display by accident. Emojis requiring 4-byte UTF-8 sequences — outside the legacy encoding’s range entirely — come out as garbled characters.

Co-written with AI.

Direct answer: Node.js is neither purely single-threaded nor purely multi-threaded. JavaScript execution runs on a single main thread, but Node.js as a runtime uses multiple background threads via libuv for I/O operations. Worker Threads and the Cluster Module enable true parallelism when needed.

“Is Node.js single-threaded?”

It’s one of those Node.js interview questions that sounds straightforward. You’ve probably heard the answer thrown around confidently in videos, tutorials, and bootcamps — “Yes! Node.js is single-threaded. That’s its whole thing.”

Except that’s not the full picture. And in an interview — or in production — giving that answer will cost you.

Answer “yes” — you’re wrong. Answer “no” — also wrong.

The accurate answer is: JavaScript execution in Node.js is single-threaded, but Node.js as a runtime environment is multi-threaded.

That single sentence is the difference between someone who has used Node.js and someone who truly understands the Node.js architecture. Let’s break it down — slowly, with no hand-waving.

What Is a Thread and Why Does It Matter in Node.js?

Before we even get to Node.js, it helps to understand what a thread actually is.

Think of your CPU as a kitchen. A thread is a single chef working in that kitchen. One chef can only do one thing at a time — chop vegetables, stir a pot, or plate a dish. If you have multiple chefs (multiple threads), they can work on different things simultaneously.

Your operating system manages hundreds of threads across all your running applications. When you open Chrome, it spins up multiple threads. When you run a Node.js server, it also creates threads — more than most people realise.

With that foundation set, let’s look at what actually happens when Node.js starts up.

1. Why Is JavaScript in Node.js Single-Threaded?

When you write JavaScript in Node.js — your route handlers, your business logic, your async/await functions — all of it runs on a single main thread.

This means:

• There is only one Call Stack
• Only one line of your JavaScript executes at any given moment
• This main thread runs the Event Loop, which is the heartbeat of every Node.js application

The Event Loop is what gives Node.js its reputation for handling many requests efficiently. It constantly checks: “Is there something in the queue waiting to run? Is the Call Stack empty? Okay, let’s go.”

But here’s the thing junior developers often don’t fully internalise: if you block the main thread, you block everything.

Write a synchronous calculation that takes 10 seconds:

// Don't ever do this in a server
const startTime = Date.now();
while (Date.now() - startTime < 10000) {
  // burning 10 seconds of CPU
}

Your entire server is frozen for those 10 seconds. Every user who sends a request during that time gets silence. The Event Loop cannot move. No callbacks run. No responses go out. One bad piece of synchronous code and your whole server becomes unresponsive.

This is called blocking the Event Loop — and it’s the most common and painful Node.js performance mistake.

2. How Does Node.js Handle Multiple Requests Without Freezing?

If JavaScript is single-threaded, how does a Node.js server handle reading files, querying a database, hashing passwords, and responding to hundreds of users — all seemingly at the same time — without freezing?

The answer: Node.js doesn’t do all of that on the main thread.

Node.js is built on top of two core components: Google’s V8 engine (which executes your JavaScript) and a powerful C++ library called libuv (which handles everything that touches the operating system).

When you ask Node.js to do something slow and I/O-heavy — reading a file from disk, making a network call, hashing a password with bcrypt — it doesn’t sit and wait. It hands that task to libuv, which manages a background Thread Pool.

By default, that thread pool has 4 threads. These threads are invisible to you as a developer. You never write code for them directly. But they are always there, quietly doing the heavy lifting.

Here’s exactly what happens, step by step, when you call fs.readFile:

1. Your code calls fs.readFile() on the main thread
          │
          ▼
2. Main thread hands the task to libuv thread pool
   (main thread immediately moves on — it doesn't wait)
          │
          ▼
3. A background thread picks up the task
   and asks the OS to retrieve the file from disk
          │
          ▼
4. OS returns the file data to the background thread
          │
          ▼
5. Background thread pushes a callback into the Callback Queue
          │
          ▼
6. Event Loop sees the Call Stack is empty,
   picks up the callback, and runs it on the main thread

The main thread never sat idle waiting for the file. It went off and served other requests. When the file was ready, the result came back to it through the queue. That’s the magic.

The Waiter Analogy (This Will Stick With You)

Think of a Node.js server as a restaurant with a single, highly efficient waiter.

The waiter (main thread) takes your order and immediately walks it to the kitchen pass-through. They don’t go into the kitchen and personally cook your food. They don’t stand at the pass-through waiting either. They spin around and take the next table’s order.

The kitchen staff (libuv background threads) handle all the time-consuming cooking. When your food is ready, they ring a bell. The waiter picks it up and brings it to your table.

This is exactly how Node.js handles I/O concurrency. One waiter, moving fast, backed by a kitchen full of workers. The waiter is never blocked — unless someone forces them to personally cook a steak right at the front desk. That’s your while loop.

3. Can Node.js Run JavaScript in Parallel? Worker Threads Explained

libuv handles system-level I/O in the background automatically. But what if your bottleneck isn’t file reading or database queries — what if it’s pure, heavy JavaScript computation?

Imagine you’re building a feature that processes video frames, runs a machine learning model, or crunches a massive dataset. These are CPU-bound tasks. libuv won’t help you here because the work itself happens in JavaScript — on the main thread.

For this, Node.js gives you two native tools:

What Are Worker Threads in Node.js?

The worker_threads module lets you spin up a completely separate V8 engine and Call Stack inside your process. You can send the heavy computation to a Worker, and the operating system will schedule that Worker onto a separate, idle CPU core.

const { Worker } = require('worker_threads');

// Offload heavy work to a Worker
const worker = new Worker('./heavy-calculation.js');

worker.on('message', (result) => {
  console.log('Got result:', result);
  // Main thread was free this entire time
});

Your main thread stays at 0% utilisation and keeps serving web traffic while the Worker grinds through the computation on another core. Workers in the same process can even share raw memory directly using SharedArrayBuffer — no costly data copying between threads.

What Does the Node.js Cluster Module Do?

While Worker Threads add parallelism inside a single Node.js process, the Cluster Module goes a level higher — it duplicates your entire application across multiple CPU cores.

If you have an 8-core machine, Cluster forks your application 8 times. You now have 8 completely independent Node.js processes, each with its own memory and Event Loop. A master process sits at your server port and distributes incoming requests across all 8 using round-robin load balancing.

const cluster = require('cluster');
const os = require('os');

if (cluster.isMaster) {
  const totalCPUs = os.cpus().length;
  for (let i = 0; i < totalCPUs; i++) {
    cluster.fork(); // Spawn one process per core
  }
} else {
  // Each worker runs your actual server
  require('./server');
}

If one instance crashes, the other 7 keep running. The master process can restart the crashed worker automatically.

4. The Thread Multiplication Trap That Breaks Production Servers

Here’s something that even experienced engineers get wrong when they first combine these two tools.

Say you have an 8-core server. You use Cluster to spawn 8 application instances — one per core, perfectly sensible. You also have a heavy data-processing feature, so inside your application code you configure a Worker Thread pool of 4 threads to handle it.

Feels reasonable, right? Let’s do the math.

Cluster duplicates your entire application — including your Worker Thread configuration. So you haven’t created 4 background threads. You’ve created:

8 Cluster Instances × 4 Worker Threads = 32 Active Threads

32 software threads are now fighting over 8 physical CPU cores. The operating system has to constantly pause threads, save their state to memory, load another thread’s state, and resume — a process called context switching. It happens so fast it looks simultaneous to a human, but it is expensive. If you overwhelm your hardware, the CPU spends more time switching between threads than actually running your code.

Your server grinds to a halt — not because of bad code, but because of bad thread arithmetic.

The rule to remember: Total Cluster Instances + Total Worker Threads ≤ Total Physical Cores

On an 8-core machine: run 4 Cluster instances, and cap your Worker pool at 1 thread per instance. Leave breathing room.

5. Node.js in Production: PM2 vs AWS Load Balancer

Understanding Node.js threading isn’t just interview trivia — it directly shapes how you architect systems at scale.

What Is PM2 and When Should You Use It?

PM2 is a tool you install on a server that manages your Node.js processes. It handles the Cluster Module automatically (pm2 start app.js -i max spawns one process per CPU core), restarts crashed instances in milliseconds, and keeps your app alive through server reboots.

It’s the go-to solution for a single VPS or bare-metal Linux server.

PM2 vs AWS Application Load Balancer: What’s the Difference?

An AWS ALB operates at a completely different level. It doesn’t know or care about threads or cores inside your application. Its job is to distribute incoming internet traffic across a fleet of completely separate machines or containers.

In modern production systems, senior engineers don’t pick one — they use both layers together:

1. Package the Node.js app in a Docker container, configured as a single-threaded instance on exactly 1 virtual CPU core
2. Use AWS ECS or Kubernetes to run dozens of identical containers
3. Put an AWS Application Load Balancer in front of the entire fleet

One single-threaded instance per container. No manual thread management in code. The infrastructure scales horizontally, and Node.js does what it’s best at — handling I/O concurrency on a single, fast, non-blocking event loop.

Summary: Node.js Threading Model at a Glance

Node.js is not single-threaded. It is not multi-threaded. It is a carefully designed runtime that uses a single thread for your code, and an intelligent background system for everything else — so that one fast, non-blocking thread can do the work of many.

That’s the real answer. And now you know why it’s a trick question.

Frequently Asked Questions

Is Node.js single-threaded or multi-threaded? Node.js JavaScript execution is single-threaded — one Call Stack, one Event Loop. But the Node.js runtime uses a multi-threaded background thread pool (via libuv) for I/O operations like file reads, database queries, and cryptography.

What is the Node.js Event Loop? The Event Loop is the mechanism that allows Node.js to perform non-blocking I/O despite running JavaScript on a single thread. It continuously checks the Callback Queue and executes pending callbacks when the Call Stack is empty.

What is libuv in Node.js? libuv is a C++ library that Node.js uses to handle asynchronous I/O operations. It maintains a background thread pool of 8 threads by default, which handle tasks like file system access and cryptographic functions without blocking the main JavaScript thread.

When should you use Worker Threads vs the Cluster Module? Use Worker Threads for CPU-bound tasks (heavy computation) within a single application process. Use the Cluster Module to scale across multiple CPU cores by running independent copies of your entire application. Avoid combining them without careful thread budgeting.

What does “blocking the Event Loop” mean? Blocking the Event Loop means running a synchronous operation on the main thread that takes a long time to complete — like a heavy while loop or synchronous file read. While it runs, Node.js cannot process any other requests, effectively freezing the server.

Co-written with AI.