DEV Community: Mohsen Fallahnejad

XSS vs CSRF: Two Browser Attacks With Two Different Fixes

Mohsen Fallahnejad — Sat, 14 Nov 2026 13:11:20 +0000

Picture two bugs that both end with the user doing something they didn't mean to.

A comment on your site renders this:

<img src="x" onerror="fetch('/api/transfer',{method:'POST',body:JSON.stringify({to:'attacker'})})">

A page on another site does this:

<form action="https://yourapp.example/transfer" method="POST">
  <input name="to" value="attacker" />
</form>
<script>document.forms[0].submit()</script>

Both ride the victim's browser. Against a normal session cookie, only the first one still works. They are different attacks, and the fix for one does nothing for the other.

The mental model: inside the page, or only borrowing the browser

XSS (cross-site scripting) means the attacker's code runs on your origin, as if you had written it. It can read the page, change it, and call your API.

CSRF (cross-site request forgery) means the attacker's code stays on their origin. It tricks the browser into sending a request to you, and the browser attaches the user's cookies. The attacker never sees the response.

XSS is the attacker sitting at the keyboard on your site. CSRF is the attacker dropping a letter into the mailbox the browser already delivers.

How it works

The browser's same-origin policy is the wall between sites. JavaScript on evil.example cannot read a page or a response from yourapp.example.

XSS climbs over that wall by becoming part of your page. Once the script runs on your origin, the wall doesn't apply: the DOM and fetch("/api/me") are allowed. For that tab, the script is your site.

CSRF doesn't climb the wall. A form on one site can POST to another, and the browser attaches the session cookie if the user is logged in. The attacker's page still can't read the reply, so CSRF forges an action, not a look at the page.

The two flags from HttpOnly cookies point opposite ways:

Flag	Against XSS	Against CSRF
`HttpOnly`	The script can't read the cookie	No help. The browser sends it anyway
`SameSite=Lax`	No help. The script is already on your site	The cookie stays home on a cross-site POST

HttpOnly limits XSS to the open tab. The script can still fetch("/api/transfer") and read the response, but it cannot copy the token out. SameSite=Lax limits CSRF, and browsers default a missing SameSite to Lax, so the form above no longer carries the session. CORS doesn't help: it only decides whether JavaScript may read a cross-origin response, and the forged form never reads one.

In practice

Stop XSS by never letting untrusted text become code. React already escapes text in JSX:

<p>{comment.body}</p> // "<img onerror=...>" shows up as text, not as a tag

The holes are where you opt out: dangerouslySetInnerHTML, element.innerHTML, and HTML built as a string on the server. Escape on the way out, for the spot you're writing into: HTML text, an attribute, or a URL. A check on the way in misses the value that looks harmless until it lands in src.

Stop CSRF by not treating every cookie-bearing request as intent.

Session cookie: HttpOnly; Secure; SameSite=Lax.
State changes go on POST, PUT or DELETE. Lax still sends the cookie when someone clicks a cross-site link, and a link is a GET.
If a cookie has to be SameSite=None (a widget embedded on other sites), add a CSRF token: a secret rendered in your page that a foreign form can't read, sent back with the action, and checked on the server.

Honest stakes: with Lax as the default, that cross-site form POST rarely carries a normal session cookie. XSS is the bug you'll actually ship, usually through one HTML sink. CSRF comes back when you set SameSite=None, or when a GET request changes data.

Say it in an interview

"XSS is the attacker's JavaScript running on your origin, so it can read the page and call your API as the user. CSRF is a request the browser sends to your site from another site, cookies attached, while the attacker can't read the response. Escaping output stops XSS, because untrusted data never becomes code. SameSite=Lax stops most CSRF; if the cookie must be sent cross-site, add a CSRF token the foreign page can't see."

Cheat sheet

	XSS	CSRF
Where the code runs	On your origin	On the attacker's origin
What they get	The page, and API calls as the user	A state change, not the response
`HttpOnly`	Blocks token theft, not the action	Does nothing
`SameSite=Lax`	Does nothing	Blocks the cookie on a cross-site POST
The fix	Escape output. Don't put user text in `innerHTML`	`SameSite`, no state-changing GET, a CSRF token when Lax isn't enough

TL;DR

XSS runs the attacker's code on your page. CSRF only borrows the browser to send a request.
HttpOnly limits XSS. SameSite limits CSRF. Each flag is useless against the other attack.
React's {text} is already escaped. The bug hides in dangerouslySetInnerHTML and raw HTML.
Cookies default to SameSite=Lax, so classic CSRF is rare unless you opt out or change state on GET.

Going deeper

Advanced and optional. Everything above is enough to explain this in an interview. This part is for the curious: full numbers, edge cases and what's still unproven.

Three ways the script gets in

Stored. The payload is saved (a comment, a username, a CMS field) and served later to whoever opens the page. One save, many victims.
Reflected. The payload is in the request, and the server copies it straight into the HTML. The attacker sends the victim a link.
DOM-based. The server's HTML is clean. Your own client code writes untrusted data into the page with innerHTML or document.write.

The fix is the same for all three: that data must stay data.

Why a GET can still be CSRF

SameSite=Lax withholds the cookie on a cross-site POST, on fetch, and in an iframe. It sends the cookie on a top-level navigation the user clicks, and that navigation is a GET. So this is still CSRF if the handler changes state:

<a href="https://yourapp.example/transfer?to=attacker&amount=100">view the invoice</a>

That's why state changes don't belong on GET. Lax assumes you already followed that rule.

Same site is not same origin

SameSite looks at the site (the registrable domain, example.com), not the origin. https://app.example.com and https://evil.example.com are the same site, so a Lax cookie is sent from one to the other. Strict doesn't close this either: the request was never cross-site. A subdomain you don't fully control can forge requests to the app. A CSRF token still works, because that subdomain can't read your page.

What a CSRF token has to be

A random value rendered into the real page (a hidden form field, or a header your frontend sets), stored in the user's session, and checked on the state-changing request. The foreign page can't read it, because of the same-origin policy. A forged form can send the cookie and still fail the check.

That check assumes the attacker can't read your HTML. XSS can, so an XSS bug defeats the token. The two fixes don't substitute for each other.

Checking the Origin header is a simpler version of the same idea: on a state-changing request, require it to be your own site. The attacker's page cannot set that header. Do the check on the server.

Content-Security-Policy

A CSP (Content-Security-Policy) is a response header that lists where scripts may load from. A strict one (script-src with a nonce or a hash, and no unsafe-inline) refuses an injected <script> or an onerror handler even if it lands in the HTML. It's a seatbelt for the XSS you haven't found. It doesn't make raw innerHTML correct, and it does nothing for CSRF.

A Philosophy of Software Design Summary: Deep Modules Beat Small Ones

Mohsen Fallahnejad — Fri, 13 Nov 2026 12:46:40 +0000

Picture a codebase where adding one field means editing seven files, and nobody is sure which seven. No single commit made it that way. It got there one reasonable shortcut at a time.

That slow slide is what this book is about.

Book: A Philosophy of Software Design, John Ousterhout (2nd edition, 2021). Ousterhout is a Stanford professor who created the Tcl language, and the book grew out of a software design course he teaches there.

The book in one sentence

Complexity is the enemy, and the best weapon against it is modules that hide a lot behind a simple interface.

Everything else in the book either explains where complexity comes from or gives you a way to hide it.

Idea 1: Complexity is anything that makes code hard to change

Ousterhout defines complexity by its effect: anything that makes a system hard to understand or modify. He names three symptoms:

Change amplification: one small change needs edits in many places.
Cognitive load: you have to hold a lot in your head to make a change safely.
Unknown unknowns: you can't even tell what you need to change. This is the worst one.

And two causes: dependencies (code that can't be understood alone) and obscurity (important information that isn't obvious).

The key point: complexity is incremental. No single shortcut ruins a codebase, so every shortcut feels fine.

Use it: in code review, ask "does this make the next change harder?" instead of "does this work?"

Idea 2: Be strategic, not tactical

Tactical programming means getting the current feature working as fast as possible. Strategic programming means treating working code as not enough: the real goal is a design that keeps future changes cheap.

The book's name for the extreme tactical developer is the tactical tornado: someone who ships features fast and leaves a mess for everyone else, often while being praised as the most productive person on the team.

Ousterhout's suggestion is modest: spend about 10–20% of your development time on design improvements. Not a rewrite, just a steady investment that pays back within months.

Use it: when you touch a file, leave its design slightly better than you found it, and count that as part of the task.

Idea 3: Deep modules beat shallow ones

This is the idea the book is known for.

Think of a module (a function, class or service) as a rectangle. The top edge is its interface: what you must learn to use it. The area is its functionality: what it does for you.

A deep module has a small interface and a lot of functionality. The book's classic example is Unix file I/O: a handful of calls (open, read, write, lseek, close) hide disks, caching, permissions and file systems.
A shallow module has an interface almost as complex as what it does. Calling it saves you little.

Here's the difference in TypeScript (this example is not from the book):

// shallow: three calls, and the caller must know the order and the format
const raw = readFileSync(path, "utf8");
const parsed = parseJson(raw);
const config = applyDefaults(parsed);

// deep: one call, the rest is hidden
const config = loadConfig(path);

The book also names the failure mode of "small is always good": classitis, where a codebase splits into many tiny classes, each easy to read alone but with so many interfaces that the system as a whole is harder to learn.

