DEV Community: Mohammed Abdelhady

OpenAI Jalapeño puts NVIDIA's inference margins on the clock

Mohammed Abdelhady — Sun, 30 Aug 2026 12:17:22 +0000

Does Jalapeño beat NVIDIA?

On the benchmark OpenAI published, yes.

Does that make it a better chip than NVIDIA's Blackwell platform?

The evidence does not support that claim yet.

Should NVIDIA care?

Yes. Jalapeño gives OpenAI a credible way to move repeated, high-volume inference onto hardware it controls. That changes how OpenAI buys GPUs, how much pricing power NVIDIA keeps, and how expensive it is to leave CUDA.

That is a narrower claim than "NVIDIA killer." It is also more interesting.

Short version: Jalapeño is an inference ASIC co-developed by OpenAI and Broadcom. Early results show excellent latency and performance per watt on three large models. It has not yet proved production-scale economics, long-context agent performance, or fleet reliability. Near term, it gives OpenAI capacity and negotiating power. Over time, it could take a profitable slice of inference away from merchant GPUs and weaken one part of NVIDIA's software moat.

This is infrastructure analysis, not a stock call.

What exactly is Jalapeño?

OpenAI calls Jalapeño its first "Intelligence Processor." The plainer description is a custom ASIC for large-language-model inference, built with Broadcom and turned into boards, racks, and production systems with Celestica.

This is intended to become more than a lab project. OpenAI and Broadcom announced a 10-gigawatt custom-accelerator program in October 2025, with racks targeted to start deploying in the second half of 2026 and the program running through 2029. Those gigawatts are a roadmap, not deployed capacity. The original collaboration announcement states the schedule.

Inference is the part that happens after training. A model has already learned its weights. The system now has to process a prompt, generate tokens, maintain the conversation state, route requests, and repeat that work for millions of users and agents.

NVIDIA GPUs can train models and serve them. Jalapeño has a smaller job description. It is designed around serving current and future LLMs, with special attention to memory movement, network delays, and the changing mix of prompt processing and token generation. OpenAI says the first engineering samples are running at target frequency and power, and that initial deployment is planned by the end of 2026. OpenAI's launch announcement has the full scope.

That narrower job lets a purpose-built chip skip features required by a merchant platform. It can spend more of its transistor, memory, and power budget on the workload its owner runs every day.

Why inference hardware keeps waiting

An LLM request has two broad phases.

During prefill, the system reads the prompt and builds the initial state. This phase leans heavily on compute.

During decode, the model emits tokens one at a time. Decode often waits on memory bandwidth because the system repeatedly reads weights and the key-value cache, or KV cache, that holds attention state from earlier tokens.

The arithmetic units can be fast and still sit idle. Data may have to cross a cache hierarchy, move between chips, or travel from a prefill worker to a separate decode worker. Every move costs energy. Some moves also add directly to the delay a user feels.

Jalapeño attacks that waiting time in several ways:

Its cores and HBM are organized into local slices. Software can place weights and KV state close to the compute that needs them.
A dedicated collective network handles known high-bandwidth communication between slices.
The design supports smaller matrix shapes, which helps avoid the padding and utilization cliffs that can appear on large systolic arrays.
OpenAI uses one flexible accelerator pool instead of permanently splitting hardware into separate prefill and decode fleets.

That last choice is easy to underestimate. Separate prefill and decode pools can look efficient when traffic matches the ratio used during planning. Production traffic moves. Prompt length, output length, cache-hit rate, concurrency, and speculative-decoding acceptance all change through the day. A fixed split can leave one pool idle while the other queues.

OpenAI accepts some local inefficiency to keep every device available for the next request. It also avoids shipping a growing KV cache across the network between phases. SemiAnalysis' architectural analysis describes a reticle-sized compute die, HBM4 with 15.4 TB/s of bandwidth, and a system that can connect 2,048 accelerators across 16 racks.

This is hardware and workload co-design in the literal sense. The team started with the traffic pattern, then built the chip and serving system around it.

What did the benchmark show?

OpenAI tested Jalapeño on SemiAnalysis' public InferenceX benchmark using three open models:

GPT-OSS 120B
DeepSeek R1 670B
Kimi K2.5 1T

Across those models, OpenAI reports 1.5 to 1.9 times more AI work per watt at peak throughput and 1.7 to 3.6 times lower end-to-end latency than the comparison systems. The chip is rated at 700 watts, while measured sustained power stayed at or below 550 watts during the tested workloads. On Kimi K2.5, OpenAI reports about 1.5 times higher peak performance per watt and 3.4 times lower end-to-end latency. The results and appendix are public.

The curve is more informative than the peak number. Jalapeño remained strong at lower concurrency, where each user expects tokens quickly. Coding agents care about that region because delays compound across sequential model calls.

The chart stops before production evidence begins.

SemiAnalysis observed the runs in OpenAI's lab, but OpenAI supplied the numbers. SemiAnalysis did not run the complete InferenceX suite and has not published AgentX results for Jalapeño. The current tests use an 8,000-token input and 1,000-token output workload. That is easier to tune than a long, multi-turn agent session with shared prefixes, cache reuse, pauses, routers, and parallel subagents.

AgentX was built for that messier traffic. Until Jalapeño runs it, the published chart says less about a full Codex session than the headline suggests.

There is also a timing mismatch. The benchmark compares engineering silicon against commercially available systems such as Blackwell. SemiAnalysis argues that HBM4-based Jalapeño is better compared with Vera Rubin, which is entering production earlier than Jalapeño's expected volume ramp. A0 silicon produced the current Jalapeño data. Production cost, yield, uptime, repair behavior, and sustained fleet performance remain unknown.

So yes, the result is technically credible. It is not a final verdict on NVIDIA hardware.

The AI-designed-chip story is more important than the branding

OpenAI says its models helped the team move from design to tapeout in nine months. AI explored implementations, shortened verification loops, and optimized arithmetic circuits. The team then used Codex with an internal model to bring three unplanned open-weight models to high performance in two months.

A selected-block result hints at why bring-up moved quickly. On GPT-OSS attention and mixture-of-experts blocks, OpenAI says AI-generated implementations ran 1.5 to 1.8 times faster than existing code written by human experts. OpenAI is explicit that this result covers selected blocks, not the complete model.

That limit does not make the result trivial. CUDA's advantage includes mature libraries, tooling, kernels, profilers, and a huge developer base. A new accelerator normally pays a large software tax before its theoretical hardware performance becomes useful. OpenAI's early bring-up suggests that models can reduce part of that tax by writing and tuning kernels against a predictable architecture.

The chip matters. The nine-month loop matters more.

If OpenAI can repeat that loop, each stable and expensive workload becomes a candidate for first-party silicon sooner than NVIDIA would like.

Four ways Jalapeño can hurt NVIDIA

1. OpenAI gains pricing power immediately

Jalapeño does not need to replace a single NVIDIA rack to affect a negotiation. Working silicon gives OpenAI an alternative for the next block of inference capacity. NVIDIA must now compete against the cost OpenAI expects from its own hardware as well as AMD, Google, Amazon, and GPU clouds.

OpenAI describes Jalapeño as a "credible first-party path" that lets it direct demand toward the best performance per dollar and maintain pricing discipline across suppliers. That language appears in OpenAI CFO Sarah Friar's infrastructure strategy.

2. The highest-volume inference can move off merchant GPUs

Custom silicon works best when the owner understands the workload and can keep the hardware busy. OpenAI has both conditions. It sees the real distribution of prompts, models, cache hits, latency targets, and product demand. It can tune the full system without waiting for a merchant roadmap.

My expectation is a split rather than a clean migration. OpenAI can place stable, repeated, power-sensitive inference on Jalapeño while keeping frontier training, post-training, new model bring-up, overflow capacity, and workloads that need broader software support on NVIDIA and other platforms.

GPU revenue can keep growing while NVIDIA receives a smaller share of the tokens OpenAI serves. Those two outcomes can coexist because total AI demand is still expanding.

3. NVIDIA's margin is exposed before its revenue is

NVIDIA reported $96.2 billion in second-quarter fiscal 2027 revenue, including $89.0 billion from data center, with a 75 percent gross margin. It also disclosed meaningful customer concentration. One direct customer represented 16 percent of quarterly revenue, while three direct customers represented 16, 15, and 13 percent of first-half revenue. NVIDIA did not identify those customers in the filing. The figures are in NVIDIA's latest 10-Q.

That margin leaves room for a customer-owned chip to create savings even after Broadcom, HBM, packaging, networking, and system costs. Jalapeño can pressure NVIDIA's price before it displaces large unit volumes.

NVIDIA has already written this risk into its own filings. Its first-quarter 10-Q says some customers are developing ASICs optimized for workloads that may not need all the features in NVIDIA data-center systems. The filing says this competition can reduce demand, selling prices, and gross margin. Read NVIDIA's wording directly.

4. AI can reduce the CUDA switching cost

CUDA is not one thing. It is the programming model, libraries, compilers, optimized kernels, debugging tools, deployment knowledge, and years of production fixes around them.

Jalapeño does not reproduce that ecosystem. It takes another route. OpenAI designed a predictable programming target and gives its models traces, simulators, placement controls, and a narrow set of workloads. The system can search for a fast mapping without making a human engineer hand-tune every layer.

If that method generalizes, the moat changes shape. NVIDIA still owns the widest platform, but a frontier lab may need fewer human-years to make its own accelerator useful. That is a software risk created by better software, not by a transistor count.

Why NVIDIA is not cornered

Jalapeño is first-party hardware. OpenAI has no announced plan to sell it as a merchant accelerator or make it available in every cloud. NVIDIA can sell one platform to frontier labs, enterprises, startups, governments, and cloud providers. That distribution is difficult to copy.

NVIDIA also spans training, post-training, inference, networking, rack systems, deployment software, and support. Jensen Huang used that breadth in his response to an analyst who asked about Jalapeño during NVIDIA's August 26 earnings call. His argument was simple: custom XPUs may serve one cloud or service, while NVIDIA runs across the full AI lifecycle and in every major cloud. The corrected transcript is available from NVIDIA.

OpenAI is still buying that breadth. Its public agreement with NVIDIA targets at least 10 gigawatts of NVIDIA systems, with the first gigawatt on Vera Rubin. The agreement was announced as a letter of intent, so it should not be treated as fully deployed capacity. It still shows that OpenAI's own-chip strategy and its NVIDIA relationship can expand at the same time. OpenAI published the partnership terms.

OpenAI has now put a public 10-gigawatt target beside both NVIDIA systems and Broadcom custom accelerators. The contracts and schedules differ, and neither figure equals production capacity today. Together they describe diversification under extreme demand, not a one-for-one hardware swap.

The near-term bottleneck may be supply rather than vendor share. If OpenAI needs more inference than every supplier can deliver, Jalapeño adds capacity instead of subtracting NVIDIA demand.

My risk map for NVIDIA

Risk	Timing	My read
Lower pricing power with OpenAI	Now	High. Working silicon changes procurement conversations before volume deployment.
Loss of OpenAI inference share	2027 onward	Medium. Production volume and reliability still have to arrive.
Gross-margin pressure across frontier labs	2027 onward	Medium. One successful program makes custom ASICs easier to justify elsewhere.
CUDA switching cost falls	Multi-generation	Medium. AI-assisted kernels are promising, but the evidence covers selected workloads.
NVIDIA platform becomes irrelevant	No credible timeline	Low. Jalapeño is internal, inference-focused, and not a replacement for NVIDIA's market reach.

The plausible downside is a narrower role for NVIDIA.

NVIDIA could become the broad training and deployment platform, the fastest place to start, and the capacity provider for new or irregular workloads. Large model owners could move mature, predictable inference onto their own chips once the economics justify it. NVIDIA would still sell a great deal of compute, but it would collect less margin from the most repeated workload in AI.

Five numbers worth watching next

Ignore the next "killer chip" headline unless it includes these:

AgentX performance. Long-context, multi-turn, cache-heavy traffic will test the serving stack along with the matrix engines.
Production cost per million tokens. Include chips, hosts, networking, cooling, yield, depreciation, and idle capacity.
B0 yield and measured power. A better stepping on paper only matters if it ships in volume.
Fleet uptime and repair rate. A fast engineering sample is different from a service that runs every minute of the year.
Deployed megawatts serving customer traffic. Announced gigawatts are plans. Production tokens are evidence.

Jalapeño does not need to defeat CUDA everywhere. It needs to serve a rising share of OpenAI's tokens, force tougher pricing on the GPUs OpenAI still buys, and show other model labs that custom silicon can reach useful performance faster than it used to.

"NVIDIA killer" is clickbait. A major NVIDIA partner now has working first-party inference silicon.

Sources and further reading

React Fiber without the folklore, Part 2: Lanes, Hooks, and commit

Mohammed Abdelhady — Fri, 10 Apr 2026 06:50:22 +0000

Question: Two state updates happen in the same component. Why can React treat one as urgent and let the other wait?

Answer: The Fiber does not store a single "priority." It carries lane bitmasks that let React track several classes of pending work at once.

That answer opens three more questions. Where is Hook state stored? How does completed render work reach the DOM? Why can React prepare a tree without exposing half of it to the screen?

The answers meet inside one Fiber: memoizedState, lanes, flags, and alternate.

This walkthrough uses React 19.2.7 source names. These are implementation details, not public API contracts. The point is to build a debugging model that matches current code, then keep the model loose enough to survive a refactor.

First, kill the single-priority picture

Suppose a search screen updates its input immediately but marks an expensive result calculation as a transition:

import { useState, useTransition } from 'react';

