Conventional wisdom says optimizing front-end performance demands complex state management solutions and intricate code splitting strategies. But what if the biggest gains weren't in *how* you manage data, but in fundamentally rethinking *if* React needs to touch that data at all? That's the core idea behind Million.js, a library built by Aiden Bai that delivers startling performance improvements by minimizing re-renders and challenging core React assumptions.
That observation is where Aiden Bai began. Not with a startup pitch or a funding round, but with a question: what if the diffing step that makes React feel safe and declarative is also the thing slowing it down?
The answer became Million.js, an optimizing compiler that has since accumulated over 17,000 stars on GitHub, attracted backing from some of JavaScript's most respected engineers, and quietly found its way into production applications running for millions of users. This is the origin story of how it got there.
The Problem Inside React's Speed
To understand why Million.js matters, you first need to understand what React is doing every time you click a button or update a piece of state. According to the official Million.js documentation, React's update cycle has two parts: rendering and reconciliation.
Rendering is the process of generating a snapshot of the current component essentially calling the function and storing the output in memory. Reconciliation is where things get expensive. React takes that new snapshot and compares it, element by element, against the previous snapshot. This comparison sometimes called diffing is how React decides which parts of the actual DOM need updating.
The documentation illustrates this with a deceptively simple example: a counter component with a single button. When the count changes, React doesn't just update the number. It checks every element in the tree. The outer div. The paragraph tag. The button itself. The onClick handler. Six diff checks for a component that only needed one thing changed.
In isolation, that overhead is negligible. But in a real-world application with hundreds of elements, the math compounds. As the documentation puts it: "React is slow. The issue with React's reconciliation it becomes exponentially slower the more JSX elements you have."
That sentence contains the entire premise of Million.js.
Aiden Bai's Approach: Skipping the Walk
The solution Bai engineered is elegant in its bluntness. more than finding ways to diff faster, why not skip the diffing step entirely?
According to analysis published on OpenReplay's blog, Bai designed Million.js with a core philosophy: "focuses on performance optimization from the very beginning." Unlike libraries that accumulated rendering costs over years of backward compatibility, Million.js was written with a specific target in mind modern web applications where most of the UI is static but some parts update frequently.
The technical mechanism works in two phases. At compile time, Million statically analyzes your JSX and divides it into two categories: static holes (fixed structure like divs, classes, and layouts that never change) and dynamic slots (the actual values that can change text content, classNames, event handlers). At runtime, Million only updates the dynamic slots, bypassing the tree walk completely.
This transforms the performance characteristic from O(tree size) to O(slots) a distinction that becomes dramatic as applications grow.
The Drop-In Philosophy
What makes Million.js distinctive in the JavaScript ecosystem is not just its technical approach but its developer philosophy. The project is explicitly designed to integrate without disruption.
As Techoral's 2026 guide to Million.js explains, the tool is positioned as a "drop-in compiler and runtime that makes React components up to 70% faster by replacing React's diffing algorithm with a fine-grained, block-based virtual DOM." The emphasis on "drop-in" is deliberate.
Developers don't need to rewrite their applications or abandon React's ecosystem. Million.js wraps existing components through a block() higher-order component, allowing adoption to happen incrementally. A team can optimize their most frequently-updating components first dashboards, live data tables, notification feeds and leave the rest untouched.
The block() API requires one rule: props must be serializable primitives (strings, numbers, booleans) more than functions or complex objects as direct props. This constraint is what allows Million to work its optimization magic. For most UI components passing primitive data, this limitation doesn't impose real friction.
The Numbers Behind the Claims
Million.js's marketing leads with a specific claim: components can run up to 70% faster. That number appears consistently across published benchmarks and third-party analysis. The figure comes with context: the 70% improvement applies specifically to components with large static structure and a small number of frequently-changing values.
A dashboard with a fixed layout and a handful of live data points is exactly this profile. A highly dynamic component with dozens of independent state variables might see less dramatic gains. The performance characteristic is predictable and tied to the block-based architecture more static structure means more room for optimization.
Memory consumption tells a similar story. Third-party benchmarks show more pronounced differences in memory usage than raw render speed, suggesting that the overhead reduction extends beyond CPU cycles to garbage collection pressure and overall browser resource usage.
Building in Public: The GitHub Years
The repository at github.com/aidenybai/million tells its own story through commit history. Over 2,364 commits across multiple branches and packages show a project that evolved through sustained iteration beyond a single breakthrough moment. The website, documentation, CLI tooling, and test infrastructure grew alongside the core compiler.
This kind of organic growth is characteristic of developer tools that earn adoption through demonstrated utility more than marketing budgets. The GitHub repository accumulated stars steadily, reaching the 17,000+ mark through organic discovery developers encountering the project, trying it on performance-sensitive components, and spreading the word when it worked.
The project also spawned related tools: React Scan and React Doctor, both mentioned on the company's official site as tools that "run for millions of users in production." This ecosystem approach providing not just the optimization but the visibility into what needs optimizing reflects a mature understanding of developer workflows.
From Open Source to Institutional Backing
The trajectory of Million.js reflects a pattern familiar in open-source JavaScript: a compelling technical solution, proven in production, attracts attention from the ecosystem's established figures. According to Million Software, Inc.'s website, the project is backed by a roster that reads like a who's-who of JavaScript infrastructure: Scott Wu (founder of the coding education platform), Amjad Masad (co-founder of Replit), Evan You (creator of Vue.js and Vite), David Cramer (co-founder of Sentry), and Y Combinator, which accepted the company in its W24 batch.
This kind of backing brings more than capital. It brings credibility, network effects, and perhaps most valuably access to engineering teams at companies where JavaScript performance is a business-critical concern. The backing suggests that Million.js is not merely a hobby project but a technology that established developers view as representing the future of frontend performance.
What This Means for TheWebSolvers Readers
For readers researching web development frameworks, performance tools, and the practitioners building modern JavaScript infrastructure, Million.js offers a case study in several relevant themes.
First, it demonstrates that optimization opportunities exist even in battle-tested, widely-adopted tools like React. The virtual DOM that made React accessible and safe to use for millions of developers also introduced predictable overhead. Identifying and addressing that overhead is exactly the kind of practical improvement that separates useful tools from merely interesting ones.
Second, it illustrates a specific pattern for framework evolution: more than replacing an existing ecosystem, Million.js builds on top of it. This "layered" approach, which the Techoral guide explicitly compares to how Solid.js and Svelte handle similar optimization challenges, means developers can adopt incremental improvements without abandoning existing investments in React knowledge, components, and tooling.
Third, the project's trajectory from personal observation to open-source release to Y Combinator backing models how developer tools can earn adoption through technical merit more than marketing spend. For readers evaluating which tools to invest time in learning, this kind of organic growth signals genuine utility.
The Setup Story: Getting Started with Million.js
One of the practical strengths of Million.js is its setup simplicity. The project provides integration with Vite, Next.js, and Webpack, with the plugin pattern making adoption a matter of configuration more than code changes.
For Vite projects, the configuration involves importing the Million compiler plugin and enabling automatic mode, which automatically wraps eligible components without explicit manual wrapping. For Next.js, a similar pattern applies with the million.next() configuration function. The automatic mode handles the complexity, though developers can opt for manual mode when they need explicit control over which components receive the optimization.
The documentation also covers advanced patterns: the <For> component for optimized list rendering, the stringToDOM() function for manual template handling, and experimental APIs for edge cases. This layered documentation strategy simple for common cases, comprehensive for edge cases reflects the kind of thoughtful API design that makes developer tools feel considered more than bolted together.
Where Million.js Fits in the Ecosystem
The JavaScript framework landscape has seen waves of optimization-focused projects, each addressing different aspects of the performance problem. Svelte compiles away the virtual DOM entirely. Solid.js uses fine-grained reactivity to achieve similar goals. React Server Components push computation to the server.
Million.js occupies a specific niche in this landscape: it optimizes the most common React usage pattern without requiring migration away from React itself. For teams with large React codebases who cannot afford the cost of rewriting, this is not merely convenient it may be the only realistic path to meaningful performance improvement.
The OpenReplay analysis frames this positioning clearly: "Even with its relative newness, it quickly captured developers' interest because it is very appealing for modern web development projects, promising high performance and a smooth, user-friendly development experience." The emphasis on "user-friendly development experience" points to an important distinction. Million.js does not ask developers to think differently about UI composition. It simply makes their existing patterns faster.
A Quiet Engineering Achievement
What makes Million.js worth understanding is not the scale of its ambition but the precision of its execution. A single developer, asking a question that thousands of React developers had probably asked themselves without pursuing it, built a tool that handles a specific performance problem elegantly and without fanfare.
The origin story is quiet: no massive launch event, no venture-funded marketing blitz, just a GitHub repository, some documentation, and a tool that developers discovered when they needed it. That pattern technical merit driving adoption more than the reverse is rarer than it should be in the JavaScript ecosystem, and it's worth paying attention to when it happens.
Aiden Bai's creation asks a question that remains relevant as web applications grow in complexity: if most of your UI is static, why is your framework treating it as if it might change? The answer block-based, compile-time analysis that skips unnecessary work represents a genuine insight. And for developers building applications where every millisecond matters, it's an answer worth having.
Where to read further
- The official Million.js documentation provides the foundational explanation of how the compiler works, including code examples for the rendering and reconciliation process.
- The Million.js GitHub repository contains the source code, commit history, and current development status of the project.
- OpenReplay's comparison analysis offers a detailed performance breakdown between React's default virtual DOM and Million.js's block-based approach.
- Techoral's 2026 implementation guide walks through setup, the block() API, automatic compiler mode, and practical advice for when Million.js helps most.
- The Million Software, Inc. company page provides context on the team, their other products (React Scan, React Doctor), and their institutional backing.