Fine, I'll build my own text editor
TL;DR
David Bushell prototypes a browser code editor three ways. Canvas rendering leaves screen readers with nothing. Contenteditable slows down on long files. A plain textarea with a highlighting layer on top is the most workable base.
The article
- Bushell starts by drawing everything on a canvas. He gets cursor placement, arrow keys, typing and a current-line highlight working. Canvas provides nothing else for free: selection, undo, multi-line paste and scrolling all need building by hand. Screen readers can't see the text at all.
- To avoid writing custom scrollbars he puts a hidden native-scrolling div over the canvas and uses its scroll position to offset the drawing.
- He then switches to a div with contenteditable="plaintext-only", which brings native selection, undo history and accessibility. Spellcheck, autocorrect and similar attributes have to be off, because they cause input latency spikes. Finding that fix took him days.
- Contenteditable slowed down unpredictably past a certain character count. It was worse in Chromium than in WebKit. A plain textarea handled long text much better. The cost is a third DOM layer for syntax highlighting, since textarea can't use CSS custom highlights.
- Next steps he lists include Tree-sitter highlighting of only the visible lines and virtualised scrolling. Readers pointed him to the OpaqueRange API (custom highlights in a textarea) and EditContext (better canvas input).
- He ends on UTF-16 pitfalls. One lime emoji has a JavaScript length of 5. Spread into an array, it gives 3 code points. Only Intl.Segmenter counts it as 1 grapheme.
Why it matters
For anyone weighing canvas, contenteditable or textarea as the base of a web editor. The post has live interactive demos of each stage, plus the exact attribute list that removed his input lag.
The discussion
The thread was friendly to the post but spent little time on its technical details. Most of it argued over whether anyone should write an editor at all, whether existing editors are fast, and Emacs versus VS Code. Two big tangents were a fight about why Go exists, set off by a Rob Pike anecdote, and meta-talk about HN downvotes.
Rite of passage or wasted effort
Many saw writing an editor as something every programmer does once. At Caltech around 1980, tzs recalled, Rob Pike dismissed an editor race as "easy to do and makes them feel important", then wrote his own. Defenders said a personal editor can stay tiny because it only needs features its one user wants. Others, led by anon291, called it not-invented-here syndrome and said to build on Emacs or Vim, but had no clean answer to which.
it's surprising how little code you can get away with when it's your own and the (many) bugs left in it at any point are the ones that don't annoy you enough for you to spend time on.
If you want to make a great editor, the proper thing to do is start from a good base. Start from emacs and make something like doom emacs or spacemacs, etc.
Is text editing solved if editors still lag?
Against the "solved problem" claim, rfgplk said most editors show input lag past about 10 kB and fall apart on multi-megabyte files. self_awareness agreed the speed once existed and was lost, citing CygnusEd on the Amiga 500. tmtvl blamed whole-file parsing for syntax highlighting and said Emacs handles huge files fine in fundamental mode. kqp argued that inefficiency compounds, so slow software never catches up with hardware.
For editing buffers >1MB, 99% of them are unusable due to a) writes taking SECONDS (how?) b) scrolling/using the buffer physically lagging out the editor itself.
Inefficiency isn’t a constant, it’s a percentage. You look at software that’s 10x as fast and say yours will run that well in 20 years, and it does, but by then the other guy is 100x as fast
The browser as a base for an editor
Several found the textarea result unsurprising and said a real editor belongs outside the browser, where custom drawing is easier. Isofarro noted that Marijn Haverbeke took the same canvas, contenteditable, DOM path in 2011 and went on to write CodeMirror. Others suggested CodeMirror 6, though one user found its docs hard to follow. Readers also reported the canvas demos drawing the cursor a line below the text in Safari and Firefox.
Yes, who would have guessed that the <textarea> element, designed specifically for this use case and built into browsers for 3 decades, would be the most performant and behaviorally consistent way to implement editable text.
the Web is probably the most limited platform today to build custom text editor, in terms of text layout, interaction and all the small bits that may matter.
Emacs against VS Code
Emacs users said it already does what newer editors offer; iLemming called it a text orchestrator wiring the browser, OCR and LLM agents together. VS Code defenders pointed to good defaults, easy setup, and devtools for anyone already working on the web. bigstrat2003 measured VS Code at over 1 GB against Sublime's 200-300 MB. But golf1052 opened a 730 MB file and found Sublime using more.
Emacs has a similar problem to Lisp: Infinite configurability and expandability (plus the lack of a "blessed set" standard that people actually like enough to use out-of-the-box) means that everyone's environment and tooling ends up becoming incompatible with each other.
Emacs is not "easy", it is "simple", it pays off only after months of investment, and the ROI from it can be immeasurably bigger in ways that you might have not realized before it.
Editors written by LLMs
stillpointlab had an LLM wrap KDE's KTextEditor in Rust, with a few LSP features, in two days without reading any of the code. boxed shared an IDE Claude wrote for him that is now his daily editor. Skeptics asked what the point was when editors on the same library already exist. Others called it burning tokens to recreate something available a thousand times over.
So I just said "do it" and have been merging everything without reading a single line. It wrote all the specs, wrote all the code, wrote all the tests.
I don't understand why you'd want to get an LLM to wrap up a text-editing library in what sounds like a pretty straightforward way, when there are already text editors using that library.
Consensus
Building a basic editor is easy and a good way to learn. Making a good one takes years of edge cases, and Unicode, input handling and performance on large files are where the work goes.
Dissent
A vocal minority said text editing is a solved problem and that new editors are ego projects that should build on Emacs or Vim instead. Others said a browser was the wrong place to start.