export function SearchBox({ search }) {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  const [isPending, startTransition] = useTransition();

  function handleChange(event) {
    const nextQuery = event.target.value;

    setQuery(nextQuery);

    startTransition(() => {
      setResults(search(nextQuery));
    });
  }

  return (
    <>
      <input value={query} onChange={handleChange} />
      {isPending && <span>Updating results...</span>}
      <ResultList items={results} />
    </>
  );
}

The two updates are real at the same time, but they do not need the same scheduling treatment. React represents pending work with lanes, which are bits inside an integer mask.

A teaching version might look like this:

const SYNC = 0b0001;
const INPUT = 0b0010;
const DEFAULT = 0b0100;
const TRANSITION = 0b1000;

let pending = DEFAULT | TRANSITION;

const hasTransition = (pending & TRANSITION) !== 0;
const withoutDefault = pending & ~DEFAULT;

Bitmasks make common scheduler questions cheap:

Add work: pending | lane
Test overlap: (pending & lanes) !== 0
Remove completed work: pending & ~finished
Pick the least significant set bit: lanes & -lanes

React 19.2.7 defines 31 lanes. The file includes sync, input-continuous, default, transition, retry, idle, offscreen, and deferred groups in ReactFiberLane.js.

Do not memorize the binary constants. They can change. Remember the capability: one Fiber and one root can record multiple pending categories, combine them, and select a subset for a render.

Lanes do not mean "run every high bit first"

The scheduler has to consider more than a static ranking. Work can be suspended, pinged when data arrives, expired after waiting, or entangled with related work that must render together.

Even the phrase "higher bit means higher priority" is backwards for the current layout. React's helper for the highest-priority lane takes the least significant set bit:

export function getHighestPriorityLane(lanes) {
  return lanes & -lanes;
}

That implementation appears in ReactFiberLane.js.

The safe public conclusion is not "lane 2 always beats lane 64." It is this: React can preserve urgent interaction while lower-priority rendering remains pending, and APIs such as transitions let application code express that distinction.

Hooks are a positional linked list

Here is the smallest surprising fact in React internals:

A function component's Hook state is not looked up by variable name.

Hooks form a linked list rooted at the Fiber's memoizedState.

const firstHook = {
  memoizedState: 'dark',
  queue: themeUpdates,
  next: secondHook,
};

const secondHook = {
  memoizedState: false,
  queue: menuUpdates,
  next: null,
};

fiber.memoizedState = firstHook;

During mount, React appends each Hook record to that list. During an update, it walks the old and work-in-progress lists in order. You can see both operations in ReactFiberHooks.js.

Now the Rules of Hooks stop sounding ceremonial.

function Panel({ canEdit }) {
  const [open, setOpen] = useState(false); // Hook 1

  if (canEdit) {
    const [draft, setDraft] = useState(''); // Sometimes Hook 2
  }

  const [theme, setTheme] = useState('dark'); // Hook 2 or Hook 3?
}

On one render, theme might consume the second Hook record. On another, draft consumes it first. Names cannot rescue the mismatch because React is advancing linked-list cursors.

This is why Hooks must be called in the same order on every render. Put the condition inside an effect, event handler, or custom Hook. Do not put it around the Hook call.

Queued updates can survive a skipped render

Each state Hook has more than its visible value. It also carries a queue and base state used while React processes updates for the lanes selected in this render.

Imagine two queued updates:

setCount((count) => count + 1);       // urgent lane
startTransition(() => setFilter('x')); // transition lane

If the current render only includes urgent work, React must not lose the transition update. The lower-priority update stays represented for a later pass. The exact queue mechanics are intricate, but the user-visible behavior follows from this requirement: skipping work is not the same as deleting it.

This also explains why reading state immediately after calling its setter still returns the state from the current render. You enqueued work. You did not mutate the closed-over snapshot.

The alternate is a transaction boundary

Part 1 introduced fiber.alternate: the paired current and work-in-progress versions of a Fiber.

During an update, React writes the candidate result into the work-in-progress tree. The currently committed tree remains available. React's source describes this as a double-buffering pool and reuses the alternate after creating it lazily in createWorkInProgress.

Think of it as a transaction boundary, with one caution: it is not a general database transaction and the two trees do not deep-copy every object.

The useful guarantees are narrower:

Render work can be prepared away from the visible host tree.
An unfinished render does not have to become the screen.
A completed result can be committed as one coordinated change.

This is why mutating external systems during render is dangerous. React may call, pause, restart, or abandon render work. A render should calculate JSX from inputs. Side effects belong in event handlers or effects.

Flags are the receipt from render

What does the completed tree need to tell commit?

It needs a compact record of work such as placement, updates, deletion, refs, layout effects, and passive effects. Fibers carry flags for their own work and subtreeFlags summarizing relevant work below them.

A simplified bubble looks like this:

function bubbleFlags(fiber) {
  let subtreeFlags = 0;
  let child = fiber.child;

  while (child) {
    subtreeFlags |= child.flags;
    subtreeFlags |= child.subtreeFlags;
    child = child.sibling;
  }

  fiber.subtreeFlags |= subtreeFlags;
}

The summary lets commit skip clean subtrees instead of inspecting every descendant for every kind of effect.

Older explanations often call this an "effect list." Current React still has Hook effect lists, but DOM commit traversal is better understood through Fiber flags and subtree flags. The vocabulary matters because an old diagram can remain visually convincing after the implementation it describes has moved on.

Commit is several ordered passes

React's public docs say commit is where calculated changes reach the DOM. Internally, "commit" is not one undifferentiated loop.

A practical sequence is:

Before mutation: read information that must be captured before host changes.
Mutation: insert, update, and remove host nodes; detach affected refs.
Layout: attach refs and run layout effects and relevant class lifecycles against the updated host tree.
Passive effects: schedule and later flush passive cleanup and setup such as useEffect.

The work loop explicitly labels the mutation phase as the place where React mutates the host tree, then calls layout effects afterward. See ReactFiberWorkLoop.js.

This ordering answers a common ref question. During render, React has not committed the next DOM. During commit, refs are cleared before affected DOM mutation and set again after the DOM update. React documents that timing in Manipulating the DOM with Refs.

It also separates useLayoutEffect from useEffect:

useLayoutEffect runs in the layout part of commit and can read the updated layout before the browser paints, but heavy work there delays paint.
useEffect is passive. It normally runs after the committed screen is available, with timing details that React may optimize around interactions.

Use layout effects for measurements that must block paint. Use passive effects for synchronization that does not.

Trace one update end to end

Take the search example from the opening.

The input event queues an urgent query update.
The transition queues result work in transition lanes.
The root records both categories as pending.
React selects lanes for a render.
beginWork processes Fibers whose own lanes or descendant lanes overlap the selected work.
Function components walk their Hook lists and process eligible queued updates.
Completion bubbles flags and remaining child lanes.
If the render finishes and is accepted, commit applies the flagged host work in ordered phases.
Work in lanes not included in that render remains pending.

