An Octane root can now attach behavior to DOM owned by another system instead of assuming that Octane owns and renders the DOM itself.
This opens several practical adoption paths:
👋 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?”
Last updated in response to this comment.
The shortest version: Solid 2 makes reactive relationships part of the running program. Octane tries to keep application code closer to ordinary JavaScript while giving a compiler more responsibility for understanding and optimizing it. The debate comes down to what reactive code should mean when you write it, and what information should remain available when the app is running.
The thread began as a developer-experience scorecard. After several rounds between Dominic Gannaway, creator of Octane, and Ryan Carniato, creator of Solid, the disagreement has become both narrower and more interesting.
It is not really compiler vs runtime. Both use both.
I’d avoid comparing Solid 2 and Octane primarily on benchmark speed. They’re both already attacking the “make DOM updates cheap” problem aggressively; the interesting comparison is what each makes you think about while building a real application. Solid makes fine-grained reactivity fundamental, while Octane deliberately preserves a component/re-render/hooks mental model and pushes more bookkeeping into its compiler. ([SolidJS Docs][1])
I’d use these nine DX pillars:
| Pillar | The question I’d test |
|---|---|
| 1. State architecture freedom | Can state live wherever the domain says it should, or does the renderer pull it toward components? |
| 2. Reactive reasoning | How easy is it to understand why somet |
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 |
|---|
Solid 2.0 makes async data part of Solid’s normal reactive system.
A reactive value can depend on a Promise. Solid tracks that async work as part of the dependency graph.
This means you need less manual code for:
transitions
Ryan Florence doesn't like me saying that, but it's true.
Why is it true? Well, they look like render props until you scroll down to the return statement and see an arrow function. If you refactor a stateless component into a stateful component (i.e. add a setup scope), the render props subtly become setup props, right under your nose.
Most of the time, using setup props is dangerous and unnecessary, as it leads to problems down the road. At first, all is well, but then you use the component more dynamically and, BOOM, you've got a stale data issue that presents itself in confusing ways. Of course, this problem is most apparent in more complex applications with many moving parts.
| // Track props access and selectively rerun callbacks on rerender. | |
| export function track<Props extends object>( | |
| ...callbacks: ((props: Props) => void)[] | |
| ) { | |
| const tracked = callbacks.map((callback) => new TrackedCallback(callback)) | |
| let oldProps: Props | undefined | |
| return (props: Props) => { | |
| tracked.forEach((callback) => { | |
| if (!oldProps || callback.shouldUpdate(props, oldProps)) { |
| import { Event, events, EventTarget, on } from './framework.ts' | |
| // Extending a built-in class with type-safe events | |
| declare global { | |
| interface Worker { | |
| // Does not exist at runtime. No createEventType wrapper needed. | |
| $rmxEvents: { | |
| message: MessageEvent | |
| } | |
| } |