A browser-based design tool must render complex documents at sixty frames per second while several people edit simultaneously. What does that force in the client architecture?

What the frame budget forces

Sixty frames per second is a 16-millisecond budget per frame for everything: input handling, document mutation, layout, and paint. That budget rules out several defaults of mainstream web application architecture.

• A DOM node per document element does not work. Thousands of elements with independent styles and layout exceeds the budget on its own. Rendering goes to canvas or WebGL, with the browser's layout engine bypassed entirely.
• The document model lives in memory, not in the framework's state. A general-purpose reactive state library re-rendering on every keystroke or drag is far too slow — mutations must be applied to a purpose-built in-memory structure and painted directly.
• The hot path is compiled. Geometry, layout and rendering computations are where a compiled target compensates for interpreted execution; the surrounding application shell does not need it and should not pay its complexity.
• Rendering is decoupled from input. Input is captured immediately and rendering happens on the frame cycle, so a slow frame delays what the user sees rather than dropping what they did.

What multiplayer adds

Concurrent editing requires a merge strategy that converges without a server round-trip on every keystroke. The two families are operational transformation and conflict-free replicated data types, and the choice is driven by the document model rather than by preference.

The property that matters more than the algorithm: local edits apply immediately and remote edits merge without the user's work jumping. A technically correct merge that relocates the object someone is dragging is a defect regardless of its convergence proof.

The architectural line to draw

Separate the document engine from the application shell. The engine is performance-critical, hard to change, and carries the merge semantics. The shell — panels, menus, settings, sharing — is ordinary application code that benefits from ordinary tooling. Conflating them makes the whole product as hard to change as its hardest part.