Building a Text Editor for the Web: Canvas vs. contenteditable vs. textarea

Frustrated by the decline of hand-crafted software like Sublime Text, developer David Bushell set out to prototype a browser-based code editor and documented the trade-offs of three rendering strategies. He started with a

to the text and mapped its scroll position onto canvas render offsets, but the accessibility dead end pushed him to abandon the approach.

His second attempt rendered text natively in a contenteditable=“plaintext-only” div, which hands over selection, undo/redo, and screen-reader support directly from the browser. The catch: input latency forced him to disable spellcheck, autocorrect, and autocapitalize (a fix that reportedly took days to find), and performance degraded unpredictably past a certain character count, with Chromium faring worse than WebKit or Firefox. A plain turned out to be far more performant for long documents, though it can’t use CSS Custom Highlights, so syntax highlighting required a third overlay layer. Commenters pointed him toward newer browser APIs — OpaqueRange for textarea highlights and EditContext for canvas input — as emerging fixes.

The piece is a candid look at how much invisible machinery a text editor actually needs, and why the browser’s built-in editing primitives, for all their quirks, are hard to beat. Bushell notes the deeper trap of doing this correctly: JavaScript strings operate on UTF-16 code units, so naive length and range math breaks on emoji and grapheme clusters — the string ”🍋🟩” reports a length of 5, three code points, but a single grapheme via Intl.Segmenter. He’s shelving the project as a proof of concept: roughly 90% of an editor with 1% of the features.