Use it: judge a function by how much it hides, not by how short it is.

Idea 4: Hide information, and watch for leaks

Each module should own a design decision (a file format, a protocol, a caching rule) so the rest of the code doesn't need to know it. That's information hiding.

The opposite is information leakage: the same decision shows up in several places. If two modules both know the layout of a file, changing the layout means changing both.

A common cause is temporal decomposition: splitting code by the order things happen ("read, then process, then write") instead of by what knowledge each part owns. The reader and writer end up sharing the format.

Use it: before splitting a module, ask "what knowledge does each piece own?" If the answer is "the same thing", keep them together.

Idea 5: Define errors out of existence

Every error a function can throw is part of its interface, and every caller has to deal with it. So the best error handling is often an API where the error can't happen.

JavaScript has good examples (these are not from the book):

"abc".slice(1, 100); // "bc"  ← clamps instead of throwing
new Set([1]).delete(5); // false ← "make sure 5 isn't there" always succeeds

The book's own example is a Tcl command Ousterhout regrets designing: removing a variable that didn't exist threw an error, so callers wrapped it in error handling. Defining it as "make sure this variable doesn't exist" would have removed the error entirely.

Use it: when you add a throw, ask whether a different definition of the operation would make the case normal instead.

Where it's weak

It disagrees with Clean Code, and both sides have a point. Ousterhout argues that very short functions and "self-documenting code with no comments" often make systems harder to understand. Robert Martin disagrees. The two discussed it at length in a public conversation from 2024–2025. Read both before adopting either as a rule.
"Deep" can be misread as "big". A 2,000-line class with a two-method interface is deep, and also hard to work on. The book wants deep and well organized inside.
It's light on testing. It's skeptical of test-driven development, arguing it pulls attention toward getting features working rather than finding the best design. Many teams won't agree.
Few web examples. Most examples come from systems code and student projects. You'll need to translate them to frontend work yourself.

Use it on Monday

In your next PR, name one place where you hid something from callers.
Find a function whose callers always call two other functions right after it. Merge them into one deep call.
Pick one throw in your code and see if a broader definition removes it.
Before building a module, sketch two different interfaces and compare them. The book calls this "design it twice".
Write the comment for a function's interface before the code. If the comment is hard to write, the design isn't clear yet.

Say it in an interview

"I like Ousterhout's idea of deep modules: a good abstraction has a simple interface and hides a lot of functionality behind it. Complexity shows up as change amplification, cognitive load and unknown unknowns, and it builds up one shortcut at a time, so I try to work strategically: spend some of every task improving the design, hide design decisions inside one module, and design APIs so common error cases simply can't happen."

Cheat sheet

Idea	In one line
Complexity	Anything that makes code hard to understand or change
Strategic programming	Working code isn't enough; invest 10–20% in design
Deep modules	Small interface, lots of functionality
Information hiding	One module owns each design decision
Errors out of existence	Define operations so the error case can't happen

Should you read it?

Read it if you've written code for a year or more and feel your designs get messy as they grow. It's short, a weekend's reading, and written plainly.

Short on time? Read the chapters on complexity, deep modules, information hiding and errors. That's most of the value.

Skip it if you want a catalog of patterns or framework advice. It's about how to think, not what to type.

The author's page for the book: A Philosophy of Software Design.

Going deeper

Advanced and optional. Everything above is enough to explain this in an interview. This part is for the curious: full numbers, edge cases and what's still unproven.

More ideas from the book, in one line each

Pull complexity downward. If either the module or its callers must handle something hard, it's usually better for the module to do it once.
Different layer, different abstraction. If a method only passes its arguments to another method with the same signature (a pass-through method), the layers aren't adding value.
Somewhat general-purpose. Design a module's interface a bit more general than today's single use. It often turns out simpler, not more complex.
Comments describe what the code can't. Good comments explain why, and what a reader can't see from the code: units, invariants, edge cases. Comments that repeat the code are noise.
Names matter. A name that's hard to pick is a hint that the thing it names doesn't have a clear purpose.
Red flags. The book ends chapters with warning signs, like shallow modules, pass-through methods, information leakage and vague names. They make a handy review checklist.

What changed in the 2nd edition

According to Ousterhout's own page, the 2nd edition (July 2021) added a chapter called "Decide What Matters", took a firmer position in favor of general-purpose designs, and added sections contrasting the book's advice with Clean Code, mainly on method length and comments. He says it may not be worth buying the 2nd edition if you already own the first, and offers the new material as a free extract for first-edition owners.

The Clean Code conversation

Between September 2024 and February 2025, Ousterhout and Robert Martin held a series of discussions about where their books disagree, and published the result as a single document on GitHub. The main topics are method length, comments and test-driven development, with code examples on both sides. It's long, but it's the most useful thing to read after this book, because it shows the same problem argued well from two directions.

How V8 Makes JavaScript Fast: Ignition, Sparkplug, Maglev and TurboFan

Mohsen Fallahnejad — Fri, 13 Nov 2026 10:16:42 +0000

Here's one small function, run on Node 26 with the same input every time:

function dist(p) {
  return Math.sqrt(p.x * p.x + p.y * p.y);
}

Then the same function again, but with V8 stopped at a different stage each time:

Ignition only:   50.9 ns per call
+ Sparkplug:     31.9 ns
+ Maglev:         1.65 ns
+ TurboFan:       1.19 ns   ← 43× faster than the first line

The code never changed. The only thing that changed is how hard V8 worked on translating it.

The mental model: a translator who works harder on popular pages

Picture a translator handed a book in a language your computer doesn't speak.

For a page read once, they translate it out loud on the spot, line by line.
For a page read a few times, they write down a quick word-for-word draft.
For a page read hundreds of times, they write a proper translation.
For the page everyone reads all day, they polish it, assuming the page always looks the way it has so far.

V8 translates your JavaScript in stages, and only spends extra effort on code that runs a lot.

Each stage is called a tier, and the whole approach is JIT (just-in-time) compilation: the machine code is made while the program runs, not before.

How it works

V8 has four tiers. Each one makes faster code, but takes longer to make it:

Tier	Translator analogy	What it does
Ignition	reading out loud	Interprets bytecode, a compact list of simple instructions made from your source
Sparkplug	word-for-word draft	Turns bytecode straight into machine code, with almost no thinking
Maglev	proper translation	A fast optimizing compiler that uses the types it has seen so far
TurboFan	polished translation	The slow, heavy optimizer for the hottest code

Every function starts in Ignition. While it runs, V8 counts how often it's called and records what it sees: "p always has x and y, and they're always numbers." That record is called type feedback.

When a function gets hot (runs a lot), V8 moves it up a tier. For dist above, V8's own trace showed:

Maglev after about 500 calls, taking 0.08 ms to compile.
TurboFan after about 16,900 calls, taking 0.61 ms to compile. That's about 8× more compile time for code about 1.4× faster.

That trade is why the tiers exist. Most code runs once, at startup. Spending TurboFan's effort on all of it would make every page load slower and save nothing.

A function's life in V8

1. Your source  — Parsed into bytecode
2. Ignition     — Every function starts here, counting calls and recording types
3. Sparkplug    — Quick machine code for warm functions
4. Maglev       — Optimized with the types seen so far
5. TurboFan     — Heaviest optimization for the hottest code
  ├─ Types stay the same → Fast code keeps running
  └─ A new type shows up → Optimized code thrown away → Back to the lower tiers

Optimized code is a bet on the types seen so far. A surprise cancels the bet.

The catch: optimized code is a bet

Maglev and TurboFan are fast because they assume the future looks like the past. "Every p.x has been a number, so skip the type check and do raw number math."

If that assumption breaks, the fast code is wrong. So V8 throws it away and goes back to a lower tier. This is called deoptimization. Here, a single call with a string inside was enough:

dist({ x: "3", y: 4 }); // V8 drops both Maglev and TurboFan code for dist

The function still works, it just runs slower until V8 learns the new types and optimizes again.

In practice

You can't pick a tier, and you don't need to. V8 decides. But two habits follow from the model:

1. Keep hot code predictable. Pass the same kinds of values to a hot function: same object shapes, numbers staying numbers. That keeps the bet safe. (For why object shape matters, see hidden classes.)

// before: one function, many types: harder to optimize
format(42); format("42"); format(null);

// after: one type per hot function
formatNumber(42);

2. Warm up before you measure. The first few hundred calls of any benchmark measure Ignition, not your code at its best. Run the code many times, then time it. Every number in this post was taken after a warm-up.

Honest stakes: for most app code (click handlers, a React render, a fetch), the tiers just work and none of this is worth thinking about. It matters in hot loops: parsers, data processing, animation, game logic. Even there, profile first. A function that never gets hot never reaches TurboFan anyway.

Say it in an interview

"V8 is a JIT engine with tiers. Everything starts in Ignition, an interpreter that runs bytecode and records type feedback. Code that runs often gets compiled by Sparkplug, then optimized by Maglev and finally TurboFan, which make fast machine code based on the types seen so far. If those types change, V8 deoptimizes and falls back to a lower tier. So JavaScript is both interpreted and compiled, and keeping hot code type-stable lets it stay in the fast tiers."

Cheat sheet

