Skip to main content

Octane: the React API without React underneath, and what it signals for the ecosystem

· 9 min read
Bruno Carneiro
Bruno Carneiro
Fundador da @TautornTech
Octane: the compiled React, without a virtual DOM

If you follow the React ecosystem closely, you've probably tripped over this announcement this week. Dominic Gannaway launched Octane, described as "the React programming model, compiled". It's the declared successor to Inferno, the framework Gannaway himself built back in 2016 with the same performance pitch.

It's worth pausing to understand two things. First, what it actually does technically. Second, and more important for anyone making stack decisions, what its arrival says about where React is heading.

The pitch: the API you already know, without the implementation you already know​

Octane doesn't ask you to learn a new mental model. useState, useEffect, useMemo, useCallback, context, portals, Suspense, transitions. The API is the same, tested against more than 2,200 conformance tests pulled directly from facebook/react.

The difference is entirely under the hood:

  • No virtual DOM. A compiler generates the render path and a keyed reconciler based on LIS (longest increasing subsequence), instead of diffing a virtual tree at runtime.
  • No manual dependency arrays. Omit the array in useEffect, useMemo, useCallback, and friends, and the compiler infers dependencies from what the closure actually captures. It also recognizes state setters, refs, and dispatchers as stable.
  • No "rules of hooks". Hooks are bound to their call site by the compiler, not to execution order. Meaning: they can live inside an if or after an early return without breaking anything. The only rule that remains is "no hooks inside a plain loop", which becomes a compile error. The @for (iteration operator from the .tsrx dialect) solves this by giving each item its own state slot.
  • Two dialects, one language. Standard JSX/TSX works with no changes. The .tsrx dialect is optional and adds control-flow directives (@if, @for, @switch, @try) that compile to keyed fast paths.

In practical terms: three of the most annoying React day-to-day pains (manual memoization, dependency arrays, mandatory hook order) go away, and you keep writing the same code.

To make it concrete, this is the example the Octane README itself uses to show the four possible forms of useEffect:

useEffect(() => sync(room.id));             // no array: the compiler infers [room.id] from the closure
useEffect(() => initialize(), []);          // empty array: mount only
useEffect(() => sync(room.id), [room.id]);  // explicit deps (keeps React behavior)
useEffect(() => measure(), null);           // null: runs after every commit

Notice how the top one is what actually kills the pain. You write the code, the compiler looks at what the closure captures, and builds the dependency list. And if you want to be explicit, the other three forms still work with the exact same React semantics.

The other thing that shows up in practice is "hook after an early return". In React, that's an error. In Octane, it works:

export function Panel(props) @{
  const [n, setN] = useState(0);

  if (props.hidden) return; // early return before a hook, ok

  useEffect(() => {
    // ...
  });

  <div>{n}</div>
}

This is possible because the compiler ties each hook to its call site, not to execution order. Anyone who has ever tangled themselves up trying to avoid an early if in a React component gets the value of this immediately.

Where this comes from​

Some context on who's behind it. Gannaway built Inferno in 2016 to test whether React-like interfaces could be optimized more aggressively. It was a time of intense debate about front-end performance. After that, he worked on the React team itself, on Lexical (Meta's text editor), and on Svelte.

Octane is, in practice, the second lap around the same question. Now with a much more sophisticated compiler and a project that was declaredly built for AI to help with development (the repo has dedicated folders for .claude, .codex, .cursor/rules, AGENTS.md, CLAUDE.md, GEMINI.md).

That in itself is a signal: a new framework in 2026 is being born assuming that whoever writes code in it is human and AI agent.

Where it fits on the compiled-frameworks map​

The most interesting point for anyone watching the ecosystem is that Octane doesn't arrive in a vacuum. It arrives at a moment when the "React vs. compiled frameworks" boundary was already shifting.

The React Compiler has already solved part of the problem inside React. It (formerly known as React Forget) reached its stable release and is already the default in frameworks like Next.js 16, doing automatic memoization without useMemo, useCallback, or React.memo. It's the same pain Octane attacks with dependency inference. The difference is that the React Compiler still operates on top of a Virtual DOM. It removes the manual work of memoization, but doesn't remove the reconciliation layer. Octane goes one step further and takes the VDOM out of the equation entirely, like Solid and Svelte already do.

