English for Million.js Developers
Vocabulary for developers using Million.js to speed up React rendering — the block virtual DOM, compiler optimizations, and benchmarking talk for performance-focused teams.
Million.js is a compiler and runtime that speeds up React rendering by replacing parts of React’s virtual DOM diffing with a faster “block” abstraction for static-shaped components. Talking about it precisely means being comfortable with performance vocabulary — reconciliation, re-renders, memoization — plus Million’s own terms like “blocks” and “for-loops.” This guide gives you the English for discussing rendering performance work with your team.
Why Million.js Exists
Reconciliation — React’s process of comparing the previous and next virtual DOM trees to figure out the minimal set of real DOM changes needed. “Reconciliation is fast in general, but for components that re-render very frequently with mostly static shape, there’s overhead Million.js is designed to cut.”
Virtual DOM (VDOM) — an in-memory representation of the UI that frameworks diff against the previous version, instead of touching the real DOM directly on every change.
“Million doesn’t replace the virtual DOM concept entirely — it introduces a faster, more specialised diffing path for components with a known, static structure.”
Re-render — when a component’s render function runs again, typically because its state or props changed.
“We profiled the component and found it was re-rendering forty times per second during a drag interaction — that’s exactly the kind of hot path Million targets.”
Core Million.js Concepts
Block
A block is Million’s core primitive — a compiled, optimised representation of a component’s static and dynamic parts, allowing much faster updates for the dynamic pieces alone.
“We wrapped the list item component in
block()— since its structure never changes, only the text content, Million can update just that one text node directly.”
Compiler
Million’s compiler (usually via a Babel or Vite plugin) analyses your JSX at build time and automatically transforms suitable components into blocks, without you needing to rewrite them by hand.
“With the compiler plugin enabled, we didn’t manually wrap every component — it automatically detected candidates and optimised them during the build.”
For-Loop Optimization
Million’s for-loop (or array) optimisation specifically targets rendering lists efficiently, minimising the work needed when items are added, removed, or reordered.
“Our table with 10,000 rows was the worst offender for re-render time — the for-loop optimisation cut update time dramatically for row insertions.”
Static Hoisting
Static hoisting moves parts of a component’s output that never change outside of the render function entirely, so they’re computed once instead of on every render.
“The icon and label never change for this button — with static hoisting, Million computes that part once and reuses it, instead of recreating it every render.”
Benchmarking and Profiling Vocabulary
Render time — how long a component takes to compute its output and commit it to the DOM, usually measured in milliseconds.
Frame budget — the time available per frame (about 16ms at 60fps) to keep an interface feeling smooth; exceeding it causes visible jank.
“Before optimisation, updating the list blew through the frame budget on lower-end devices — after switching to blocks, it stayed well under it.”
Flame graph — a visualisation of where time is spent during rendering, used to identify which components are the actual bottleneck before optimising.
“The flame graph showed almost all the time was in one deeply nested list component — that’s where we focused the optimisation effort, not everywhere at once.”
Micro-benchmark — a narrowly scoped performance test measuring one specific operation, useful for comparing approaches but not a substitute for real-world profiling.
“The micro-benchmark showed a big win, but we didn’t roll it out until we confirmed the improvement held up in our actual production-sized dataset.”
Talking About Trade-Offs
Premature optimisation — optimising code before confirming it’s actually a bottleneck, often at the cost of readability or maintainability.
“We didn’t reach for Million on every component — only the ones the flame graph actually flagged as expensive, to avoid premature optimisation.”
Escape hatch — a way to opt a specific component out of an optimisation when it doesn’t fit the assumptions the optimiser relies on (for example, highly dynamic structure).
“This component’s shape changes based on a feature flag, so we used the escape hatch to keep it on regular React rendering instead of forcing it into a block.”
Explaining the Decision to a Team
| Situation | Phrase |
|---|---|
| Justifying adoption | ”We only adopted Million for the components our profiling flagged as expensive — it’s not a blanket rewrite of the app.” |
| Explaining a measured improvement | ”Converting the row component into a block cut its update time by roughly 70% in our benchmark on the large dataset.” |
| Describing a limitation | ”Highly dynamic components with unpredictable structure don’t benefit much from blocks — we left those on standard React rendering.” |
| Reporting a regression | ”After the last dependency update, one component stopped qualifying for the compiler’s automatic optimisation — we’re investigating why.” |
Common Mistakes
- Saying “Million.js replaces React” — it’s a compiler-level optimisation layered on top of React, not a replacement framework.
- Calling every performance win a block optimisation without checking — some gains come from unrelated changes like memoization or reduced prop drilling.
- Describing a micro-benchmark result as proof of a real-world improvement without validating it against actual production data.
Practice Exercise
- Explain, in two sentences, what a “block” is and why it can update faster than a standard React re-render.
- Write a short PR description explaining that a specific list component was converted to use Million’s block optimisation, including the measured before/after numbers.
- Draft a message to a teammate explaining why you decided not to apply an optimisation to a highly dynamic component.