That is the relationship among the pieces. Lanes answer "which work now?" Hook queues answer "which state transitions belong to that work?" Alternates answer "where can we prepare it?" Flags answer "what must commit do?"

The model I keep beside the profiler

When an update behaves oddly, I do not start with "React re-rendered everything." I ask:

Which Fiber kept or lost identity?
Which lanes were pending, selected, suspended, or left behind?
Which Hook position and queue produced this state?
Which flags survived into commit?
Did the suspicious code run in render, mutation, layout, or a passive effect?

Those questions are specific enough to guide a profile, but they do not pretend internal constants are permanent.

Fiber is not one trick. It is the meeting point between identity, resumable traversal, update queues, scheduling, and host mutation. The architecture becomes useful when you stop treating those words as separate chapters and trace one update through all of them.

React Fiber without the folklore, Part 1: The tree and the work loop

Mohammed Abdelhady — Wed, 08 Apr 2026 11:51:15 +0000

Question: If React already has a component tree, why does it need Fiber?

Short answer: A component tree describes what is nested inside what. A Fiber tree also records where React paused, what still needs work, and how to continue without rebuilding the call stack.

That distinction sounds small until a render is interrupted.

A normal recursive tree walk borrows the JavaScript stack. Once it enters a deep child, the browser cannot ask it to hand control back halfway through. Fiber moves the traversal state into heap objects. React can process one object, choose the next one, and yield between units of work when the renderer and scheduler allow it.

This article follows the actual shape used by React 19.2.7. It is not a substitute for the source. It is a map for reading the source without getting lost.

Start with the links, not the jargon

A simplified Fiber node looks like this:

const fiber = {
  type: ProfileCard,
  key: null,
  pendingProps: { userId: 42 },

  return: parentFiber,
  child: firstChildFiber,
  sibling: nextSiblingFiber,

  memoizedProps: previousProps,
  memoizedState: firstHook,
  updateQueue: pendingUpdates,

  flags: 0,
  subtreeFlags: 0,
  lanes: 0,
  childLanes: 0,

  alternate: otherVersionOfThisFiber,
};

The real constructor contains these fields and more in ReactFiber.js.

Three pointers turn the component hierarchy into a structure React can walk iteratively:

child points to the first child.
sibling points to the next child of the same parent.
return points back to the parent.

Why call the parent link return? Because when a unit has no more child work, that is where control returns. The name describes the traversal, not the JSX relationship.

Consider this component:

function App() {
  return (
    <main>
      <Header />
      <Profile />
    </main>
  );
}

Its relevant Fiber links are closer to this:

App
 |
 child
 v
main -> Header -> Profile
        sibling  sibling

Header.return  = main
Profile.return = main
main.return    = App

Header and Profile are visually siblings in JSX. In memory, only the first child hangs directly from main; later children form a sibling chain.

Try the walk yourself

Here is a deliberately small depth-first walker. It does not render anything, but its control flow mirrors the useful part of Fiber traversal.

function beginWork(node) {
  console.log('begin', node.name);
  return node.child;
}

function completeWork(node) {
  console.log('complete', node.name);
}

function performUnitOfWork(node) {
  const child = beginWork(node);

  if (child) return child;

  let cursor = node;

  while (cursor) {
    completeWork(cursor);

    if (cursor.sibling) return cursor.sibling;
    cursor = cursor.return;
  }

  return null;
}

let nextUnit = root;

while (nextUnit) {
  nextUnit = performUnitOfWork(nextUnit);
}

The order is the point:

Begin the current node.
Descend into its first child if one exists.
If there is no child, complete the node.
Move sideways to a sibling.
If there is no sibling, climb through return and complete ancestors until a sibling appears.

React's production code has branches for component types, Suspense, hydration, errors, profiling, and more. The spine is still recognizable. In React 19.2.7, performUnitOfWork calls beginWork. When no child is returned, it enters completion.

The call stack no longer owns the whole journey. The workInProgress pointer does.

What happens in begin and complete?

It is tempting to translate beginWork as "render this component" and completeWork as "put it on screen." The second half is wrong.

beginWork asks what this Fiber's children should be for the current render. For a function component, that includes calling the component through the Hooks machinery and reconciling the returned children. For a host component such as div, it reconciles the children prop.

The official source shows child reconciliation assigning workInProgress.child from either the mount or update path in ReactFiberBeginWork.js.

completeWork runs while the traversal climbs back up. Among other renderer-specific jobs, completion can prepare host instances and bubble information from descendants into their parent. It does not mean the browser DOM has already changed.

That matters because React's public mental model has three stages:

Trigger a render.
Render components and calculate the next UI.
Commit the required changes.

React documents that separation in Render and Commit. The render phase may be restarted or abandoned. Visible mutation belongs to commit.

Where interruption becomes possible

Replace the final while loop in our toy walker with a deadline:

function workLoop(deadline) {
  while (nextUnit && performance.now() < deadline) {
    nextUnit = performUnitOfWork(nextUnit);
  }

  if (nextUnit) {
    scheduleAnotherSlice(workLoop);
  }
}

This is explanatory code, not React's scheduler. The useful idea is that nextUnit survives outside the JavaScript stack. A later callback can resume from the saved Fiber.

Current React has more than one work-loop path. One loop asks the Scheduler whether it should yield; another uses a time boundary. The exact policy can change. The stable concept is narrower: work is divided into resumable units, and concurrent rendering can yield between them.

This is also why "Fiber makes React asynchronous" is a poor explanation. A synchronous render still uses Fibers. Fiber is the work representation. Scheduling policy decides whether a particular render yields.

Reconciliation is an identity problem

Now ask a harder question:

When React sees new JSX, how does it know whether a Fiber represents the same thing as before?

The practical answer is type, position, and key.

function Results({ sorted }) {
  const items = sorted ? sortByScore(data) : data;

  return items.map((item) => (
    <ResultRow key={item.id} item={item} />
  ));
}

The key is not decoration and it is not passed to ResultRow as a normal prop. It helps React match an old child Fiber with a new element among siblings.

If an item's position changes but its stable key remains, React can preserve the component's identity and state. If the key changes, React is allowed to treat it as a different component and remount it.

Index keys are therefore not universally forbidden. They are a claim: "the identity of each item is its current position." That claim is safe for a fixed, append-only list. It breaks when items reorder, disappear, or arrive in the middle.

The bug often looks supernatural because the DOM text is correct while local state appears to jump rows. The Fiber identity followed the index exactly as requested.

Why React keeps two versions

Each Fiber has an alternate field. During an update, React can keep the currently committed node and a work-in-progress version of that node.

React's own comment calls this a double-buffering pool. The alternate is created lazily, then reused. See createWorkInProgress.

That design gives React somewhere to write the next result without corrupting the tree currently associated with the screen. If a render cannot finish, the committed version still exists. When commit succeeds, the finished work becomes current.