Solid and Svelte 5 have already proven the "no VDOM" thesis. Solid uses signals with DOM-node granularity, no component re-render, just surgical updates of what changed. Svelte 5 (with runes) compiles to direct DOM operations, with a runtime of about 1.6 KB against Solid's ~7 KB. For most applications, the performance difference between these approaches is imperceptible. Which suggests that Octane's real value proposition isn't "faster than Solid", but rather "the speed of a VDOM-less framework with React's API and ecosystem".

That's a pretty specific bet. Instead of asking React devs to learn signals (Solid) or runes (Svelte), Octane bets that the hooks API has already won the mental-model race, and that what was missing was just removing the implementation cost of it.

tip

Translating for stack decisions: if your team already thinks in hooks, Octane gives you the performance win with no retraining cost. If you're starting from scratch, it still makes sense to look at Solid/Svelte for the leaner mental model.

Signs of traction, and what's still unproven​

Initial reception carried real weight. Tanner Linsley (TanStack maintainer) has publicly commented that TanStack has adapters for Octane practically ready for Start and other libraries in the suite. The repo itself already lists ports of zustand, jotai, TanStack Query/Router/Table/Virtual, Apollo Client, Motion, StyleX, Radix, base-ui, React Hook Form, Redux/Redux Toolkit, Lexical, Recharts, visx, i18next, and MDX.

In other words: a deliberate attempt to reduce migration cost to a minimum by bringing the entire React ecosystem along instead of demanding a rewrite. That's what separates Octane from other "React but faster" attempts. It's not asking the ecosystem to choose between performance and the libraries it already uses.

That said, feet on the ground:

  • The project is officially in alpha. The API may change, and "2,200 conformance tests" covers hook semantics, not necessarily every production edge case at scale.
  • Ecosystem binding parity is variable per package. The project itself maintains a status table (docs/bindings-status.md) admitting that some ports are partial.
  • Adopting Octane today means betting on a young compiler for SSR, hydration, and streaming. These are areas historically full of edge cases that are hard to get right on the first try.
warning

Testing on a side project, a technical spike, or a playground, fine. Putting a customer-facing product on top of an alpha compiler is a recipe for headaches: when it breaks (and it will), you're going to be debugging the compiler, not your code.

Why this matters for the React ecosystem​

The strongest signal Octane sends isn't about Octane itself. It's about the consensus that has formed around React's hooks API.

After years of "signals vs. hooks" as the dominant narrative at conferences and on Twitter, we now have three distinct responses converging on the same diagnosis (the React implementation has unnecessary cost), with different prescriptions:

ApproachWhat it keepsWhat it removes
React CompilerVDOM, hooksManual memoization
Solid / SvelteAggressive compilationVDOM, hooks (traded for signals/runes)
OctaneHooks and the entire APIVDOM, deps arrays, rules of hooks

If Octane can deliver on this with production stability (and that "if" is still big, given the alpha stage), it becomes the strongest argument ever made that "hooks" and "virtual DOM" were never the same design decision, and that you can have one without the other.

That puts pressure on both sides. React has to show that the Compiler can close the performance gap without giving up the VDOM. Solid and Svelte have to justify why it's worth asking devs to learn a new mental model, if the "compiled" version of the old model already solves the problem.

What to do with this next week​

If you make stack decisions, the practical read is short:

  • Don't migrate production. Alpha is alpha, and SSR/hydration in a new compiler is where things break badly.
  • Play with it in the playground. Half an hour of exploration gives you way more signal than reading any Twitter thread on the topic.
  • Keep an eye on TanStack. If Tanner's adapters ship stable, that's the first concrete sign that the ecosystem has actually started moving.
  • Rethink the internal narrative. If your team's talk was "we need to switch frameworks to get performance", Octane (together with the React Compiler) is evidence that the problem may never have been the framework, just its implementation.

It's the kind of bet that, if it pays off, changes the conversation from "I need to switch frameworks to get performance" to "my favorite framework is fast enough, it just needed a better compiler". And that's good for everyone.

References​