👋 Hey Dominic — I collected a few thoughts on the landing page. Hopefully there’s something useful in here.
My main impression is that the page is written primarily for engineers who are already interested in renderer/framework architecture.
That audience obviously matters. But I suspect it causes the page to spend too much time answering:
“Is Octane technically interesting and defensible?”
before sufficiently answering:
“Why should my team care about Octane?”
I may be putting too much weight on the distinction, especially because the people making framework decisions are often engineers themselves. But the mode of evaluation still seems different.
“React’s programming model, compiled.” is a strong starting point.
The material immediately below it, though, introduces quite a few concepts at once: Inferno, hooks, Suspense, actions, virtual DOM removal, hook rules, dependency arrays, and compiler tracking.
Most of these are relevant, but together they make the reader assemble the value proposition themselves.
The simpler idea I took away from the page was something like:
Octane tries to preserve the React programming model while removing some of the runtime and ergonomic costs associated with React.
That feels like a fairly compelling proposition. I’m not sure the page states it as clearly or as early as it could.
Several sections explain how Octane works before it is completely clear why that particular property matters to someone considering adoption.
Examples include:
- compiled DOM updates
- async execution behavior
- the absence of a virtual DOM
- the signals discussion
- detailed API compatibility
For a framework engineer, these are useful evidence.
For someone deciding whether Octane deserves attention from their team, I suspect questions like these come first:
- What materially improves for us?
- How disruptive is adoption?
- How much React knowledge carries over?
- Can we experiment without making a large commitment?
- How much ecosystem compatibility do we lose?
- How mature is this?
The page does address several of these. They just aren't always given the same prominence as the architecture.
“Why not build Octane on signals?” stood out to me.
It seems like a legitimate design question, and probably an important one among people deeply interested in reactivity models.
But I'm less sure that it belongs this early in the main landing-page narrative.
Introducing the signals debate also introduces an objection that many React developers may not have had yet. The page briefly becomes an argument about framework architecture rather than an explanation of why somebody might adopt Octane.
Maybe that is deliberate because Octane's initial audience is primarily framework enthusiasts. If so, this criticism matters less.
The page returns several times to the fact that Octane keeps familiar React concepts:
- components are functions
- props remain props
- hooks exist
- context exists
- familiar data flow remains
- much of the API surface carries over
I think this is one of Octane's strongest selling points.
But because it appears in several places, the page sometimes feels like it is repeatedly reassuring the reader rather than establishing the idea once and then building on it.
There may be an opportunity to make “you keep the React mental model” one of the main organizing ideas of the page.
One of the clearest lines on the page is:
Add Octane to a React app. One component at a time.
That immediately tells me something important about the practical decision: adopting Octane does not necessarily require making an application-wide bet upfront.
Similarly, the explanation that existing TSX can remain while individual components move to TSRX makes experimentation sound relatively contained.
I would put a caveat on the usual migration-cost argument, though.
The cost of mechanical code migration seems substantially less important than it was historically because coding agents can now perform a lot of repetitive translation work. So I’m not sure “the rewrite is smaller” should be treated as the whole advantage.
There are still costs AI does not simply erase: validating behavior, finding semantic mismatches, maintaining two worlds during a transition, retraining intuition, evaluating ecosystem gaps, and deciding whether the new technology is something the team actually wants to depend on.
So the stronger implication of incremental adoption may be optionality rather than saved typing.
A team can try Octane in a limited area, observe what happens, and expand its commitment only if the results justify it.
If that interpretation is right, “one component at a time” may be communicating something more valuable than low migration effort: low commitment to finding out whether Octane is worth adopting.
The page may be organized around what is interesting about Octane rather than how someone evaluates Octane
The current progression sometimes feels like a tour of the technically interesting parts of the project.
A prospective adopter may have a different sequence of questions:
What is this? → Why should I care? → What do I have to give up? → How safely can we evaluate it? → Does it actually deliver? → How does it work?
Octane appears to have answers to most of those questions.
My uncertainty is mostly about ordering and emphasis rather than whether the necessary substance exists.
It's possible I'm assuming a broader audience than Octane actually wants right now.
If the immediate objective is to attract renderer authors, library authors, and highly technical early adopters, the current page may be appropriately technical.
If the objective is eventually to persuade teams that already use React to seriously consider Octane, I think the balance may be different.
I'm also not sure how much weight to put on migration difficulty anymore. AI may have changed that calculation enough that the historically compelling “incremental migration” pitch now matters primarily because it reduces risk and commitment, rather than engineering labor.
The questions I'd probably use to think about it are:
- Who is the landing page primarily supposed to convince today?
- What decision should someone be ready to make after reading the first screen or two?
- Is Octane mainly competing for architectural mindshare right now, or for actual React application adoption?
- Which concern has proven harder in conversations with potential users: convincing them that Octane works, or convincing them that adopting it is worth trying?
- Does “one component at a time” matter mostly because migration is easier, or because it makes the decision reversible?
- Has AI reduced migration cost enough that other adoption concerns now deserve substantially more emphasis?
Depending on those answers, some of this critique may matter a lot, or very little.