Rust + WebAssembly
Shared document semantics
Rust owns commands, validation, anchors and history. WebAssembly brings that engine to the browser, with a thin adapter for DOM rendering and platform input.
edit.ac · Open source · SDK in development
Build editing into your product.
A Rust-powered document engine, WebAssembly for the browser, and an architecture designed for responsive editing and collaboration. Embed the experience your product needs.
The architecture
Less work on every keystroke. More room for your product.
Task descriptions, comments, notes and longer documents share the same demands: responsive input, dependable saves and content that can grow. edit.ac is designed around those demands, from the document store to the rendering boundary.
Incremental editing
Update the affected range
Compact patches let adapters update changed content. The design keeps whole-document serialization and framework rerenders out of ordinary editing.
Local-first foundation
Keep the document close
One Yrs-backed collaborative state underpins local editing, recovery and synchronization. Offline work and collaboration use the same document model.
Optional modules
Choose your editing footprint
The architecture separates the core from menus, tables, math and other extensions, so each product can choose the capabilities it needs.
Designed for performance
A short path from input to visible change
Each edit has a focused job. The engine and its adapters are designed to bound that work as the document grows.
-
Prepare one semantic edit
Resolve the affected range and validate the command before changing the collaborative store. Keep expensive parsing outside the mutation phase.
-
Patch what changed
Commit the edit, emit a compact patch and update the affected DOM or native spans. Scoped subscriptions keep application updates focused.
-
Queue persistence and sync
Send update bytes to storage and synchronization adapters. Ordinary typing should not wait for a network request or a full document export.
One engine, platform input
Rust at the center. WebAssembly at the browser boundary.
The shared engine keeps document rules consistent while each adapter handles its platform's input, selection and rendering. This is the direction for the SDK; platform availability follows qualified releases.
A thin browser layer
The browser design pairs a WebAssembly engine with a framework-independent adapter and a thin React wrapper. Native browser input and composition remain part of the editing experience.
Native controls, shared rules
The original brief calls for iOS and Android adapters using native text controls without a WebView. Native SDKs remain planned, with platform qualification tracked separately.
Headless and agent workflows
The headless engine provides a foundation for nonvisual consumers. The agent contract lets applications prepare and inspect proposed changes before applying them.
Keep local work
Collaboration starts with a durable document
The local-first design carries edits through saves, restarts and reconnects. Your application owns storage and transport; the engine supplies the shared document semantics.
Recover local edits
An update journal and checkpoints form the recovery path. Unsynced updates are retained, and persistence failures are explicit in the host contract.
Reconnect with shared state
Yrs-backed state and a version-pinned Yjs interoperability contract give collaboration a common foundation. Stable anchors identify positions as concurrent edits arrive.
Use your own services
Connect persistence and sync through host adapters. The hosting guide describes application responsibilities for identity, authorization, storage and remote commits.
Content that fits your product
Start with everyday writing. Extend where it matters.
The design brings Markdown and structured content into the shared engine, with optional extensions for richer interactions. Explore their contracts as you plan your integration.
Markdown in the engine
A shared Rust parser and serializer are planned for formatted paste, typing shortcuts and explicit literal paste, with a documented CommonMark/GFM profile.
Portable extensions
Typed nodes, marks and commands pair with platform rendering hooks. Planned modules include slash commands, mentions, block reorder and math.
Understand format fidelity
Import and export have separate contracts. Check supported directions, conversion reports and fidelity limits when planning how content moves into or out of your product.
Plan an editor migration
Choose your integration surface and check the compatibility boundaries. The migration path must account for document schemas, extension behavior and stored content.
Measure the whole experience
Performance claims need more than a small JavaScript wrapper
The brief sets engineering targets for the complete editing experience. Those targets guide development; they are not published benchmark results or claims of superiority over other editors.
Count the full download
Measure JavaScript, WASM and essential CSS together, including decompression, compilation and document restoration. Optional modules have their own costs.
Time actual editability
Separate a fast first viewport from the first accepted edit. Track cold and warm starts, typing latency, Markdown paste and long-document activation.
Compare equal capabilities
Use reproducible documents and optimized baselines with equivalent collaboration and persistence. Track tail latency, memory and repeated mount/edit/destroy cycles.
Explore the SDK
Find the path into your application
Start with the integration contracts, then follow the development evidence for the capabilities your product needs.
Choose your integration
Understand the web, native and terminal surfaces, lifecycle and services your application owns.
Design local storage
Plan save, recovery and reconnect behavior before adding collaboration.
Connect agent editing
Prepare and inspect document changes through your application's MCP, then apply them with a stable request identity.
Shape the editor
Explore extension contracts for content, commands and the UI your product needs.
Build with the architecture. Follow the release.
edit.ac is open source under Apache-2.0 and the SDK is in development. There is no qualified public editor release yet. Installation tutorials and a public playground will follow release qualification; the docs are ready for planning your integration.