Solid 2 vs Octane

solid-2-versus-octane.md

NOTICE: I've summarized the perspectives of Octane's and Solid's creators here, for anyone short on time: https://gist.github.com/aleclarson/829c10aa7d287944ef75e1c2a90bef06

---

I'm a React/Preact/Astro developer with an interest in other renderers. The two that have most caught my eye recently are Octane (from Dominic Gannaway of React Hooks / Svelte / Inferno fame) and Solid 2.

I asked ChatGPT to compare them with its own "Renderer DX Pillars", which I've shared below. This is its gut instinct, with very little hedging:

Pillar	Winner	Why
State architecture freedom	Solid 2	Reactivity is independent of components. Much less component gravity.
Reactive reasoning	Solid 2	The dependency graph is explicit and causal. Easier to answer “why did this update?”
Derived state & synchronization	Solid 2	Fine-grained derivation is the native model; less need to coordinate state manually.
Async/data flow	Solid 2	This is basically Solid 2's flagship idea. Async being part of reactivity feels deeper than improving Suspense/hooks ergonomics.
Component authoring	Octane	Normal values, normal functions, familiar TSX, fewer Solid-specific semantic gotchas.
Escape hatches	Solid 2, narrowly	Solid's primitives compose very directly with imperative JS without pretending everything is a component concern.
Ecosystem interoperability	Octane	If its React-ecosystem compatibility ambitions work, this could be a huge advantage.
Tooling & debuggability	Solid 2 today	More mature and battle-tested. Octane's compiler creates more invisible machinery that tooling has to explain well.
Architectural scaling	Solid 2	Its reactive model naturally lets domain/application architecture exist independently of rendering.

So my gut scoreboard is:

Solid 2: 7 Octane: 2

But the two Octane wins are meaningful ones.

Where Octane feels strongest

Its pitch seems particularly strong around:

“I want React's authoring experience without React's runtime/design baggage.”

You get something like:

function Counter() {
  const [count, setCount] = useState(0);
  const doubled = count * 2;

  return <button onClick={() => setCount(count + 1)}>
    {doubled}
  </button>;
}

That's extremely approachable.

Solid asks you to internalize:

const [count, setCount] = createSignal(0);
const doubled = () => count() * 2;

which isn't hard, but it is a different programming model.

So for day-one DX, I wouldn't be surprised if Octane feels better.

Where Solid feels fundamentally stronger

Solid's advantages seem to accumulate as the application becomes less like:

some components with state

and more like:

a complex reactive application that happens to have a UI.

That's where signals outside components, ownership, fine-grained derivation, async graph semantics, stores, and independent domain state all start reinforcing each other.

My gut says the trajectory looks something like:

small app

Octane  ██████████
Solid   █████████

         ↓ complexity

large/stateful app

Octane  ████████
Solid   ████████████

Not because Octane necessarily scales poorly, but because Solid's abstraction seems closer to the actual problem being modeled once state relationships get complicated.

The pillar I'd be least confident about

Escape hatches.

Octane could easily end up winning there if its compiler makes effects, refs, subscriptions and integration code extraordinarily pleasant.

And ecosystem interoperability could become an overwhelming Octane win if their compatibility layer is genuinely broad and reliable rather than “we have adapters for the popular demos.”

My strongest instincts

If I had to assign confidence rather than points:

• Solid strongly wins: state architecture, derived state, async, architectural scaling.
• Solid probably wins: reactive reasoning, escape hatches.
• Octane strongly wins: initial component authoring.
• Octane probably wins: ecosystem interoperability.
• Solid wins for now: tooling/maturity.

The biggest question I'd personally want answered before choosing between them is therefore not performance.

It's:

Does Octane's compiler actually eliminate the architectural drawbacks of component-centric reactivity, or does it mostly make that model much nicer to write?

If it's the latter, I'd expect Solid 2 to remain the stronger foundation for complex applications.

This time no AI.

If I came off dismissive of Octane that isn't my intention. Especially not from a technology standpoint. The current push of AI forks I find distasteful given the effort it takes to create those libraries in the first place, but I wasn't grouping Octane in with them.

It is more that Ive been pushing back against React for over a decade now. Not React the implementation, but React the model. React the implementation has been poked at for years. But the model has had people feel secure despite what empirically was in front of them. It has taken a long time to gain any ground against its inertia.

So to me this is like OOP vs FP, or maybe closer to home immediate mode vs retained mode. I didn't enter the ring because of adoption, developer experience, or even performance, but a belief in a fundamentally better model. Obviously I acknowledge it isn't something so cut and dry. But it is why I focus on education and trends that span more than a single framework.

I don't doubt Octane is capable of everything you are setting out to accomplish. I think language/compiler is an important part of the authoring story even more so with AI. Solid just approaches the problem the way I always have with the view a compiler is a last stage optimization. We need to know what we are building first. It can be argued that maybe Svelte switched gears too quickly, but it is a textbook example of what Im talking about. They had the compiler but then they realized they had an incomplete model.

Solids track record of not changing is very much grounded in our approach. We didn't chase DX. And in that I think we have a lot in common with React. The prevalence of agents doesn't change those foundations of truth to me. Which is to say if you ask me what we should be building it isn't Reacts model. That foundation has had its chance and for the betterment of the ecosystem we need to explore different paths.

The compiler can come later. We're still catching up to the deficit of not having nearly as many people building on this model the past decade. The fact that we are still discovering concrete wins at runtime without a compiler I view as evidence this has more legs. Far from solved.

So if you hear me being critical here it is just rebelling against the calcification of Reacts core model. It has enough legacy as it is. I refuse to accept it and I will undermine it at every junction. Not out of malice or disrespect of the engineering that goes into solutions built on top of it, but because that is the foundation on which my work stands.

Thanks for clarifying Ryan. Like I said, it's all good.

I know you only have good intentions with your thinking and comments. I'm not trying to rain on your endeavours or your critical thinking into why React's model isn't the right one. We all know it's not right, I already tried and largely failed with trying to change that with Ripple. The community just have no appetite to adopt new frameworks anymore. I was having a chat with a very well known software engineer that used to work at Google the other month and he said that he was excited by Ripple but has no reason to move from React, because the migration path simply isn't worth it anymore. He can get an agent to fix the performance issue in React and it largely just works eventually.

I'm just a builder and tinkerer. Octane is an attempt for me to delve further down the path I first started on with Inferno all those years back. I feel like I left unfinished business on the table when I was working on the OG React Compiler – Prepack whilst at Facebook and this has been a nice change of scenery for me. If the migration story from moving from React to something a lot better is watertight, then just maybe it will move the needle, or at least their agent will tell them they should.

It's also crucial to point out here that signals play a major role in Octane too – just not as a first-class citizen just yet – they might though, but we first wanted to let people decide what to use and our recommendation has been to use Alien Signals or Jotai/Zustland if people are already using that in their React apps. useState is a good local state mechanic, but again, with "use strong" we can detect people using it in problematic ways and push people to use better state mechanics, such as signals, state machines or context.