DOMD: a Markdown-native WYSIWYG editor for React, built for AI streaming

The problem DOMD targets: Markdown that has to survive streaming and scale

Most Markdown editors treat the rendered view as the working surface and the Markdown text as an export format. DOMD inverts that. The README states that WYSIWYG editing happens directly on Markdown, and that the Markdown document itself is the editing source of truth. That single decision is what the rest of the design hangs on.

The audience is narrower than "anyone who writes Markdown". DOMD is for React developers embedding an editor into a product, and for users who hit two specific walls: documents large enough to make a conventional editor stutter, and AI output that arrives token by token. The README claims smooth editing and streaming through 20,000-line Markdown documents, and states that open fences, half-built tables and partial lists render correctly mid-stream, then absorb their real terminators without flicker. Those are the two claims worth evaluating against your own workload.

There is also a multi-device angle. The kernel supports conflict-free merging within a paragraph rather than treating each paragraph as a single last-write-wins value, so two devices editing different parts of the same paragraph offline can both keep their changes. The README is explicit that offline state exchange and real-time synchronization share the same CRDT foundation but can be adopted independently.

How the kernel works: a Markdown-native engine with an operation stream

The README is direct about what DOMD is not: the kernel is not built on ProseMirror, Slate, Lexical or any general-purpose rich-text framework. Parsing, rendering, editing, undo/redo, streaming AI injection and chunked file loading are all modeled as deterministic state changes inside the kernel. Rendering happens only where changes occur.

The size claim follows from that. The core is described as 30+ KB after Brotli compression, with only React and Immer as runtime dependencies. For a React app where bundle budget is a real constraint, that number is the headline.

For synchronization, the architecture is an adapter rather than a rewrite. The kernel itself is CRDT-agnostic. It emits a structured operation stream for ordinary edits, and an optional CRDT plugin observes that stream, translates each change into transactions on nested Yjs shared types, and maintains a mergeable Y.Doc replica. Because the boundary is an adapter around the operation stream, the README states that product and interaction code does not need to be rebuilt around Yjs; a completed editor feature can opt in by attaching the plugin.

The kernel exposes three integration points for the real-time path: subscribeRenderDataOps emits local editing operations, applyExternalRenderDataOps incrementally applies remote operations, and cursor snapshots and subscriptions expose presence data. An optional realtime-sync adapter translates between these APIs and nested Yjs shared types. Incoming changes are replayed only onto the affected nodes instead of replacing the document, which is what preserves localized rendering during live editing.

Inline syntax is the other first-class extension point. Parameters follow the Pandoc and Djot inline-attribute family. Delimiters carry no meaning of their own: a .word selects a variant, a semantic type registered as plain data, and the same variant can attach to whichever delimiters fit your product. Unregistered types do not error; they degrade into plain CSS hooks. A variant can also bind a React component, which receives the parsed parameters and children and renders inside the live document.

Installing DOMD and a first real use

The repository is a Next.js application with a Tauri desktop shell, not a single npm package you install and run. The README points to two entry points: the hosted web editor at https://www.domd.app/editor, and macOS builds published on the releases page as DOMD_aarch64.dmg for Apple Silicon and DOMD_x86_64.dmg for Intel. If you only want to use the editor, download the appropriate disk image; there is no documented Homebrew formula or package-manager install in the README.

If you want to work on the application itself, the top-level package.json defines the scripts. Clone the repository, then run the development server:

npm install
npm run dev

npm run dev maps to next dev, so you should see the Next.js development server start and the application served locally. The other scripts in package.json are npm run build (next build), npm run start (next start) and npm run lint (eslint). There is also an analyze script that runs next experimental-analyze and then serves the generated report over a local Python HTTP server on port 3000, which is how the maintainers inspect bundle composition.

For embedding the kernel rather than running the app, the README names the package @do-md/core-react and links its npm page. The README does not reproduce an import example, so check the package page and the demos it links before writing integration code. What the README does give is the inline-syntax grammar, which is the part most likely to shape your data model:

==highlight==                              plain highlight
=={red}highlight==                         tinted — a positional parameter
=={.comment author="Alice"}highlight==     a semantic type with attributes