Do not picture two permanent, independent application trees with every object duplicated forever. Alternates are paired and reused, and many fields may point to shared data until a render path needs to clone or replace it.

A debugging model that holds up

When a React bug feels random, I use four questions:

Identity: Did type, position, or key make this a new Fiber?
Phase: Did this code run while calculating or while committing?
Traversal: Is React descending into child work, completing ancestors, or bailing out?
Priority: Is this update in the work React chose to process now?

The first three now have a concrete shape. The fourth needs lanes, effects, and Hooks, which belong in Part 2.

Fiber is not "the virtual DOM object." It is React's mutable work record for one potential piece of UI. Once you see the links and the cursor, the name stops feeling mystical. It is a stack frame React can keep, revisit, clone, and schedule.

Next question: If the render phase only calculates, how do lanes decide what gets calculated first, and how do flags carry the answer into commit?

A Node.js file watcher that survives real editors and noisy events

Mohammed Abdelhady — Sat, 04 Apr 2026 08:23:35 +0000

Question: Why did one save in my editor produce rename, change, another rename, and sometimes no filename at all?

Answer: Because fs.watch() reports an operating-system event stream. It does not report your editor's concept of "the user saved one file."

Many editors save safely by writing a temporary file, syncing it, and replacing the original. From the file system's point of view, that can be several real operations. Linux, macOS, and Windows surface them through different mechanisms. Node normalizes part of the interface, not the meaning of every event.

A useful watcher therefore does not restart a process for every callback. It collects hints, filters noise, waits for a short quiet window, checks final state, and moves one restart controller toward the newest generation.

We will build that pipeline with current Node APIs.

The callback is a hint

The familiar API looks harmless:

import { watch } from 'node:fs';

watch('src', { recursive: true }, (eventType, filename) => {
  console.log(eventType, filename);
});

The callback only promises two event types: rename and change. On most platforms, rename is also used when a filename appears or disappears. The filename can be null, even on platforms that usually provide it.

Node's own watch caveats are worth reading before writing retry logic:

The API is not fully consistent across platforms.
Network and virtualized file systems can be unreliable.
On Linux and macOS, a deleted and recreated file may receive a new inode while the watcher stays attached to the old one.
Windows has distinct behavior when the watched directory is moved or deleted.

So do not translate eventType === 'rename' into "a human renamed this file." Treat it as "directory membership or identity may have changed."

Prefer the async iterator for a controlled lifecycle

node:fs/promises exposes watch() as an async iterator. Current Node 24 also gives it an AbortSignal, recursive watching on supported platforms, ignore patterns, and a bounded event queue.

import { watch } from 'node:fs/promises';

export async function readWatchEvents(root, signal, onEvent) {
  const events = watch(root, {
    recursive: true,
    signal,
    overflow: 'throw',
    ignore: [
      '**/.git/**',
      '**/node_modules/**',
      '**/dist/**',
      '**/*.log',
    ],
  });

  for await (const event of events) {
    onEvent(event);
  }
}

Why choose overflow: 'throw'? The async iterator's queue defaults to 2048 entries. Its default overflow policy warns and drops events. A development reloader can usually recover by forcing a full rebuild, but silently trusting an incomplete event sequence is a bad default. Throwing lets the outer controller log the loss and restart the watcher from known state.

These options are documented in fsPromises.watch(). If your tool supports older Node releases, feature-test or define a minimum version. Do not copy current options into a package that claims compatibility with runtimes that predate them.

Filter twice

Ignoring node_modules, .git, build output, and logs at the watcher boundary reduces load. You still need an application filter because "not ignored" is broader than "should restart my server."

import path from 'node:path';

const RESTART_EXTENSIONS = new Set([
  '.cjs',
  '.js',
  '.json',
  '.mjs',
  '.ts',
  '.tsx',
]);

function shouldRestart(relativeName) {
  if (relativeName === null) return true;

  const extension = path.extname(String(relativeName));
  return RESTART_EXTENSIONS.has(extension);
}

Returning true for a null filename is conservative. We know something changed inside the watched scope but cannot identify it. Missing one source edit is worse than one extra restart.

For a large monorepo, that policy may be too expensive. A null filename can instead schedule a scoped rescan that compares modification metadata or a content manifest. The important part is to choose a fallback. filename.toString() without a null branch is not one.

Debounce is not quite the right word

Suppose the watcher sees this burst:

rename  src/.server.js.tmp
change  src/.server.js.tmp
rename  src/server.js
change  src/server.js

We are not merely delaying the last callback. We want to merge several hints into one decision while preserving which paths may have changed. That is coalescing.

export function createCoalescer({ settleMs, flush }) {
  const changedPaths = new Set();
  const eventTypes = new Set();
  let lostFilename = false;
  let timer = null;

  function push({ eventType, filename }) {
    eventTypes.add(eventType);

    if (filename === null) {
      lostFilename = true;
    } else {
      changedPaths.add(String(filename));
    }

    clearTimeout(timer);
    timer = setTimeout(() => {
      timer = null;

      const batch = {
        changedPaths: [...changedPaths],
        eventTypes: [...eventTypes],
        lostFilename,
      };

      changedPaths.clear();
      eventTypes.clear();
      lostFilename = false;
      flush(batch);
    }, settleMs);
  }

  function close() {
    clearTimeout(timer);
    timer = null;
  }

  return { push, close };
}

The quiet window is a product decision, not a law. Around 50 to 150 ms often feels immediate for local development, but storage, transpilation, and editor behavior differ. Measure the event bursts on the systems you support.

A maximum wait is also useful under constant writes. Without one, a pure trailing-edge timer can postpone work forever. Production tooling usually flushes when either the stream goes quiet or a maximum batch age is reached.

One restart controller, many generations

The worst watcher bugs usually come after detection. A burst starts child B while child A is still exiting; another burst starts child C; an old exit handler clears the reference to the newest child.

Make restart order explicit.

import { spawn } from 'node:child_process';
import { once } from 'node:events';
import { setTimeout as delay } from 'node:timers/promises';

export class RestartController {
  #child = null;
  #closed = false;
  #requestedGeneration = 0;
  #appliedGeneration = 0;
  #drainPromise = null;

  constructor(command, args, options = {}) {
    this.command = command;
    this.args = args;
    this.options = options;
  }

