Limitations

Use this page to decide whether Chroma fits your project and to find workarounds. For the feature list, see the API reference.

Not available

Server-side rendering (SSR). Chroma renders in the browser (or in Chroma Desktop). Every component runs once against the real DOM, so there is no hydration step. If your project depends on SSR or SEO-critical, server-rendered pages, choose a framework that provides them.

Keyed list reconciliation. For has no key prop and rebuilds all item nodes on every change to the tracked array. Focus and local DOM state inside list items are lost on update. See Control flow.
DevTools. There is no browser extension or inspector. useDebugValue logs to the console when globalThis.__CHROMA_DEBUG__ is set.
Error boundaries. Errors in effects, cleanups, reducers, and Provider children are caught and logged to the console, but you cannot catch them and render fallback UI. See Reactivity.

The WebAssembly boundary has a cost. Every DOM operation crosses from WebAssembly to JavaScript. Chroma optimizes for an engine that lives entirely in Rust, not for benchmark wins. See Architecture.
No direct .wasm import. Browsers do not ship ESM integration for WebAssembly, so the generated pkg/chroma.js loader is required.
Production builds need tooling. Development needs no build step, but chroma build needs Node.js (esbuild), and a dynamic build also needs wasm-pack on your PATH. See Prerequisites.
Mobile targets are not production-ready. Android and iOS builds are a preview and may change between releases. Use browser delivery or Chroma Desktop for production. Details: Desktop.

For skips items whose render function throws, without logging the error. Workaround: wrap the render function body in your own try/catch while debugging.