Remember	Detail
Ignition	Interpreter. Every function starts here
Sparkplug	Quick, non-optimizing machine code
Maglev	Fast optimizer, uses type feedback
TurboFan	Slow, strongest optimizer, for the hottest code
Deoptimization	Types change → optimized code thrown away
Measured here	Same function: 50.9 ns → 1.19 ns per call (43×)

TL;DR

V8 translates JavaScript in four tiers, spending more effort only on hot code.
Optimized code is a bet that types stay the same. A surprise type cancels it.
The same function ran 43× faster in TurboFan than in Ignition alone.
Keep hot functions type-stable, warm up before benchmarking, and profile before optimizing.

Going deeper

Advanced and optional. Everything above is enough to explain this in an interview. This part is for the curious: full numbers, edge cases and what's still unproven.

How the numbers were measured

Node 26.13 (V8 14.6), Apple M3 Pro, median of 7 fresh processes per setting.

The benchmark calls dist through a total function that sums it over 10,000 points like { x: i % 97, y: i % 13 }. After 300 warm-up runs, it times 2,000 more and divides by the number of points. V8's --max-opt flag caps the highest tier allowed:

Flag	Highest tier	ns per point
`--max-opt=0`	Ignition	50.9
`--max-opt=1`	Sparkplug	31.9
`--max-opt=2`	Maglev	1.65
`--max-opt=3`	TurboFan	1.19

The jump from Sparkplug to Maglev is the big one, because that's where V8 starts using type feedback: once it knows p.x is always a number on the same object shape, the property read becomes a single memory load and the math becomes raw float operations. TurboFan's extra win here comes mostly from heavier work like inlining and better register use.

In this test, dist gets inlined into total, so the timings describe the hot loop as a whole. A bigger function would show a different ratio.

How the tier-ups were traced

node --trace-opt --trace-deopt --no-concurrent-recompilation trace.js

The script called dist 20,000 times, printing a marker every 25 calls, then passed it one object with a string. The trace printed marking dist for optimization to MAGLEV, reason: hot and stable near call 500 and the same for TURBOFAN_JS near call 16,900. After the string input it printed marking dependent code ... for deoptimization, reason: dependent field representation changed for both the TurboFan and Maglev code.

--no-concurrent-recompilation makes compiling happen right away on the main thread, so the call count is easy to read. Normally V8 compiles Maglev and TurboFan code on background threads and swaps it in when ready.

The thresholds aren't fixed call counts

V8 doesn't tier up after a set number of calls. Each function has an interrupt budget that runs down as its bytecode executes, scaled by the function's size, and loops count too. So a tiny function and a big one reach Maglev after very different call counts. Treat "500" and "16,900" as what happened for this one function, not as rules.

The trace doesn't show Sparkplug, because Sparkplug isn't counted as optimization. It kicks in early, before Maglev.

On-stack replacement (OSR)

A function called once that runs a long loop never gets "called a lot". V8 handles that with on-stack replacement: it compiles optimized code for the loop and jumps into it in the middle of the running call. That's why a single long loop at the top of a script still gets fast.

Tiers have changed over time

Older articles describe only two tiers: the Ignition interpreter and the TurboFan optimizer. Sparkplug shipped in 2021 (Chrome 91) and Maglev in 2023 (Chrome 117) to fill the gap between "slow interpreter" and "expensive optimizer". Newer V8 versions are also building Turboshaft, a new backend for TurboFan, and Turbolev, which feeds Maglev's front end into it. The model in this post (cheap tiers first, expensive tiers for hot code, deopt on surprise) has stayed the same.

React Server Components vs 'use client': What Actually Ships to the Browser

Mohsen Fallahnejad — Fri, 13 Nov 2026 10:16:11 +0000

Add a log to a Client Component:

"use client";

export function LikeButton() {
  console.log("rendering LikeButton"); // shows up in your terminal too
  return <button>Like</button>;
}

Load the page, and the message appears in the terminal where Next.js runs, not just in the browser console.

So "use client" doesn't mean "runs only in the browser". It means something else, and once you see what, it's clear where to put it.

The mental model: the result vs the result plus the code

Both kinds of component render on the server first, so the browser gets real HTML. The difference is what gets sent along with it:

A Server Component sends only its result. A Client Component sends its result plus the code to run it again in the browser.

The result is enough to look at. The code is what lets a component react: to clicks, typing, state and effects.

How it works

In the Next.js App Router, every component is a Server Component by default.

A Server Component runs only on the server, at build time or per request. It can be async, read a database or a file, and use secret keys. Its result is sent to the browser. Its code is never sent. A heavy library used only inside a Server Component adds zero bytes to your bundle.

A Client Component also renders on the server for the first HTML. Then its JavaScript is downloaded and React hydrates it: attaches event handlers and starts its state, so the HTML becomes interactive.

"use client" marks a boundary. The file with the directive, and everything it imports, goes into the browser bundle. You only write it at the entry point. The components it imports are client code automatically.

	Server Component	Client Component
Renders on the server	yes	yes (first HTML)
Its code sent to the browser	no	yes
`async`, database, secrets	yes	no
`useState`, `useEffect`, `onClick`	no	yes
Browser APIs (`window`, `localStorage`)	no	yes, in effects and handlers

Data crossing the boundary

Props passed from a Server Component to a Client Component have to travel over the network, so they must be serializable: strings, numbers, plain objects, arrays, dates, and a few more. A regular function can't be sent:

Functions cannot be passed directly to Client Components unless you
explicitly expose it by marking it with "use server".

Server Components can sit inside Client Components

A Client Component can't import a Server Component, but it can receive one as children:

// page.tsx (Server Component)
<Modal>
  <Cart /> {/* still a Server Component: its code stays on the server */}
</Modal>

<Cart /> is rendered on the server, and Modal only gets its result. That's how a client-side wrapper (a modal, a tab panel, a theme provider) can hold server-rendered content.

In practice

Push "use client" down to the leaves. The usual mistake is putting it at the top of a whole page because one button needs onClick:

// before: page.tsx
"use client"; // the whole page and all its imports now ship to the browser

// after: page.tsx stays a Server Component
import { LikeButton } from "./LikeButton"; // only this file has "use client"

export default async function Page() {
  const post = await getPost();
  return (
    <article>
      <h1>{post.title}</h1>
      <PostBody post={post} />
      <LikeButton postId={post.id} />
    </article>
  );
}

Now only the button's code ships. The page, the data fetching and everything PostBody imports stay on the server.

This blog works that way. Each post's MDX is compiled, and every code block is syntax-highlighted, inside a Server Component. I checked the production build: the browser chunks contain highlight.js's CSS theme, but none of its JavaScript. Readers get colored code without downloading a highlighter.

Two habits that prevent mistakes:

Put import "server-only" at the top of files with secrets or database code. If a Client Component ever imports them, the build fails instead of leaking.
Pass plain data (postId) to Client Components, not whole objects with methods.

Honest stakes: a Client Component in the wrong place still works. It costs bundle size and hydration time, which you feel on slow phones and big pages. Moving one "use client" from a page to a button is often the cheapest performance fix in an App Router project.

Say it in an interview

"In the App Router, components are Server Components by default: they run only on the server, can fetch data directly, and their code never reaches the browser. "use client" marks a boundary: that file and everything it imports are bundled for the browser. Client Components still render on the server for the first HTML, then hydrate to become interactive. So I keep pages and data fetching on the server and put "use client" only on the small interactive pieces, passing them serializable props."

Cheat sheet

Remember	Detail
Default	Server Component: runs on the server, code never shipped
`"use client"`	Boundary: this file + its imports go to the browser
Client Components	Still render on the server first, then hydrate
Props across the boundary	Must be serializable: no regular functions
`children`	Server Components can be passed into Client Components
Where to put it	On the leaves: the button, not the page

TL;DR

Server Components send the result. Client Components send the result plus the code.
"use client" doesn't mean browser-only: Client Components render on the server too.
Everything a "use client" file imports ships to the browser.
Put the directive on the smallest interactive piece and pass it plain data.

Going deeper

Advanced and optional. Everything above is enough to explain this in an interview. This part is for the curious: full numbers, edge cases and what's still unproven.

What the browser actually receives

On the server, Next.js renders Server Components into the RSC Payload, a compact description of the rendered tree. It holds:

the rendered result of every Server Component,
placeholders saying "a Client Component goes here", with a reference to its JavaScript file,
the props passed to each Client Component.

On the first load, Next.js uses the payload plus the Client Components to produce HTML, so the page shows before any JavaScript runs. Then the browser loads the client JavaScript, React reads the payload, and hydrates the Client Components.

On later navigations, the browser only fetches the RSC Payload for the new route (often prefetched) and React updates the page without a full reload.

`"use server"` isn't the opposite of `"use client"`

There's no directive for "this is a Server Component", because that's the default. "use server" marks Server Functions: functions the client can call, which run on the server. They're the one kind of function you can pass as a prop to a Client Component, because React sends a reference to them, not their code.

Context providers need a client wrapper

createContext and providers are client-only. Make a small Client Component that renders the provider around children, and use it in a Server Component layout. Render it as deep in the tree as you can, so more of the page stays static.

Third-party components without the directive

A package component that uses hooks but doesn't ship "use client" breaks when rendered from a Server Component. Fix it with a one-line wrapper:

// carousel.tsx
"use client";
export { Carousel } from "some-carousel-package";

Environment variables

