Skip to content

Instantly share code, notes, and snippets.

@aleclarson
Last active August 23, 2026 17:31
Show Gist options
  • Select an option

  • Save aleclarson/82d9eb9f91988066c5b080bdaebaa2c1 to your computer and use it in GitHub Desktop.

Select an option

Save aleclarson/82d9eb9f91988066c5b080bdaebaa2c1 to your computer and use it in GitHub Desktop.
Octane progress: August 8–22, 2026

Octane progress: August 8–22, 2026

Octane can now enhance DOM it doesn't own

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:

  • Add Octane behavior to server-rendered HTML.
  • Introduce Octane incrementally inside an existing application.
  • Build widgets that coexist with another renderer.
  • Use Octane where replacing the surrounding DOM ownership model would be too disruptive.

This is the clearest new Octane feature from the period. It changes where Octane can be introduced, not merely how well an existing application compiles.

React 19 parity is reaching the edges that break real apps

Scripts, styles, and metadata now follow React 19

Octane added more of React 19's resource and document behavior:

  • Stylesheet and script hoisting
  • preload and preinit
  • Module variants of preload and preinit
  • Resource deduplication
  • Stylesheet precedence
  • <style href precedence> behavior
  • Nested document metadata

These changes should reduce Octane-specific workarounds in applications and libraries built around React 19's resource model.

Root errors now land in the right hooks

Roots now support React-compatible error hooks:

  • onCaughtError
  • onUncaughtError
  • onRecoverableError

The result is a more familiar error-reporting model for React-oriented libraries and application infrastructure.

Fragment refs stop being a compatibility trap

Octane completed its implementation of React's newer Fragment ref behavior. Libraries and application code that use the Fragment ref API now have a compatible target in Octane.

Prerendering gets a Node stream API

Octane added prerenderToNodeStream, extending its compatibility with React's server-rendering APIs.

The binding catalog is becoming broad enough to plan around

@octanejs/motion handles the layout cases that expose renderer gaps

The binding for Motion gained broader layout-animation and lazy-loading support, including:

  • Preserving transforms during layout measurement
  • Layout handoffs
  • Stable lazy features across rerenders
  • Strict LazyMotion behavior

This work improves behavior in the cases where animation libraries tend to expose subtle renderer differences.

@octanejs/monaco-editor opens the door to full editor apps

Octane added a binding for Monaco Editor with:

  • Controlled language and value behavior
  • Diff editor handling
  • Model reuse
  • An Octane playground

Monaco support makes Octane more practical for code editors, playgrounds, and other developer tools.

@octanejs/xstate covers machines while @octanejs/xstate-store covers stores

@octanejs/xstate ports the XState React API, while @octanejs/xstate-store ports XState Store. Together they cover both state-machine integration and the lighter store model.

@octanejs/resizable-panels accounts for persistence and SSR

The binding ports react-resizable-panels and accounts for persistence and server-rendering behavior.

The rest of the binding map fills in

State and data

Animation and interaction

Content and input

Layout and rendering

Application integration

More build setups work without Octane-specific exceptions

TanStack Start works under Rsbuild

Octane can now run with TanStack Start under Rsbuild. The integration includes server-rendering behavior such as removing ClientOnly content where appropriate.

CommonJS is a real distribution target

Octane and its bindings gained executable require package conditions and CommonJS dependency graphs. Consumers whose toolchains still resolve CommonJS packages no longer face an effectively ESM-only distribution.

Rspack can compile Octane in parallel

Rspack can compile Octane modules across parallel loader workers. This is a build-performance improvement rather than an application feature, but it should shorten compilation in larger projects.

Compiler stability is catching up with normal TypeScript

Template text stops rejecting valid TypeScript

Octane's TypeScript integration now accepts more ordinary TypeScript values in template-text positions, including generic, union, and narrowed values.

function Label<T extends string | number>({ value }: { value: T }) {
  return <span>{value}</span>;
}

TypeScript already knows that value is renderable text. Octane should not require a cast or conversion to restate that fact. This change removes false errors in normal TypeScript code, so it belongs under compiler stability rather than new authoring capability.

Descriptor children are no longer opaque

Descriptor children are now inspectable instead of opaque. That gives debugging and tooling code more information about compiled and renderable children.

What's in the pipeline

Suspense no longer reveals stale descriptor output

Later on August 22, Octane landed a fix for incomplete descriptor and memoized subtrees. Suspense now retries that work before revealing it instead of letting an equal-props bailout reuse output from an incomplete render.

The retry preserves mounted state, DOM identity, and unaffected memo and identity bailouts. It also repairs a related Activity case where a stable descriptor failed to register its deferred effects.

Generated components may shrink, but the PR claims no hydration speedup

PR #831, opened by @domgan-oai, moves repeated scalar-binding comparisons and child-text updates into compiler-private runtime helpers. It also skips hydration attribute writes when the adopted server value already matches and moves list reconciliation out of the common child path.

An earlier version added calls inside repeated host rows and regressed JSX row selection. The revised compiler keeps those guards inline. The PR reports a 0.84% reduction in summed per-file gzip output across its fixed 16-file comparison, while explicitly making no hydration-speed claim. As of August 23, the PR is open and its full CI run is green.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment