Dev ToolsRelease Marijn Haverbeke's new editor ditches ProseMirror's complex step model for a simpler, delta-based architecture.
[Mariana Souza](https://sourcefeed.dev/u/mariana_souza)
If you have built a collaborative document editor, a rich chat composer, or a custom CMS over the last decade, you have almost certainly crossed paths with [ProseMirror](https://prosemirror.net). It is the invisible engine powering some of the most prominent text inputs on the web, from ChatGPT and Gemini to massive enterprise platforms. Yet, for all its power, writing code to manipulate ProseMirror's document state has always felt like solving a Rubik's cube in the dark.
Now, Marijn Haverbeke, the creator of both ProseMirror and CodeMirror, has released Wordgard (version 0.1.0). It is not a minor update or a backward-compatible ProseMirror 2.0. Instead, it is a complete, greenfield rewrite designed to fix the architectural pain points that have frustrated developers for nine years. By borrowing state management concepts from the version 6 redesign of CodeMirror and combining them with a novel tree-validation model, Wordgard offers a radically simpler way to build complex, collaborative editors.
Why "Steps" Made Us Wince #
To understand why Wordgard is a big deal, we have to look at how ProseMirror handles document changes. In ProseMirror, every document modification is represented as a sequence of atomic "Steps." If you want to make two changes in a single transaction, you have to apply the first step, calculate how that step shifted the document's coordinate system, and then apply the second step relative to that new coordinate system.
If you want to figure out what range of the document actually changed, you have to iterate through the sequence of steps in both directions, mapping positions forward and backward. It is an incredibly complex mental model that makes writing custom transaction transforms or history plugins notoriously difficult. Even Haverbeke admits that some of these design choices now look like they were "dreamed up by the utterly deranged." Instead of trying to graft a new state model onto ProseMirror, which would have resulted in a compromised, backward-compatible mess, Haverbeke chose to start fresh. Wordgard is the result of that clean slate.
The Wordgard Way: Deltas, Tokens, and Fix-ups #
Wordgard replaces the step-based model with a much simpler, flatter change representation inspired by the "delta" format originally popularized by ShareJS.
In Wordgard, a change is represented as a single, flat sequence of sections. Each section does one of three things:
Keep: Preserves a specific span of the old document.** Replace**: Replaces a span of the old document with new content.** Update**: Preserves the structure of a span but adds or removes marks (like bolding, links, or image alt text).
For example, if you want to make a three-character word bold, Wordgard represents this as [keep 3] [update 3 +bold] [keep 4]
. Because every transaction is associated with a single, unified change set, reasoning about what changed in the document becomes trivial.
But rich text is not flat; it is a tree of nested nodes like paragraphs, lists, and tables. To bridge this gap, Wordgard uses a token-counting indexing system similar to ProseMirror's. It treats the document tree as a flat sequence of open-node, close-node, and leaf tokens.
This introduces a classic rich-text challenge: if you can arbitrarily splice tokens, you can easily generate invalid document trees (for example, by deleting a closing tag without deleting its opening counterpart). Wordgard solves this by running a validation pass during change-set creation. If a change would result in an invalid tree, the editor automatically derives a "fix-up change" to correct the structure.
This fix-up mechanism is particularly elegant when it comes to collaborative editing and operational transformation (OT). When merging concurrent edits from different users, Wordgard ensures that even when changes are transformed and applied out of order, the fix-up engine guarantees convergence. Applying transformed change A after B yields the exact same document structure as applying B after A, preventing the editor from falling out of sync.
The Developer Angle: To Switch or Not to Switch? #
If you are currently running a production application on ProseMirror, there is no need to panic. Haverbeke has made it clear that ProseMirror is not going anywhere and will continue to be maintained. There is also no automated upgrade path. Switching to Wordgard means rewriting your editor integration from scratch. If your current ProseMirror setup works, you should probably stick with it.
However, if you are starting a new project or struggling with the limitations of your current rich-text stack, Wordgard is highly worth evaluating. Here is how the practical trade-offs stack up:
The Pros
Sane State Manipulation: Writing custom plugins, undo histories, or collaborative sync engines is vastly easier because you are dealing with flat deltas rather than a chain of dependent steps.Custom Selection Layer: Wordgard foregoes the browser's native selection APIs to draw its own custom selection layer. This eliminates a massive class of cross-browser selection bugs and makes custom cursor behaviors much easier to implement.First-Class Collaboration: Multi-user syncing and conflict resolution are baked deeply into the core architecture, rather than feeling like an afterthought.
The Cons
Ecosystem Cold Start: ProseMirror has a massive ecosystem of plugins, wrappers, and community tools. Wordgard is at version 0.1.0; you will be writing a lot of your own UI components and extensions.No Code Sharing: Despite sharing architectural ideas with CodeMirror 6, Wordgard contains a significant amount of copy-pasted and modified code. Haverbeke opted against sharing packages to avoid "nightmarish amounts of type parameters and extra indirection."Opinionated Contribution Model: Wordgard is licensed under the permissive MIT license, but it is developed on a private Forgejo instance anddoes not accept pull requests. If you find a bug, you report it; if you want to contribute financially, there is a social expectation of commercial sponsorship, but the codebase remains firmly under Haverbeke's control.
A Promising New Direction #
Wordgard is a fascinating correction of the design mistakes that have plagued in-browser rich-text editing for years. By proving that we can have the structural safety of a schema-based tree editor with the programming simplicity of a flat delta format, it sets a new bar for editor architecture.
While it is too early for most production apps to migrate, Wordgard is the design pattern we will likely be copying for the next decade. If you are building a highly customized content-editing UI today, starting with Wordgard will save you from the architectural debt of yesterday's step-based models.
Sources & further reading #
Wordgard: The new in-browser rich-text editor from the creator of ProseMirror— wordgard.net - Wordgard: The new in-browser rich-text editor from the creator of ProseMirror | Hasty Briefs— hb.int2inf.com - Wordgard Release 0.1— marijnhaverbeke.nl - Wordgard: The new in-browser rich-text editor from the creator of ProseMirror | Apex Neural Systems— apexneuralnews.com -
[Nuxt HN | Wordgard: The new in-browser rich-text editor from the creator of ProseMirror](https://hn.nuxt.dev/item/48772573)— hn.nuxt.dev
[Mariana Souza](https://sourcefeed.dev/u/mariana_souza)· Senior Editor
Mariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon.
Discussion 0 #
No comments yet
Be the first to weigh in.