  requestRestart(reason) {
    if (this.#closed) return;

    this.#requestedGeneration += 1;
    console.log(`[watch] restart requested: ${reason}`);

    this.#ensureDrain();
  }

  #ensureDrain() {
    if (this.#closed || this.#drainPromise) return;

    this.#drainPromise = this.#drain().finally(() => {
      this.#drainPromise = null;

      if (
        !this.#closed &&
        this.#appliedGeneration < this.#requestedGeneration
      ) {
        this.#ensureDrain();
      }
    });
  }

  async #drain() {
    while (
      !this.#closed &&
      this.#appliedGeneration < this.#requestedGeneration
    ) {
      const generation = this.#requestedGeneration;
      await this.#stopChild();

      if (this.#closed) return;

      this.#child = spawn(this.command, this.args, {
        stdio: 'inherit',
        ...this.options,
      });

      this.#appliedGeneration = generation;
    }
  }

  async #stopChild() {
    const child = this.#child;
    if (!child) return;

    this.#child = null;

    if (child.exitCode !== null || child.signalCode !== null) return;

    child.kill('SIGTERM');

    const exited = once(child, 'exit').then(() => true);
    const timedOut = delay(2000, false);

    if (!(await Promise.race([exited, timedOut]))) {
      child.kill('SIGKILL');
      await once(child, 'exit');
    }
  }

  async close() {
    this.#closed = true;
    await this.#drainPromise;
    await this.#stopChild();
  }
}

The generation counter turns a noisy stream into "eventually run the newest requested generation." It does not start one process per event. At most one drain loop owns child replacement.

Clearing this.#child before waiting also matters. An exit event from the old process can no longer overwrite a newer child reference.

For a process tree, signals are platform-specific. SIGTERM and SIGKILL do not form a complete cross-platform process-group strategy. A reusable tool should put termination behind an adapter and test it on Windows as well as POSIX systems.

Wire the pipeline

Now connect detection, filtering, coalescing, and restart control:

import { watch } from 'node:fs/promises';

export async function runDevWatcher({ root, entry }) {
  const abortController = new AbortController();
  const runner = new RestartController(
    process.execPath,
    [entry],
    { cwd: root },
  );

  const coalescer = createCoalescer({
    settleMs: 90,
    flush(batch) {
      const paths = batch.lostFilename
        ? 'unknown path'
        : batch.changedPaths.join(', ');

      runner.requestRestart(paths);
    },
  });

  const stop = async () => {
    abortController.abort();
    coalescer.close();
    await runner.close();
  };

  process.once('SIGINT', stop);
  process.once('SIGTERM', stop);

  runner.requestRestart('initial start');

  try {
    for await (const event of watch(root, {
      recursive: true,
      signal: abortController.signal,
      overflow: 'throw',
      ignore: ['**/.git/**', '**/node_modules/**', '**/dist/**'],
    })) {
      if (shouldRestart(event.filename)) {
        coalescer.push(event);
      }
    }
  } catch (error) {
    if (error.name !== 'AbortError') {
      await runner.close();
      throw error;
    }
  }
}

There is one deliberate gap: if the watch queue overflows, this function exits instead of pretending the stream is complete. A CLI wrapper can catch that failure, perform a full rebuild, and create a fresh watcher with backoff.

That recovery path should be visible in logs. "Watching" is a system state, and losing coverage is operationally important.

Test the ugly events

Happy-path tests that write one file once are not enough. Exercise the contracts that differ by platform and editor:

A burst of four hints produces one restart.
Two paths in one burst are both preserved.
A null filename triggers the conservative fallback.
A change during process shutdown produces one later generation, not overlapping children.
Abort stops the watcher and the child.
Queue overflow becomes a visible recovery event.
Temporary files and build output are ignored.
Delete and recreate of the watched target is detected or recovered by a parent-directory watch.

Run integration tests on each operating system you claim to support. Mocking fs.watch is useful for state-machine tests, but a mock cannot tell you what FSEvents or inotify actually emits.

The key design choice is simple: an OS event is evidence that state may have changed, not a command to restart immediately. Once the watcher treats events as hints, the rest of the architecture becomes calmer: batch the evidence, inspect final state, and let one controller own the transition.

EventEmitter internals: Listener identity, once(), and safe dispatch

Mohammed Abdelhady — Sat, 04 Apr 2026 08:04:09 +0000

Question: If a once() listener is wrapped, how can off(event, originalFunction) still remove it?

Answer: The wrapper must keep the original function's identity somewhere. If your emitter hides that relationship, removal becomes guesswork.

That tiny problem exposes most of the hard parts in an event system: duplicate listeners, mutation during dispatch, synchronous ordering, one-shot cleanup, and what an error event means.

We will build a small emitter that makes those contracts explicit. Use Node's battle-tested EventEmitter in production unless you need different semantics. The point of this implementation is to understand the promises your code already depends on.

Before code, answer five questions

An event emitter is not just a map from names to callbacks. Pick the behavior first.

Are listeners called synchronously or queued?
Does registration order matter?
Can the same function be registered twice?
What happens if a listener is removed while an emit is in progress?
Is error an ordinary event or a failure channel?

Node's answers are precise:

emit() calls listeners synchronously in registration order.
Duplicate registrations are allowed and produce duplicate calls.
removeListener() removes at most one matching registration.
Removing a listener during an active emit does not cancel that listener from the already-started dispatch.
Emitting error without an error listener throws.

Those rules are documented in the Node 24.15 Events API. Our emitter will copy this useful core, without pretending to reproduce every Node feature.

A listener is a registration, not only a function

Start with a representation that can preserve identity:

class TinyEmitter {
  #events = new Map();

  on(eventName, listener) {
    this.#assertListener(listener);

    const registrations = this.#events.get(eventName) ?? [];
    registrations.push({ listener, original: listener, once: false });
    this.#events.set(eventName, registrations);

    return this;
  }

  #assertListener(listener) {
    if (typeof listener !== 'function') {
      throw new TypeError('listener must be a function');
    }
  }
}

Why store an object instead of the function directly? Because one function may appear in several independent registrations. Each registration can have its own once behavior while still pointing to the same original callback.

const emitter = new TinyEmitter();

function logSave(path) {
  console.log('saved', path);
}

emitter.on('save', logSave);
emitter.on('save', logSave);

This is not accidental deduplication waiting to happen. Node explicitly allows it. Calling emit('save') should call logSave twice. If duplicate registration is a bug in your application, prevent it at the application boundary instead of silently changing emitter semantics.

Synchronous emit creates a stack, not a queue

Add dispatch:

emit(eventName, ...args) {
  const registrations = this.#events.get(eventName);

  if (!registrations || registrations.length === 0) {
    if (eventName === 'error') {
      const error = args[0];
      throw error instanceof Error
        ? error
        : new Error(`Unhandled error event: ${String(error)}`);
    }

    return false;
  }

  const snapshot = registrations.slice();

  for (const registration of snapshot) {
    if (registration.once) {
      this.#removeRegistration(eventName, registration);
    }

    registration.listener.apply(this, args);
  }

  return true;
}

The call to apply is intentional. With a normal function listener, Node binds this to the emitter. Arrow functions keep lexical this, as usual.

The snapshot is more important. Consider this:

function first() {
  console.log('first');
  emitter.off('tick', second);
}

function second() {
  console.log('second');
}

emitter.on('tick', first);
emitter.on('tick', second);
emitter.emit('tick');