The README notes that the same variant can be attached to different delimiters, for example =={.mention id=1}Alice== and <{.mention id=1}Alice> are equivalent. If you plan to bind a variant to a React component, that attribute such as id can act as a stable reference to an object in your product, which is how a small piece of Markdown becomes interactive UI.

Where DOMD is the wrong tool

The from-scratch decision cuts both ways. Because the kernel is not built on ProseMirror, Slate or Lexical, it does not inherit their plugin ecosystems, their community extensions, or the accumulated edge-case handling of editors that have been in production for years. If your product needs a mature rich-text feature set with third-party plugins, DOMD is the wrong starting point. The README frames the kernel as something you embed in editors, inputs, collaborative workspaces and AI interfaces; it does not present it as a general-purpose rich-text framework.

The CRDT story has a similar boundary. The kernel is CRDT-agnostic and the synchronization layer is optional, which is good for adoption but means the merge behaviour you get depends on attaching the plugin and on Yjs. The README does not document conflict resolution policy beyond the statement that concurrent changes converge through Yjs, and it does not document rollback. If your requirements include a specific, auditable merge policy, that is something to verify rather than assume.

Finally, consider the packaging. The repository is a private Next.js and Tauri application, so adopting DOMD means either embedding @do-md/core-react or shipping inside a similar stack. The macOS builds are the product; a Linux or Windows desktop build is not mentioned in the README. The README also does not state what happens to documents already written in flavours of Markdown that rely on raw HTML or on parser extensions outside the Pandoc-style attribute family.

DOMD versus ProseMirror, Slate and Lexical

The honest comparison is not feature against feature, it is source of truth against source of truth. ProseMirror, Slate and Lexical model a rich-text document and treat Markdown as a serialization concern. DOMD models Markdown itself as the editing source of truth, which is why the README can claim that parsing, rendering, editing and undo/redo are all deterministic state changes inside one kernel.

The practical difference shows up in three places. First, round-tripping: if Markdown is the document, there is no lossy conversion step between what the user sees and what is stored. Second, streaming: the kernel ingests token streams chunk by chunk and renders them live, handling open fences and half-built tables mid-stream, which is a problem those frameworks leave to the application layer. Third, size: a 30+ KB Brotli core with React and Immer as the only runtime dependencies is a different budget from a general rich-text framework plus a Markdown serializer plus a streaming adapter.

The cost of that trade is ecosystem. A ProseMirror-based editor gives you a decade of extensions and a hiring pool that already knows the API. DOMD gives you a smaller surface and a kernel whose extension point is inline variants bound to React components. If your inline needs are highlights, mentions, comments and wikilinks, the variant system covers them without forking a parser. If your needs are broader, you are writing the extensions yourself.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent and recent: v0.8.1 and v0.8.0 both on 2026-08-30, and v0.7.1 on 2026-08-27. Note that the top-level package.json declares version 0.9.1 while the latest listed release is v0.8.1, so the application and the published release tags are not moving in lockstep. If you pin to a release, check which kernel version it bundles.

Upgrade cost is concentrated in the extension API. The README introduces inline syntax as a first-class extension point in @do-md/core-react 0.6, and the variant grammar is described as following the Pandoc and Djot inline-attribute family. That convention is stable in the wider Markdown world, which lowers the risk of churn, but any product code that binds variants to React components depends on the parsed parameters and the render contract. A change there is a change in your code.

The licence needs attention before you plan anything. The repository licence is reported as NOASSERTION, which means the file could not be classified automatically, while the package.json in the repository declares "license": "MIT". Those two signals disagree. Read the LICENSE file at the repository root and, for the published @do-md/core-react package, the licence field on its npm page. This is a factual discrepancy to resolve, not a legal opinion; if the terms matter to your organisation, have someone who can read them confirm which applies to the package you actually ship.

Editorial conclusion

Adopt DOMD if you need a Markdown-first editor embedded in a React product, especially when AI streaming or very large documents are the hard part. Do not adopt it if you need a general-purpose rich-text framework with a large plugin ecosystem, because the kernel is from scratch and not built on ProseMirror, Slate or Lexical. Before committing, verify the licence situation: package.json declares MIT while the repository licence is reported as NOASSERTION, and confirm the inline-variant API against the version you install.

Frequently asked questions

Official sources

1. do-md/domd on GitHub
2. Issues
3. Project website
4. README
5. Releases