Only variables starting with NEXT_PUBLIC_ are included in client code. Others are replaced with an empty string in the browser bundle, so a secret used in a Client Component reads as empty, which is a hint it's in the wrong place.

What wasn't measured

The highlight.js check above confirms the highlighter's JavaScript is not in the browser chunks of this blog's production build. It isn't a measurement of how many kilobytes it would cost if it were shipped.

Why React Needs key: The Bug That Moves Your Input to the Wrong Row

Mohsen Fallahnejad — Fri, 13 Nov 2026 10:15:41 +0000

Picture a shopping list with a note field on each row:

{items.map((item, i) => (
  <li key={i}>
    {item.name} <input placeholder="note" />
  </li>
))}

The list is Milk, Eggs, Bread. You type "2 dozen" next to Eggs. Then you delete Milk.

The list now shows Eggs and Bread, and "2 dozen" sits next to Bread.

Nothing crashed, nothing warned. The note moved to the wrong row because of key={i}.

The mental model: name tags, not seat numbers

Every render, React has to answer one question for each item in the list: "Is this the same item as last time, or a new one?"

It answers by looking at the key, like checking name tags at a door.

A key is a name tag. React matches items between renders by name tag, not by position.

If the tag matches, React keeps that item's state and DOM element and only updates what changed. If a tag disappears, that item is removed. If a new tag shows up, a new item is created.

The index makes a bad name tag because it's really a seat number. When someone leaves, everyone behind them moves up a seat, and their tag changes.

How it works

Comparing the new list to the old one is called reconciliation. Here's what React sees in the hook, with index keys:

Key	Before	After	What React concludes
`0`	Milk	Eggs	Same item, its name changed
`1`	Eggs	Bread	Same item, its name changed
`2`	Bread	(gone)	Item 2 was deleted

React thinks Bread was deleted and the other two were renamed. So it keeps the first two <li> elements, with their inputs, and removes the last one. The input that holds "2 dozen" belonged to key 1, and key 1 is now labeled Bread.

Now the same delete with real IDs, key={item.id}:

Key	Before	After	What React concludes
`milk`	Milk	(gone)	Milk was deleted
`eggs`	Eggs	Eggs	Same item, keep it
`bread`	Bread	Bread	Same item, keep it

Now React removes the right row, and "2 dozen" stays with Eggs.

This applies to any state inside a list item: text in an uncontrolled input, useState in a child component, focus, scroll position, a playing video, a running animation.

In practice

Use a stable ID from your data:

{items.map((item) => (
  <li key={item.id}>...</li>
))}

A good key is:

Unique among its siblings. Two different lists can reuse the same keys.
Stable. The same item gets the same key on every render.

Two keys to avoid:

<li key={i}>              // breaks when items are removed, inserted or reordered
<li key={Math.random()}>  // a new name tag every render: every row is recreated

Math.random() is worse than the index. Every render, React sees all new tags, so it throws away every row and builds it again. Inputs lose what you typed and lose focus while you type.

When the index is fine: the list never changes order, nothing is inserted or removed in the middle, and the items hold no state. A static list of footer links is fine with an index. If you leave key out, React uses the index for you and logs a warning.

Bonus: a key change resets state on purpose

Because a new key means "new item", you can use it to reset a component:

<ProfileForm key={userId} userId={userId} />

When userId changes, React throws away the old form, with all its half-typed state, and mounts a fresh one. That's simpler than an effect that clears each field by hand.

Honest stakes: with read-only lists you'll never see this bug. You'll hit it the first time a list item holds state (an input, a toggle, an expanded panel) and the list can be filtered, sorted or edited. That's most real apps.

Say it in an interview

"When a list re-renders, React matches old and new items by their key to decide which ones to keep, update, add or remove. That's part of reconciliation. If you use the index as the key, removing or reordering items shifts the keys, so React keeps the wrong elements and state ends up on the wrong item. Keys should be stable and unique among siblings, usually an ID from the data. Changing a key also forces React to remount a component, which is a clean way to reset its state."

Cheat sheet

Remember	Detail
What a key does	Tells React which item is which between renders
Same key	Keep state and DOM, update props
New or missing key	Mount a new item / remove the old one
Good key	Stable, unique among siblings: `item.id`
Index as key	Only for static lists with no state
`Math.random()`	Never: every row is recreated each render

TL;DR

React matches list items by key, like checking name tags.
The index is a seat number: it shifts when items move, so state lands on the wrong row.
Use a stable ID from your data.
Change a component's key to reset its state on purpose.

Going deeper

Advanced and optional. Everything above is enough to explain this in an interview. This part is for the curious: full numbers, edge cases and what's still unproven.

Why React doesn't just compare everything

Finding the smallest set of changes between two trees is expensive in general. React avoids that with two shortcuts, described in the React docs on reconciliation:

Different element types make different trees. If a <div> becomes a <section>, React doesn't compare their children. It tears down the old subtree and builds the new one.
Keys mark which children are the same. Within one parent, React matches children by key. Without keys, it can only match by position.

Together, these make each update roughly proportional to the number of elements, instead of something much slower.

Index keys also cost speed

Correctness is the main problem with index keys, but there's a performance cost too. Insert one item at the top of a 1,000-row list with index keys, and every row's key now points at different data, so React updates all 1,000 rows. With ID keys, React adds one row and leaves the rest alone.

Keys only matter among siblings

A key is compared only with the other children of the same parent. Moving an item to a different parent always remounts it, even with the same key. Keys don't need to be unique across the whole page.

Fragments can take a key

When each item renders more than one element without a wrapper, use the long form of a Fragment:

import { Fragment } from "react";

{terms.map((t) => (
  <Fragment key={t.id}>
    <dt>{t.word}</dt>
    <dd>{t.meaning}</dd>
  </Fragment>
))}

The short <>...</> syntax can't take a key.

`key` is not a prop

React reads key itself and doesn't pass it to your component, so props.key is undefined. If the child needs the ID, pass it again under another name: <Row key={item.id} id={item.id} />.

Generating IDs

If your data has no ID, create one when the item is created (for example with crypto.randomUUID()) and store it with the item. Generating it during render is the same as Math.random(): a new key every time.

Packed vs Holey Arrays in V8: Why new Array(n) Makes Spread 4x Slower

Mohsen Fallahnejad — Wed, 11 Nov 2026 09:56:06 +0000

Two arrays. Same million numbers, in the same order, with no gaps in either:

const a = [];
for (let i = 0; i < 1_000_000; i++) a.push(i);

const b = new Array(1_000_000);
for (let i = 0; i < 1_000_000; i++) b[i] = i;

Copy each one with spread:

[...a]: 0.17 ms
[...b]: 0.71 ms

Same contents, same length, and b takes four times as long to copy. The difference is how b started, not what it holds.

The mental model: a label in permanent marker

V8 puts a label on every array's storage box. The label says two things:

What's inside: small whole numbers, any numbers, or anything at all.
Whether there may be gaps: packed (no gaps) or holey (maybe gaps).

V8 reads the label to pick its fastest code. And the label is written in permanent marker: it can become more general, but it never goes back, even after you fix the contents.

The label describes the array's history, not its contents.

V8 calls these labels elements kinds.

How it works

There are three content labels, from most specific to most general:

Label	Holds	Example
`SMI`	small whole numbers	`[1, 2, 3]`
`DOUBLE`	any numbers	`[1, 2, 3.5]`
`ELEMENTS`	anything	`[1, 2, "3"]`

Each one comes in a packed and a holey version, so a plain array has one of six labels.

You can read part of the label with node --allow-natives-syntax:

%HasHoleyElements([1, 2, 3]);    // false
%HasHoleyElements(new Array(3)); // true  ← born with 3 empty slots

new Array(1_000_000) doesn't create a million undefineds. It creates a million holes: slots that don't exist yet. Filling them in doesn't change the label, because V8 won't scan a million slots to check that every gap is gone.

Why gaps cost time: reading a hole means "look further up, on Array.prototype". So on a holey array, V8 has to be ready for a hole at every slot. A packed array can be copied in one go. A holey one takes a slower path that handles slot by slot, and that's the 4× in the hook.

These moves change the label for good:

Holey: start with new Array(n) or [1, , 3], delete arr[i], or write past the end (arr[arr.length + 5] = x).
DOUBLE: add one decimal, NaN or -0.
ELEMENTS: add one string, object, null or undefined.

const c = [1, 2, 3];
c.push(4.5);
c.pop();     // only whole numbers again…
             // …but the label still says DOUBLE

In practice

Build arrays so they're packed from the first write:

// before: born holey, stays holey
const ids = new Array(rows.length);
for (let i = 0; i < rows.length; i++) ids[i] = rows[i].id;

// after: packed
const ids = rows.map((r) => r.id);

push, map, filter and Array.from({ length: n }, fn) all give packed arrays.

Three more habits:

Fill front to back. Writing into [] from the last index down made building a million-item array 6.6× slower here (38.5 ms vs 5.8 ms).
Don't delete array items. Use splice, or filter into a new array.
Keep number arrays numeric. One null placeholder moves the whole array to ELEMENTS.

Honest stakes: the hook costs about half a millisecond per million-item copy. A plain for loop over a holey array was about 1.4× slower. Most apps will never notice. Big arrays in hot paths will: data grids, charts, parsers, game loops. Profile first. When it is the problem, the fix is usually one line where the array is created.