Node calls both listeners during that emit. The removal affects later emits. Iterating a snapshot gives us the same observable rule.

If we iterated the live array and spliced it inside first, second might slide into the current index and get skipped. That would make listener behavior depend on array mutation details instead of the contract.

Synchronous does not mean "fast" or "blocking forever." It means each listener runs on the caller's current stack before emit() returns. A listener can choose to defer its own work:

emitter.on('report', (payload) => {
  setImmediate(() => writeReport(payload));
});

The emitter still dispatched synchronously. The listener scheduled separate work.

Remove one registration from the end

Node removes at most one matching registration. When the same function appears more than once, current Node behavior removes the most recently added matching instance.

off(eventName, listener) {
  this.#assertListener(listener);

  const registrations = this.#events.get(eventName);
  if (!registrations) return this;

  for (let index = registrations.length - 1; index >= 0; index -= 1) {
    const registration = registrations[index];

    if (registration.original === listener) {
      registrations.splice(index, 1);
      break;
    }
  }

  if (registrations.length === 0) {
    this.#events.delete(eventName);
  }

  return this;
}

#removeRegistration(eventName, target) {
  const registrations = this.#events.get(eventName);
  if (!registrations) return;

  const index = registrations.indexOf(target);
  if (index !== -1) registrations.splice(index, 1);

  if (registrations.length === 0) {
    this.#events.delete(eventName);
  }
}

Identity comparison uses ===. Two arrow functions with identical source text are still different objects:

emitter.on('open', () => console.log('open'));
emitter.off('open', () => console.log('open')); // removes nothing

Keep the reference when you will need to unsubscribe:

const handleOpen = () => console.log('open');
emitter.on('open', handleOpen);
emitter.off('open', handleOpen);

This is the same reason a UI cleanup can fail when registration and removal each create a fresh closure.

`once()` must remove before calling

Our registration object makes once() simple:

once(eventName, listener) {
  this.#assertListener(listener);

  const registrations = this.#events.get(eventName) ?? [];
  registrations.push({ listener, original: listener, once: true });
  this.#events.set(eventName, registrations);

  return this;
}

Notice the dispatch order:

if (registration.once) {
  this.#removeRegistration(eventName, registration);
}

registration.listener.apply(this, args);

Removal happens before invocation. That protects against re-entrant emits:

emitter.once('ready', () => {
  console.log('ready');
  emitter.emit('ready');
});

emitter.emit('ready'); // logs once, not recursively forever

A common hand-built version removes the wrapper after calling the listener. The nested emit then sees the wrapper still installed and calls it again.

Node exposes this wrapper distinction through two inspection methods. listeners(event) returns original listeners, including originals registered with once(). rawListeners(event) includes wrappers. Our object representation makes the same split easy:

