Rich text with Rust + WebAssembly

Concepts that appear when the document core lives in Rust and ships as WASM, while the browser still owns IME, selection, and much of input—plus the JS↔WASM boundary cost model.

Overview

Moving the editor “brain” to Rust does not remove browser editing quirks: composition, clipboard normalization, selection APIs, and undo interaction remain host concerns unless you replace the surface entirely (e.g. canvas with a custom input stack—then you inherit different costs).

These pages focus on architecture and boundaries: where editing happens, how IME relates to your Rust model, how data crosses the JS↔WASM line, and how collaboration layers (CRDT) often sit next to WASM modules.

For language-agnostic editor design (schema, transactions, HTML mapping), use Editor . Here we assume a Rust core + browser host.

Why a whole section?

  • Editing model choices (DOM vs canvas vs hybrid) change who implements caret, IME, and accessibility.
  • IME is not “implemented in Rust” in the browser: you integrate with composition events and reconcile to your model.
  • FFI: every keystroke or paste can accidentally copy whole documents across the boundary—design matters as much as algorithms.
  • Collaboration often uses Rust CRDT crates with WASM bindings while the visible editor remains JS-hosted.

How this fits the rest of the site

Scenarios and Cases document real browser behavior (IME, paste, selection). WASM teams hit the same phenomena; these guides explain how they connect to a Rust core.

Guides