Say it in an interview

"V8 tracks an elements kind for every array: whether it holds small integers, doubles or anything, and whether it's packed or may have holes. Optimized code and built-ins like spread pick fast paths from that kind. Transitions only go one way, toward more general, so new Array(n) stays holey even after you fill every slot. To keep arrays fast, build them with push, map or Array.from, avoid delete, and don't mix types into number arrays."

Cheat sheet

Remember	Detail
Elements kind	The label: what's inside + packed or holey
Content labels	`SMI` → `DOUBLE` → `ELEMENTS`, one way only
Holey makers	`new Array(n)`, `[1, , 3]`, `delete`, writing past the end
Packed makers	`push`, `map`, `filter`, `Array.from`
Cost seen here	Spread 4.3× slower, `for` loop 1.4× slower on holey

TL;DR

V8 labels every array by what it holds and whether it may have gaps.
Labels only get more general. Filling the gaps never makes an array packed again.
Spreading a million-item holey array took 0.71 ms vs 0.17 ms for a packed one.
Create arrays with push, map or Array.from, and profile before you rewrite anything.

Going deeper

Advanced and optional. Everything above is enough to explain this in an interview. This part is for the curious: full numbers, edge cases and what's still unproven.

Full measurements

All numbers: Node 26.13 (V8 14.6), Apple M3 Pro, median of 7 fresh processes. Each array holds 1,000,000 small integers, and the timed code runs inside functions after a warm-up.

Spread ([...arr]), by how the array was built:

Built with	Label	Time per copy
`push` in a loop	packed	0.17 ms
`Array.from({ length }, fn)`	packed	0.17 ms
`new Array(n).fill(0)`, then index writes	packed	0.16 ms
`new Array(n)`, then index writes	holey	0.71 ms
`push`, then `delete a[5]; a[5] = 5`	holey	0.73 ms

The last row has no gaps at all. One delete, followed by putting the value straight back, is enough to make it holey for good.

Other operations, packed vs holey (ns per item):

Operation	Packed	Holey
`for` loop sum	0.58	0.84
`[...arr]`	0.17	0.72
`slice()`	0.16	0.15
`includes` / `indexOf`	0.15	0.15
`for...of`, `reduce`, `map`	~5.2	~5.4

Not every operation cares. slice, includes and indexOf were the same speed either way. The callback-based methods were dominated by the callback in this setup, so the label barely showed.

Building a million-item array:

How	Time
`push`, front to back	5.8 ms
`[]`, index writes from the end	38.5 ms
`new Array(n)`, index writes from the end	1.9 ms (but holey)

Memory: one string boxes every decimal

A DOUBLE array stores raw 8-byte numbers. Once it becomes ELEMENTS, every decimal has to live in its own small object on the heap, and the array stores pointers to them:

1,000,000 numbers	Label	Heap
whole numbers	`SMI`	7.6 MB
whole numbers, after one string was written and replaced	`ELEMENTS`	7.6 MB
decimals	`DOUBLE`	7.6 MB
decimals, after one string was written and replaced	`ELEMENTS`	22.9 MB

Small whole numbers fit inside the pointer itself, so they cost nothing extra. Decimals tripled.

`fill()` depends on your Node version

new Array(n).fill(0) gives a holey array in Node 22 (V8 12.4) and a packed one in Node 24 and 26. Array.from and push are packed in every version, so they're the safer advice.

Why holes are expensive

A hole isn't undefined: reading one has to check the prototype chain, because Array.prototype[5] could exist. V8 keeps a global "nobody has put indexed properties on Array.prototype" flag (a protector) so most hole reads can just return undefined, but code still has to check for the hole on each read. For spread, the result must be packed, so V8 likely has to walk the holey array and turn holes into undefined, instead of copying the storage in one block. That's a reasonable reading of the numbers, not something this benchmark isolates.

What didn't matter

Reading one index past the end (i <= arr.length) used to be a well-known slowdown. Here it cost about 0.69 vs 0.58 ns per item: real, but small on this V8 version.

Measuring it yourself

Time code inside functions, not at the top level of a script. A top-level version of the hook measured 0.51 vs 1.05 ms, because the top-level loop itself wasn't optimized and hid half the difference.

More labels

V8 has more elements kinds than these six: frozen and sealed arrays, typed arrays, arguments objects, and a DICTIONARY mode for very sparse arrays (like writing only index 1,000,000 into []). The six above are the ones plain arrays move through every day.

Next.js use cache, cacheLife and cacheTag: How One View Counter Rebuilt Every Page

Mohsen Fallahnejad — Wed, 11 Nov 2026 09:55:36 +0000

Vercel's usage page told me this blog had used 2 h 32 min of function CPU in 30 days: 80% of everything on my account. It's a blog. The posts only change when I deploy.

The cause was one line near the top of my pages:

const stats = await getPostStats(); // read + comment counts, cached for 5 minutes

The counts were cached for 5 minutes. But the 5-minute timer didn't stay on the counts. Every page that showed them took it on, so every post, tag and series page went stale every 5 minutes and was rebuilt on the server the next time a reader or a crawler came by.

The mental model: a shared fridge

Think of the server cache as one fridge that every visitor shares.

"use cache" puts a result in the fridge. The next caller takes it out instead of cooking it again.
cacheLife is the best-before sticker. After that date, the next visitor still gets the old dish while a fresh one cooks in the background.
cacheTag is the name on the lid. You can throw out every box labelled comments at once, the moment the comments change.

A page is only as fresh as the shortest best-before date inside it.

How it works

`"use cache"`: store the result

async function getPost(slug: string) {
  "use cache";
  return db.post.findUnique({ where: { slug } });
}

The arguments are part of the key, so getPost("a") and getPost("b") are separate boxes in the fridge. You can put "use cache" on a component too, and its rendered output is stored.

One rule: you can't read cookies() or headers() inside. Read them outside and pass the value in as an argument.

`cacheLife`: when it goes stale

async function getExchangeRates() {
  "use cache";
  cacheLife("hours"); // or "minutes", "days", "max", or your own profile
  return fetch("https://api.example.com/rates").then((r) => r.json());
}

After the time is up, the next request still gets the old result straight away, and Next.js refreshes it in the background. Nobody waits.

The trap from my hook: a page's prerendered HTML is a cached thing too. If something inside it has a 5-minute life, the whole page gets a 5-minute life. That's how one counter set the clock for every page.

`cacheTag`: throw it out on demand

async function getComments(slug: string) {
  "use cache";
  cacheLife("max");                         // no timer...
  cacheTag("comments", `comments:${slug}`); // ...just a name
  return db.comment.findMany({ where: { slug, approved: true } });
}

// when a comment is approved:
revalidateTag("comments", "max"); // route handler: serve old, refresh in background
updateTag(`comments:${slug}`);    // server action: the next request waits for fresh data

A timer is a guess about when data changes. A tag means you refresh exactly when it changes. My comment list used to sit on the 5-minute timer. Now it's "max" plus a tag, and new comments still show up straight away.

Which one to use

Your data	Use
Changes only when you deploy (posts, docs)	Nothing. It's static already
Changes when you change it (CMS, comments, products)	`"use cache"` + `cacheLife("max")` + `cacheTag`, invalidate on write
Changes on its own, slowly (rates, star counts)	`"use cache"` + `cacheLife("hours")`
Changes constantly and shows on every page (view counts)	A small cached API route, fetched in the browser
Belongs to one user (cart, dashboard)	Not the shared fridge. Fetch it per user

Where TanStack Query fits

They solve different problems, so you use both:

Server cache (use cache) answers: "Don't hit the database for every visitor." One fridge, shared by everyone.
TanStack Query answers: "Don't refetch for this visitor every time a component mounts." It's each visitor's own lunchbox in browser memory, with refetch on focus, polling, retries and optimistic updates.

The pattern I ended up with: render the page from server-cached data, and load live or per-user bits in the browser from a route handler that is itself cached.

// app/api/stats/route.ts — one shared, cached answer
export async function GET() {
  return Response.json(await getPostStats()); // getPostStats uses "use cache"
}

// in the browser — one request per visitor, shared by every component
const { data } = useQuery({
  queryKey: ["stats"],
  queryFn: () => fetch("/api/stats").then((r) => r.json()),
  staleTime: 30 * 60_000, // match the server's refresh time
});

When the user changes something, clear both layers: updateTag in the server action, then queryClient.invalidateQueries({ queryKey: [...] }) in the browser.

Honest stakes: after moving the counts into the browser, the build output for my post, tag and series pages went from refresh every 5m to refresh every 1d. Only /api/stats still refreshes on a timer. Most apps won't hit this exact bug, but any value read high up in a page can quietly set the clock for the whole page.

Say it in an interview

"use cache marks a function or component whose result Next.js stores and reuses, keyed by its arguments. cacheLife sets how long it stays fresh and when it's refreshed in the background, and a page can't stay cached longer than the shortest life inside it. cacheTag names entries so I can invalidate them when the data changes, with revalidateTag or updateTag. TanStack Query is a separate, per-user cache in the browser: I use the server cache for shared data and TanStack Query for live or per-user data."

Cheat sheet

Tool	One line
`"use cache"`	Store this result; arguments are the key
`cacheLife`	Best-before: stale → refresh in the background
`cacheTag` + `revalidateTag`	Throw out by name, serve old while refreshing
`cacheTag` + `updateTag`	Throw out by name, next request waits (server actions only)
TanStack Query	Per-visitor browser cache on top

TL;DR

"use cache" stores, cacheLife sets when it goes stale, cacheTag lets you clear it on demand.
A page is only as fresh as the shortest-lived cache inside it. One 5-minute counter made all my pages refresh every 5 minutes.
Prefer "cache forever + tag" for data you control, timers for data you don't.
Use TanStack Query for per-user and live data, ideally fetching from a cached route.

Going deeper

Advanced and optional. Everything above is enough to explain this in an interview. This part is for the curious: full numbers, edge cases and what's still unproven.

The three numbers behind `cacheLife`

Every profile is three numbers:

Number	Meaning
`stale`	How long the browser may reuse it without asking the server
`revalidate`	After this, the next request triggers a background refresh
`expire`	After this with no traffic at all, the next request waits for a fresh result

The built-in profiles (Next.js 16.4):

Profile	`stale`	`revalidate`	`expire`
`default`	5 min	15 min	never
`seconds`	30 s	1 s	1 min
`minutes`	5 min	1 min	1 h
`hours`	5 min	1 h	1 day
`days`	5 min	1 day	1 week
`weeks`	5 min	1 week	30 days
`max`	5 min	30 days	1 year

You can define your own in next.config under cacheLife. Mine was stats: { stale: 300, revalidate: 300, expire: 86_400 }.

Too short to prerender

Very short lives don't get baked into the static page at all:

revalidate: 0 or expire under 5 minutes: left out of the prerender and computed on every request (a "dynamic hole").
stale under 30 seconds: also left out of the prerender.

My 5-minute profile sat just above that line, so it was baked in and set the clock for the whole page.

Nested caches

If an outer "use cache" calls cacheLife itself, its own lifetime wins. If it doesn't, it starts from default (15 min) and shrinks to match any shorter cache inside it. A longer inner cache never makes it longer. Always set cacheLife explicitly so you can read the lifetime at the call site.

`revalidateTag` vs `updateTag`

	`revalidateTag(tag, "max")`	`updateTag(tag)`
Where	Server actions and route handlers	Server actions only
Next request gets	The old result while it refreshes	Fresh data (it waits)
Good for	Webhooks, admin tools, CMS updates	"I just saved it, show me my change"

Calling revalidateTag doesn't rebuild anything by itself. It marks entries stale, and each page refreshes when someone next visits it.

Where the fridge lives

Plain "use cache" keeps entries in memory on each server instance. On serverless platforms instances come and go, so expect some misses. "use cache: remote" stores entries in a shared cache that all instances can read, at the cost of a network round-trip and usually a platform fee. "use cache: private" is for results that depend on cookies or headers and must never be shared between users.

Measuring it yourself

Run next build and read the Revalidate column in the route table. Before my fix, /p/javascript-this-explained showed 5m. After it, 1d (that last day comes from a cached copyright year in the footer).

How 'this' Works in JavaScript: Decided by the Call, Not the Code

Mohsen Fallahnejad — Tue, 10 Nov 2026 11:15:18 +0000

Same function, two calls, two different results:

const user = {
  name: "Sara",
  hello() { return `Hi, ${this.name}`; },
};

user.hello();       // "Hi, Sara"

const hello = user.hello;
hello();            // TypeError: Cannot read properties of undefined (reading 'name')

Nothing about the function changed. Only how it was called.

The mental model

this is like the word "me". It means whoever is speaking right now, not whoever wrote the sentence. A function finds out what this is at the moment it's called.

For arrow functions, there's one exception: they never say "me" themselves. They repeat the "me" of the function around them.

How it works: look at the call

To find this, ignore where the function was written. Look at the line that calls it, and check these rules in order:

How it's called	`this` is	Example
With `new`	the new object	`new User("Sara")`
With `call`, `apply` or `bind`	whatever you pass	`hello.call(admin)`
As `obj.method()`	the object left of the dot	`user.hello()` → `user`
Plain `fn()`	`undefined`	`hello()`

The last row explains the hook. hello() has nothing left of the dot, so this is undefined, and reading .name from it throws.

(In old scripts without strict mode, a plain call gives the global object instead of undefined. Modules and classes are always strict, so undefined is what you'll see in modern code.)

The "left of the dot" rule works with any object, even one that borrowed the method:

const admin = { name: "Ali", hello: user.hello };
admin.hello(); // "Hi, Ali"

Arrow functions: no "me" of their own

An arrow function doesn't get its own this. It uses the this of the code around it, the place where it was written.

const timer = {
  name: "Timer",
  start() {
    setTimeout(() => console.log(this.name)); // "Timer"
  },
};
timer.start();

The arrow sits inside start, and start was called as timer.start(), so the arrow's this is timer.

That's also why an arrow is a bad choice for an object method:

const box = { name: "Box", hi: () => this.name };
box.hi(); // this is not box: an arrow ignores the dot

Is `this` part of scope?

No, and that's the main source of confusion. Variables are decided by where the code is written. That's scope: a function can see the variables around it. this is decided by the call, so the same function can get a different this each time.

Arrow functions are the one place where the two meet. An arrow looks up this the same way it looks up a variable: from the code around it.

In practice

You'll hit this mostly when you pass a method somewhere else: a callback, an event handler, setTimeout(user.hello). The method gets called later as a plain fn(), and this is lost.

Two fixes:

setTimeout(() => user.hello());     // call it with the dot yourself
setTimeout(user.hello.bind(user));  // or lock `this` with bind

Say it in an interview

"this depends on how a function is called, not where it's defined. With new it's the new object, with call/apply/bind it's what you pass, with obj.method() it's the object before the dot, and with a plain call it's undefined in strict mode. Arrow functions don't have their own this; they use the this of the surrounding code."

Cheat sheet

this = "me": decided when the function is called.
Look at the call: new → new object, call/bind → what you pass, obj.fn() → obj, fn() → undefined.
Arrow functions use the this of the code around them.
Scope (variables) follows where code is written. this follows how it's called.
Passing a method as a callback loses this: wrap it in an arrow or use bind.

Originally published on Bitlyst.

What Is Turbopack? How Next.js's Rust Bundler Avoids Doing Work Twice

Mohsen Fallahnejad — Tue, 10 Nov 2026 10:53:25 +0000

I built this blog twice in a row. The first next build compiled in 2.8 seconds. The second, with no code changes, compiled in 0.45 seconds. Same code, same machine. The difference is the whole idea behind Turbopack.

The mental model

Turbopack is a chef who never chops the same onion twice. Every small prep step is labeled and kept in the fridge. When you change one recipe, the chef redoes only the steps that used the changed ingredient and reuses everything else.

A bundler is the tool that turns your source files (TypeScript, JSX, CSS) into the files the browser and server actually run. Turbopack is the bundler built into Next.js, written in Rust, and it's the default since Next.js 16. (If you're unsure what a bundler does next to npm or Bun, see who does what in a JavaScript kitchen.)

How it works

1. It breaks the work into tiny labeled steps

Bundling is many small jobs: read a file, parse it, compile its JSX, find its imports, build a chunk. Turbopack runs each job as a small function and remembers its result, plus what that result depended on.

2. A change only redoes what depends on it

When you save Button.tsx, Turbopack knows which steps read that file. Those steps run again. Steps for the other 500 files are reused from the fridge. That's called incremental computation: doing only the work that changed.

3. The fridge survives restarts

Those results are saved to disk in .next/cache. Close your laptop, run next dev tomorrow, and most of the prep is already done. That's why my second build compiled 6× faster.

4. It only cooks what's ordered

In development, Turbopack compiles only the pages you open. A 200-page app doesn't compile 200 pages before you see the first one.

5. One kitchen for server and browser

Next.js builds code for the server and for the browser. webpack ran separate compilers and stitched their output together. Turbopack keeps one graph (a map of which file imports which) for both, so it knows exactly what changed on each side.

Turbopack vs webpack vs Vite

	webpack	Vite	Turbopack
Written in	JavaScript	JavaScript (plus native helpers)	Rust
In development	Bundles everything up front	Serves files almost unbundled	Bundles, but only what changed and what you opened
Remembers past work	Partly	Partly	Every small step, saved to disk
Where you use it	Anywhere	Anywhere	Next.js

The Vite row is a real design choice. Serving files unbundled is fast for small apps, but a big app can mean thousands of browser requests. Turbopack bundles in dev too, but cheaply, because almost every step is a cache hit.

In practice

You're probably using it already: next dev and next build use Turbopack by default. To compare, add --webpack.

Be honest about the stakes. On this blog, the full build took about 11 seconds just to generate 243 static pages, cold or warm. Turbopack speeds up compiling, not your data fetching or prerendering. You feel it most in big apps, on dev server restarts, and when you save a file and wait for the page to update.

Two things it doesn't do:

It doesn't check types. It removes TypeScript types without reading them. Your editor and next build do the checking.
It doesn't run webpack plugins. Most webpack loaders work, but a project that depends on a custom webpack plugin has to stay on --webpack for now.

Say it in an interview

"Turbopack is the Rust bundler built into Next.js. Its main idea is incremental computation: it splits bundling into small functions, caches each result with what it depended on, and when a file changes it reruns only the affected steps. The cache is saved to disk, it compiles only the pages you request in dev, and it keeps one module graph for server and client code."

Cheat sheet

What: the default bundler in Next.js 16, written in Rust.
Core idea: remember every small step, redo only what a change touches.
Cache: saved in .next/cache, survives restarts.
Dev: compiles only the pages you open.
Doesn't: type-check, or run webpack plugins (use --webpack if you need them).

Going deeper

Advanced and optional. Everything above is enough to explain this in an interview. This part is for the curious: full numbers, edge cases and what's still unproven.

How I measured

Project: this blog, Next.js 16.4.6, 243 static pages, on my Mac.
Cold: rm -rf .next, then next build. Compile step: 2.8 s.
Warm: a second next build right after. Compile step: 0.45 s.
Only the Turbopack cache deleted (rm -rf .next/cache/turbopack): compile went back to 2.7 s, so the speedup comes from Turbopack's disk cache.
Static page generation took about 11 s in every run. That part is rendering your pages, not bundling.
The numbers come from the ✓ Compiled successfully in … line next build prints.

Settings worth knowing

turbopackFileSystemCache: the disk cache, on by default for dev and build.
turbopack.resolveAlias: the Turbopack version of webpack.resolve.alias.
turbopack.rules: run webpack loaders (for example an SVG loader) inside Turbopack.

Edge cases

Platforms: Turbopack needs native binaries. macOS, Windows and Linux (x64 and ARM64) are supported. Other platforms fall back to WebAssembly, which can't run Turbopack, so you need --webpack there.
Babel: if Turbopack finds a Babel config file, it runs Babel for your files. That costs speed, since Babel runs in Node.js rather than in Rust.
Sass: custom sassOptions.functions aren't supported, because Rust can't call those JavaScript functions directly.
Compiling JSX and TypeScript: Turbopack uses SWC, another Rust tool. See how Next.js turns JSX and TypeScript into JavaScript.

turbopackRustReactCompiler: Running the React Compiler in Rust Inside Next.js

Mohsen Fallahnejad — Tue, 10 Nov 2026 10:52:55 +0000

This blog's next.config.mjs has two lines that look like they do the same thing:

reactCompiler: true,
experimental: { turbopackRustReactCompiler: true },

They don't. The first turns the React Compiler on. The second picks which version of it runs.

The mental model

Turbopack speaks Rust. The normal React Compiler speaks JavaScript. Without the flag, every component file goes through an interpreter: it's handed to Node.js, compiled there, and handed back. turbopackRustReactCompiler hires a native speaker instead: a Rust version of the compiler that runs inside Turbopack itself.

Same work, same output. Just no interpreter in the middle.

First: what the React Compiler does

The React Compiler is a build step that adds memoization to your components for you. Memoization means "remember the last result and reuse it if the inputs didn't change". It's what useMemo, useCallback and memo do by hand (quick refresher here).

// You write this:
function Price({ amount }) {
  const label = formatMoney(amount);
  return <span>{label}</span>;
}
// The compiler outputs a version that skips formatMoney
// and reuses the same <span> when amount hasn't changed.

It works at build time, on every file that has components or hooks. So how fast it runs adds to every build and every file save.

How it works

Without the flag: the Babel version

The official React Compiler is a Babel plugin, written in JavaScript. Turbopack is written in Rust, and Rust can't run JavaScript by itself. So for each file that needs compiling:

Turbopack sends the file's code to a Node.js process.
Babel reads it, runs the React Compiler, and writes out new code.
The new code goes back to Turbopack, which carries on bundling.

That's a trip between two worlds for every component file. You also need babel-plugin-react-compiler installed.

With the flag: the Rust version

turbopackRustReactCompiler swaps in a Rust version of the React Compiler that runs inside Turbopack's own process. The code never leaves Rust: no handoff to Node.js and no extra package to install.

What it saved on this blog

I timed the compile step of a cold next build on this blog (3 runs each, on my Mac):

React Compiler off      → 2.1 s
Babel React Compiler    → 2.8 s   (about a third slower)
Rust React Compiler     → 2.1 s   ← same as having it off

So the Rust version gave me the compiler's benefits for no measurable build cost, while the Babel version added about 0.7 seconds.

In practice

Turn it on if all three are true:

You use Turbopack, the default in Next.js 16. With --webpack this option throws an error.
You already have reactCompiler: true. The flag alone does nothing.
You're fine with experimental. It arrived in Next.js 16.3 to gather feedback before becoming the default.

Then remove babel-plugin-react-compiler from your dependencies. It's no longer used.

Be honest about the stakes: 0.7 seconds on a small blog is nothing. The saving grows with the number of component files, so you notice it in big apps and in dev, where every save recompiles.

Say it in an interview

"The React Compiler automatically memoizes React components at build time. Normally it runs as a Babel plugin, so a Rust bundler like Turbopack has to send each file to Node.js and back. Next.js's turbopackRustReactCompiler flag uses a Rust version of the compiler that runs natively inside Turbopack, which removes that round trip. It needs reactCompiler: true, works only with Turbopack, and is experimental."

Cheat sheet

reactCompiler: true turns the compiler on.
turbopackRustReactCompiler: true picks the Rust version instead of Babel.
Babel version: JavaScript, runs in Node.js, every file makes a round trip.
Rust version: runs inside Turbopack, no round trip, no Babel plugin needed.
Limits: Turbopack only, experimental since Next.js 16.3.

Going deeper

Advanced and optional. Everything above is enough to explain this in an interview. This part is for the curious: full numbers, edge cases and what's still unproven.

How I measured

Project: this blog, Next.js 16.4.6, 243 static pages, on my Mac.
Each run: delete .next/cache/turbopack and the build output, run next build, read the ✓ Compiled successfully in … line.
Configs: reactCompiler: false / reactCompiler: true with turbopackRustReactCompiler: false (with babel-plugin-react-compiler installed temporarily) / both true.
Results: off 2.1 / 2.1 / 2.1 s, Babel 3.2 / 2.7 / 2.8 s, Rust 2.2 / 2.1 / 2.1 s.
What this doesn't show: how the gap grows in a large app, or the effect on dev-mode reloads. Measure your own project before you quote a number.

Next.js already skips files that don't need it

Even with the Babel version, Next.js doesn't send every file to Babel. A fast check written in SWC (Next.js's Rust compiler) first looks for files with JSX or hooks, and only those go to the React Compiler. That keeps the Babel cost down, but every file that does need it still pays for the trip.

Where JavaScript tools run inside Turbopack

Turbopack runs JavaScript tools like Babel, PostCSS and webpack loaders in separate Node.js processes. The turbopackPluginRuntimeStrategy option chooses between child processes (the default) and worker threads. A Rust port removes the React Compiler from that path completely.

Bun vs npm, Yarn, Vite and Webpack: Who Does What in a JavaScript Kitchen

Mohsen Fallahnejad — Tue, 10 Nov 2026 10:52:54 +0000

Picture a job ad that says "Vite, webpack, npm, Yarn or Bun". It reads like five options for one job. It's actually three different jobs, and only one tool on that list tries to do all three.

The mental model

A JavaScript project is a kitchen. Node is the stove that cooks (runs your code). npm and Yarn are grocery delivery (they bring packages into the pantry, node_modules). webpack and Vite are the chef who plates the food for guests (they bundle your code for the browser). Bun is a kitchen-in-a-box: stove, delivery and chef in one tool.

Keep those three jobs in mind and every tool falls into place.

Job 1: the stove (runtime)

A runtime is the program that runs JavaScript outside the browser. For years that meant Node.js. When you type node server.js, Node runs it.

Bun is a runtime too: bun server.js does the same job. It's built from different parts (Zig and Apple's JavaScriptCore engine, while Node uses C++ and Google's V8), and it can run TypeScript files directly without a separate build step.

Job 2: grocery delivery (package manager)

A package manager reads package.json, downloads the packages it lists, and puts them in node_modules. It also writes a lockfile, a receipt of the exact versions it picked, so every machine gets the same ones.

npm ships with Node. It's the default.
Yarn was created in 2016 by Facebook and others, when npm was slow and had no lockfile. npm caught up later, so today the gap is small.
pnpm is another option. It saves disk space by storing each package once and linking to it.
bun install does the same job and works with the same package.json, much faster.

How much faster? I ran a quick test on my Mac: one project with React, Next.js, Vite, webpack, TypeScript and ESLint, cache already warm, node_modules deleted before each run.

npm install    # ~2.2 s
yarn install   # ~1.15 s  (Yarn 1)
bun install    # ~0.2 s   ← about 10× faster than npm

Job 3: the chef (bundler)

Browsers don't want your 300 source files, JSX and TypeScript. A bundler turns them into a few optimized files the browser can load.

webpack is the veteran (2012). It bundles everything, even during development, and can be configured to do almost anything. That power is also why its config files get long, and why big projects start slowly in dev.
Vite (2020) takes a shortcut in development: it serves your files to the browser almost as they are and only transforms the file you just changed. That's why the dev server starts in about a second. For production, it still runs a real bundler.
Turbopack is Next.js's own bundler, now the default there (how it works).
bun build is Bun's bundler.

So Vite vs webpack is a fair comparison: both are chefs. Vite vs npm isn't: one cooks, the other shops.

The whole kitchen in one table