listeners(eventName) {
  return (this.#events.get(eventName) ?? [])
    .map(({ original }) => original);
}

rawListeners(eventName) {
  return (this.#events.get(eventName) ?? [])
    .map(({ listener }) => listener);
}

Our once() does not need a callable wrapper, so both arrays contain the same function. If you implement once() with wrappers, keep wrapper.listener = original or an equivalent registration field so off(event, original) can still work.

`error` is a policy decision

Node treats the string event name error specially. No listener means the emitted error is thrown and the process normally exits. That loud failure prevents an operational error from disappearing into an empty listener list.

const emitter = new TinyEmitter();
emitter.emit('error', new Error('connection lost'));

Our emit copies that core behavior. Whether your own event abstraction should do the same depends on its role. A browser UI event bus may be better with explicit result types. A Node service component may benefit from Node-compatible failure semantics.

Async listeners add another edge:

emitter.on('job', async () => {
  throw new Error('job failed');
});

emitter.emit('job');

Synchronous try/catch around listener.apply cannot catch a later Promise rejection. Node offers captureRejections to route rejected async listeners to its rejection hook or error channel. Our tiny emitter does not. Callers must catch inside the listener, or the emitter must detect thenables and define what happens to rejection.

Do not bolt that feature on without deciding whether rejection routing is synchronous, asynchronous, recursive, and observable through error.

Test contracts, not private arrays

These tests use Node's built-in test runner:

import assert from 'node:assert/strict';
import test from 'node:test';

test('keeps registration order and duplicates', () => {
  const emitter = new TinyEmitter();
  const calls = [];
  const repeated = () => calls.push('same');

  emitter.on('tick', () => calls.push('first'));
  emitter.on('tick', repeated);
  emitter.on('tick', repeated);
  emitter.emit('tick');

  assert.deepEqual(calls, ['first', 'same', 'same']);
});

test('removing during emit affects the next emit', () => {
  const emitter = new TinyEmitter();
  const calls = [];

  const second = () => calls.push('second');
  const first = () => {
    calls.push('first');
    emitter.off('tick', second);
  };

  emitter.on('tick', first);
  emitter.on('tick', second);
  emitter.emit('tick');
  emitter.emit('tick');

  assert.deepEqual(calls, ['first', 'second', 'first']);
});

test('once is safe under re-entrant emit', () => {
  const emitter = new TinyEmitter();
  let calls = 0;

  emitter.once('ready', () => {
    calls += 1;
    emitter.emit('ready');
  });

  emitter.emit('ready');
  assert.equal(calls, 1);
});

Run them with:

node --test emitter.test.js

The implementation is about 70 lines. The semantics are the actual product.

When reviewing an event system, I now ask one question first: what is a listener in this design? If the answer is only "a function in an array," once(), duplicate removal, and in-flight mutation are probably waiting to surprise you.

JavaScript arrays are not C arrays: Holes, elements kinds, and resize costs

Mohammed Abdelhady — Wed, 01 Apr 2026 21:36:51 +0000

Question: Is a JavaScript array a contiguous block of memory like a C array?

Answer: ECMAScript does not promise that. It defines an Array as an exotic object with special rules for index-like property names and length. An engine may use contiguous storage when that is profitable, then switch representations when your data becomes sparse or mixed.

The distinction matters. "Arrays are contiguous" is a useful first-week simplification and a bad foundation for performance advice.

This article separates three layers that are often blended together:

What JavaScript guarantees.
What V8 currently optimizes.
What your benchmark actually proves on one workload.

First experiment: a hole is not `undefined`

Run this in Node or a browser console:

const holey = ['a', , 'c'];
const explicit = ['a', undefined, 'c'];

console.log(holey.length);          // 3
console.log(holey[1]);              // undefined
console.log(1 in holey);            // false
console.log(holey.hasOwnProperty(1)); // false

console.log(explicit.length);       // 3
console.log(explicit[1]);           // undefined
console.log(1 in explicit);         // true
console.log(explicit.hasOwnProperty(1)); // true

Reading either position returns undefined, but the object shapes differ. The hole is an absent property. The explicit value is a present property whose value happens to be undefined.

That difference leaks into array methods:

const source = ['a', , 'c'];

console.log(source.map((value) => value));
// [ 'a', <1 empty item>, 'c' ]

console.log([...source]);
// [ 'a', undefined, 'c' ]

console.log(source.slice());
// [ 'a', <1 empty item>, 'c' ]

Spread consumes the array iterator, which reads a value for every index and materializes the default missing value as undefined. slice() preserves absence. V8 discusses this exact difference in Speeding up spread elements.

If an API cares about "missing" versus "present but empty," serializing, cloning, or iterating can change the information you thought you had.

What the language promises

ECMAScript calls arrays exotic objects. The exotic part is the relationship between array-index properties and length.

const values = [];

values[4] = 'x';
console.log(values.length); // 5
console.log(Object.keys(values)); // [ '4' ]

Writing index 4 raises length to 5. It does not create properties 0 through 3.

Shrinking length performs deletion:

const values = ['a', 'b', 'c', 'd'];
values.length = 2;

console.log(values);       // [ 'a', 'b' ]
console.log(2 in values);  // false

The specification says reducing length deletes configurable own array elements above the new boundary. This is observable object behavior, not merely a pointer change.

Arrays can also carry named properties that do not affect length:

const values = ['a'];

values.owner = 'search-index';
values['01'] = 'not an array index';

console.log(values.length); // 1
console.log(values.owner);  // search-index
console.log(values['01']);  // not an array index

That is enough to reject the simple C-array model. JavaScript arrays participate in prototypes, property descriptors, getters, setters, deletion, and arbitrary named properties.

The specification does not require a growth factor, a backing-store layout, or constant-time access. Those are engine choices.

What V8 does with ordinary dense arrays

V8 separates integer-indexed elements from named properties. For common dense arrays, the elements store can behave like an internal array. For sparse cases, V8 can use a dictionary representation to avoid reserving a mostly empty region. The overview is in Fast properties in V8.

V8 also tracks an array's elements kind. A simplified set is:

PACKED_SMI_ELEMENTS
PACKED_DOUBLE_ELEMENTS
PACKED_ELEMENTS

HOLEY_SMI_ELEMENTS
HOLEY_DOUBLE_ELEMENTS
HOLEY_ELEMENTS

SMI is V8 terminology for small integers represented efficiently by the engine. A floating-point value requires a double representation. A string or object requires a general tagged-element representation.

const values = [1, 2, 3]; // packed small integers

values.push(4.5);         // transition toward doubles
values.push({ id: 5 });   // transition toward general elements

These transitions let optimized code make narrower assumptions when an array stays uniform. They are not JavaScript-visible types. typeof 1 and typeof 4.5 are both number.

The current V8 guide says transitions generally move from specific to more general kinds. It also records a 2025 exception: Array.prototype.fill can repack some holey arrays. That update is a useful warning against turning an engine blog post into eternal law.

Packed and holey are performance hints, not a religion

Creating a large index gap makes holes:

const values = [1, 2, 3];
values[1000] = 4;

For a packed representation, an indexed load can check bounds and read a slot. A holey load may need extra checks, including whether a value exists on the prototype chain.

Array.prototype[1] = 'from prototype';

const values = ['local', , 'end'];
console.log(values[1]); // from prototype

delete Array.prototype[1];

Do not put indexed properties on Array.prototype in real code. The example shows why a hole cannot always be treated as an internal undefined slot.

V8's own guidance is measured: for real-world code, the packed-versus-holey difference is often too small to matter. Keep arrays dense when it is natural, but do not rewrite clear business logic because a diagram told you HOLEY_ELEMENTS is scary.

Profile first. A network request, DOM layout, JSON parse, or database query can erase any win from polishing an array loop.

Growth and operation cost need honest language

Introductory tables often claim:

index read   O(1)
push         amortized O(1)
shift        O(n)

That is a reasonable model for a dynamic contiguous array. It is not a complexity guarantee written into ECMAScript.

An engine may allocate spare capacity, grow a backing store, copy elements, specialize built-ins, or choose a dictionary. shift() changes the logical index of every remaining item, but an engine is free to use internal tricks instead of physically moving every value on every call.

Use the table as an algorithm-design warning:

Repeated push() is usually a natural fast path for dense lists.
Repeated shift() is suspicious for a large queue.
Inserting at the front fights the array's index model.
Huge sparse indices can trigger a representation change.

Then measure the actual runtime and dataset.

For a queue, a head index often communicates intent better than repeated shifting:

class Queue {
  #items = [];
  #head = 0;

  enqueue(value) {
    this.#items.push(value);
  }

  dequeue() {
    if (this.#head === this.#items.length) return undefined;

    const value = this.#items[this.#head];
    this.#head += 1;

    if (this.#head > 1024 && this.#head * 2 > this.#items.length) {
      this.#items = this.#items.slice(this.#head);
      this.#head = 0;
    }

    return value;
  }
}

This keeps dequeue work small and occasionally compacts consumed entries in one batch.

Why microbenchmarks lie so easily

This benchmark changes the array kind while supposedly measuring iteration:

function sum(values) {
  let total = 0;
  for (const value of values) total += value;
  return total;
}

sum([1, 2, 3]);
sum([1.1, 2.2, 3.3]);
sum([1, , 3]);

The call site now receives small-integer, double, and holey inputs. The optimizing compiler may generate different code or handle the site polymorphically. Warmup, garbage collection, dead-code elimination, CPU frequency, and sample size add more noise.

A benchmark should answer a product question such as "which queue representation handles our 99th-percentile burst with less latency and memory?" It should not ask "are arrays fast?"

Measure:

Representative sizes and value types.
Warm and cold behavior when both matter.
Throughput and tail latency.
Allocation and garbage collection.
More than one engine if the code runs in more than one engine.

Keep the result scoped to the tested versions. Engine teams improve these paths continuously.

When TypedArray is the honest data structure

If you truly need fixed-width numeric elements over an exposed binary buffer, use a TypedArray:

const pixels = new Uint8ClampedArray(4 * width * height);
const samples = new Float32Array(4096);

TypedArrays have a defined element type, byte length, byte offset, and backing ArrayBuffer. They trade ordinary Array flexibility for a binary layout suitable for graphics, audio, file formats, and WebAssembly boundaries.

They still are not a magic performance switch. Conversion cost, bounds, alignment, transfer, and API compatibility matter. Choose them because the data is genuinely fixed-width numeric data.

The working rule

I use this sentence when reviewing performance code:

JavaScript arrays are objects with special index and length behavior; engines often optimize dense, uniform arrays with compact element stores.

Both halves matter. The first prevents false guarantees. The second explains why ordinary arrays are fast enough for most application work.

Keep arrays dense when that matches the problem. Use objects or maps for named sparse data. Use a queue abstraction for queues. Use TypedArrays for binary numeric storage. And when performance matters enough to make the code stranger, bring a profiler before bringing folklore.