Browser support

This page covers Octane's core DOM renderer, hydration, server-function client, and first-party build integrations. Your application and its other dependencies may have additional requirements.

Support policy

Octane targets current evergreen Chrome, Edge, Firefox, and Safari. For a new application, a useful starting point is the explicit target used by this website's playground runtime and by Vite 8's default build target:

Required browser APIs

Octane uses modern JavaScript and DOM APIs directly. These are particularly important when choosing an older target:

The ordinary DOM runtime also expects native DOM events, template elements, document fragments, Map, Set, WeakMap, WeakSet, Symbol, Promise, and standard modern object and array methods. The versions above come from MDN's browser compatibility data. They put a known lower bound on the ordinary DOM path: Chromium / Edge 86, Firefox 78, and Safari 14 without polyfills. They do not establish that every Octane feature, dependency, or emitted bundle works at that bound.

These requirements and fallbacks describe current Octane. Releases 0.1.9 through 0.1.34 also called Object.hasOwn() in ordinary component capability checks. Octane 0.1.35 removed that core dependency and added browser scheduling, observer, media-query, and mobile-input compatibility fixes. Check your installed version before applying this page to an older release.

In particular, an older Chromium browser can successfully load a page and then fail when a later hydration or cleanup path calls replaceChildren(). Setting build.target to that browser does not create the missing DOM method. A passing test in a newer browser does not exercise the missing API either.

Feature-specific requirements

Some core features need more than the ordinary DOM path:

See Core APIs for the behavior of each feature. Recheck the requirements when upgrading Octane or changing the kinds of data sent through server functions.

Features with fallbacks

These APIs improve behavior when available, but their absence does not by itself raise the ordinary rendering requirement:

Do not add all of these to an application-wide browser gate. Test whether a missing optional feature changes the experience you intend to provide.

Choose a build target

The published core runtime is modern ESM; its package build targets esnext. The consuming application must lower JavaScript syntax for its own browsers. For a routed Vite or Rsbuild app, set the shared target explicitly:

// octane.config.ts
export default {
	build: {
		target: ['chrome111', 'edge111', 'firefox114', 'safari16.4', 'ios16.4'],
	},
};

For a client-only Vite app, put the same build.target in vite.config.ts. With low-level Rspack, configure both the JavaScript transform and Rspack's generated runtime. See Build tools for the integrations.

Rsbuild's modules target maps to Chrome 87, Edge 88, Firefox 78, Safari / iOS 14, and Samsung Internet 14. It is a syntax target, not a promise that form actions, RPC, native inert, or every application dependency works there. Explicit browser arrays work across the full Vite and Rsbuild integrations; Vite's baseline-widely-available shorthand is not an Octane-wide target name.

Syntax transforms and API polyfills solve different problems. If your target lacks an API in the tables above, load an appropriate, maintained polyfill before importing the application, avoid the feature, or raise the target. Check the final production chunks, including dependencies and lazy-loaded code. Neither a successful build nor a JavaScript syntax target supplies missing DOM methods. Rsbuild's compatibility guide explains its separate syntax and polyfill settings.