Tool	Runtime (stove)	Package manager (delivery)	Bundler (chef)	Test runner
Node + npm	Node	npm	—	`node --test`
Yarn	—	✓	—	—
webpack	—	—	✓	—
Vite	—	—	✓	— (Vitest is separate)
Bun	✓	✓	✓	`bun test`

In practice

You don't have to switch everything at once. The easiest step is the most popular one: keep Node and your bundler, and use bun install only as a faster package manager. It reads the same package.json, so trying it is cheap: delete node_modules, run bun install, and see if your app still starts.

Be honest about the stakes. On a small project, 2 seconds vs 0.2 seconds barely matters on your laptop. It matters in CI, where installs run on every push, and in big monorepos. Running Bun as your production runtime is a bigger step. Most npm packages work, but Node has more years in production, so test your exact stack before you commit.

Say it in an interview

"These tools do different jobs. Node is a runtime that runs JavaScript. npm and Yarn are package managers that install dependencies. webpack and Vite are bundlers that prepare code for the browser, and Vite is faster in dev because it serves files without bundling them first. Bun is an all-in-one toolkit: a runtime, package manager, bundler and test runner, with a very fast bun install."

Cheat sheet

Three jobs: run code (runtime), install packages (package manager), prepare code for the browser (bundler).
Node = stove. npm / Yarn / pnpm = delivery. webpack / Vite / Turbopack = chef.
Bun = kitchen-in-a-box: all three plus a test runner.
Vite vs webpack: Vite skips bundling in dev, so it starts faster.
Easiest win: use bun install as a drop-in faster package manager.

Going deeper

Advanced and optional. Everything above is enough to explain this in an interview. This part is for the curious: full numbers, edge cases and what's still unproven.

Why bun install is so fast

Bun's team explains the tricks in Behind the Scenes of Bun Install (Lydia Hallie, September 2025). The main ideas:

Fewer trips to the operating system. Every file read or network call is a "system call", and each one has a cost. In their strace run, Bun made about 166,000 system calls for an install where npm made about 997,000 and Yarn about 4 million.
No Node layers in between. Bun is written in Zig and talks to the operating system directly, instead of going through Node's file system APIs and thread pool.
A binary cache of package info. Registry data is parsed once and saved in a compact binary format, so later installs skip parsing JSON.
Copy-on-write file copies. On macOS, Bun uses clonefile(), which can clone a whole package folder in one call without duplicating bytes on disk. On Linux it defaults to hard links.
A readable lockfile. bun.lock is text, so you can review it in pull requests. The older binary bun.lockb was dropped for that reason.

Their headline claim is that bun install is about 7× faster than npm, 4× faster than pnpm and 17× faster than Yarn on average. Those are the Bun team's own benchmarks, and the post doesn't state the machine or project for every test.

How my numbers were measured

Machine: my Mac (macOS), Node 22.18.0, npm 10.9.3, Yarn 1.22.22, Bun 1.4.4.
Project: a package.json with react, react-dom, next, typescript, vite, webpack and eslint (140 top-level packages, about 385 MB in node_modules).
Method: each tool installed once to warm its cache and write a lockfile. Then, three times each: delete node_modules and time install --ignore-scripts.
Results: npm 2.37 / 2.11 / 2.19 s, Yarn 1.17 / 1.15 / 1.12 s, Bun 0.23 / 0.23 / 0.19 s.
What this doesn't show: cold installs with an empty cache, which depend heavily on your network, or Yarn 4 and pnpm.

JavaScript Classes Are Functions in a Costume (and What this.constructor Points To)

Mohsen Fallahnejad — Tue, 10 Nov 2026 09:58:50 +0000

Ask JavaScript what a class is:

class User {}
typeof User; // "function"  ← surprise

Not "class". A function. Six years ago I wrote two short posts about this, one on what a class really is and one on a this trick inside classes. This post folds both into one idea.

The mental model

A JavaScript class is a function wearing a costume. Underneath it's the same constructor function JavaScript always had. The costume adds a few strict rules and nicer syntax.

Other languages build classes into the core of the language. JavaScript added the class keyword in ES2015 on top of what it already had: functions and prototypes.

What's under the costume

When you write a class, JavaScript builds a function. Calling it with new does what constructor functions always did:

Create an empty object.
Link that object to User.prototype, so it can use the class's methods.
Run the constructor body with this pointing at the new object.
Return the object.

class User {
  constructor(name) { this.name = name; }
  hello() { return `Hi, ${this.name}`; }
}

const u = new User("Sara");
Object.getPrototypeOf(u) === User.prototype; // true

The methods live once on User.prototype. Every user borrows them from there instead of carrying its own copy.

The three rules the costume adds

If it's a function, why not write a plain function? Because the costume changes how it behaves:

Rule	Plain function	Class
Strict mode	Only if you opt in	Always on inside the class body
Hoisting	Usable above its definition	Not usable before the line it's defined on
Calling it	Works with or without `new`	Throws without `new`

new Late(); // ReferenceError: Cannot access 'Late' before initialization
class Late {}

User("Sara"); // TypeError: Class constructor User cannot be invoked without 'new'

All three rules catch mistakes early. Forgetting new on an old constructor function quietly set properties on the global object. A class throws instead.

The this.constructor trick

The second old post was about this puzzle. A static method belongs to the class, not to its objects:

class User {
  static greet() { return "hi from User"; }
}

new User().greet(); // TypeError: ... greet is not a function

So how can the constructor call a static method without typing the class name? Through this.constructor:

class User {
  constructor() {
    console.log(this.constructor.greet()); // "hi from User"
  }
  static greet() { return "hi from User"; }
}

Here's why it works. Every prototype has a constructor property that points back to the function that made it. The new object doesn't have constructor itself, so JavaScript looks it up on User.prototype and finds User. this.constructor is the class, so this.constructor.greet() is just User.greet().

In practice

Picture a subclass that overrides the static method:

class Admin extends User {
  static greet() { return "hi from Admin"; }
}

new Admin(); // logs "hi from Admin"

If the constructor had hard-coded User.greet(), Admin would still print the User greeting. this.constructor picks the class that actually ran new, so subclasses get their own version for free. You'll see this in base classes that read static config, such as default options or a type name.

Day to day, you'll mostly hit the costume rules as error messages: "cannot be invoked without 'new'" or "before initialization". Now you know where they come from.

Say it in an interview

"A class in JavaScript is a special kind of function. new creates an object linked to the class's prototype and runs the constructor on it. Compared with a plain function, a class is always in strict mode, can't be used before its definition, and throws if you call it without new. Inside an instance, this.constructor points back to the class, which is how you reach static members, and in a subclass it points to the subclass."

Cheat sheet

typeof SomeClass === "function": a class is a function in a costume.
new creates an object, links it to Class.prototype and runs the constructor.
The costume adds three rules: strict mode, no use before definition, new required.
static members live on the class, not on its objects.
this.constructor is the class that ran new, so this.constructor.someStatic() respects subclasses.

Originally published on Bitlyst.

DEV Community: Mohsen Fallahnejad

XSS vs CSRF: Two Browser Attacks With Two Different Fixes

The mental model: inside the page, or only borrowing the browser

How it works

In practice

Say it in an interview

Cheat sheet

TL;DR

Going deeper

Three ways the script gets in

Why a GET can still be CSRF

Same site is not same origin

What a CSRF token has to be

Content-Security-Policy

Further reading

A Philosophy of Software Design Summary: Deep Modules Beat Small Ones

The book in one sentence

Idea 1: Complexity is anything that makes code hard to change

Idea 2: Be strategic, not tactical

Idea 3: Deep modules beat shallow ones

Idea 4: Hide information, and watch for leaks

Idea 5: Define errors out of existence

Where it's weak

Use it on Monday

Say it in an interview

Cheat sheet

Should you read it?

Going deeper

More ideas from the book, in one line each

What changed in the 2nd edition

The Clean Code conversation

Further reading

How V8 Makes JavaScript Fast: Ignition, Sparkplug, Maglev and TurboFan

The mental model: a translator who works harder on popular pages

How it works

The catch: optimized code is a bet

In practice

Say it in an interview

Cheat sheet

TL;DR

Going deeper

How the numbers were measured

How the tier-ups were traced

The thresholds aren't fixed call counts

On-stack replacement (OSR)

Tiers have changed over time

Further reading

React Server Components vs 'use client': What Actually Ships to the Browser

The mental model: the result vs the result plus the code

How it works

Data crossing the boundary

Server Components can sit inside Client Components

In practice

Say it in an interview

Cheat sheet

TL;DR

Going deeper

What the browser actually receives

"use server" isn't the opposite of "use client"

Context providers need a client wrapper

Third-party components without the directive

Environment variables

What wasn't measured

Further reading

Why React Needs key: The Bug That Moves Your Input to the Wrong Row

The mental model: name tags, not seat numbers

How it works

In practice

Bonus: a key change resets state on purpose

Say it in an interview

Cheat sheet

TL;DR

Going deeper

Why React doesn't just compare everything

Index keys also cost speed

Keys only matter among siblings

Fragments can take a key

key is not a prop

Generating IDs

Further reading

`"use server"` isn't the opposite of `"use client"`

`key` is not a prop

`fill()` depends on your Node version

`"use cache"`: store the result

`cacheLife`: when it goes stale

`cacheTag`: throw it out on demand

The three numbers behind `cacheLife`

`revalidateTag` vs `updateTag`

Is `this` part of scope?