What Nabu doesn't do well (yet)

At the time of writing, opening a document of 10,000 blocks takes about 9 s in the lab, and the page does not answer while it loads (1,000 blocks: about 1.3 s). Typing in such a document was slow too (88 ms per key) and is fixed since 0.1.0: the browser skips what is off screen, and a key reaches the screen in about 13 ms at the median, 19 ms for the slow one in twenty (9 ms and 15 ms on a short page, on a busy machine). The load is next: the document is built block by block, and a single transaction is read several times by the extensions.

Android and iOS keyboards send their own input events (autocorrect, swipe, predictive text). Nabu has not been tuned on them yet.

Developed and tested in Chromium. The test suite does not run in Firefox or WebKit yet, so we cannot promise they behave.

The model is a CRDT and tabs already merge. A network transport between users is not shipped: you would bring your own.

No table block yet. It needs a block-selection primitive we have not built.

Extensions that rewrite the editable surface can fight with a single contenteditable. Not tested yet; spellcheck: false adds the opt-out hints Grammarly reads.

The document is a Loro CRDT, and Loro is a WebAssembly file: 1.2 MB gzipped (3.6 MB raw). Yjs, by comparison, is 28 KB. We have not measured the weight of Nabu’s own code separately.

Loro’s WebAssembly needs the nabu() plugin in your Vite config and an esnext build target. Without them, Nabu fails to load. Svelte 5.20 or later only.