alt Hacker NewsIt makes sense when the editor is a core feature of your paid product. I understand the sentiment.
But is not it strange that I would need 8 months & a "development is ongoing" mindset just to render Markdown (which is very secondary to the main app features, and mostly just a user convenience people expect in 2026) with a custom low-level solution, effectively playing hardcore engineer instead of building what I actually want to build?
Anyhow, my point is not that "it is impossible". My point in the article is that I understand why people choose web technologies over native for such things. They want to build products, not fight the system’s limitations.
Replies
You're assuming the text editor component alone took 8 months, but of course it did not! That would be crazy. There's a whole app built around the text component, which is what took my time, and the reason people are buying the app.
Development is ongoing for the features around the text component. I added folding lists which took a while, and because I offer outliner features I added focus/hoist which was also quite complicated.
Performance profiling and adjustments were measured and solved when I was almost done, because premature optimisation is a bad idea.
I don't consider what I did fighting any sort of limitations, so I guess it's a point-of-view thing. I wanted to use system components, and the only way to do that whilst maintaining performance is to do it with due care and attention. Nothing comes for free.
Not to turn this into an AI debate, but it will only take 8 months if you insist on coding manually.
I'm doing little video utility apps that I never would have attempted a year ago, because I know the challenges of AVFoundation all too well. But if I don't have to actually write that plumbing? Sure.
> just to render Markdown
Rendering text beyond ASCII is famously difficult to do; rendering formatted text is sometimes difficult to even make sense of (e.g. what should a style change in the middle of an Arabic word do? how about a selection boundary being moved with arrow keys?); rendering honest-to-goodness Markdown, which can technically include arbitrary HTML tags, is nowhere in the vicinity of a small project.
None of which is to say that you shouldn’t demand that a toolkit solve it for you, only that I understand why the RichEdit control reportedly had a separate team allocated to it in turn-of-the-millenium Microsoft. Working with a large amount of formatted text feels like it should be the most complicated feature of any UI toolkit and I shudder at the thought of even designing the API for it.
(A web browser is good at all this. It also has the API surface of a web browser.)
And some things will still be on you regardless. Did you know Android has two modes for text wrapping, one that won’t reflow the entire paragraph after a single-word change at the end and a different one whose results embarrass a typographer from half a millenium ago? That’s very much the correct way to do things, but if you’re streaming text in, it’s on you to decide whether you want subpar wrapping throughout or a layout jump whenever a paragraph break arrives. Most importantly, it’s on you to know the question exists; there are more, some more important than this one.
(Modern toolkits aren’t the only ones that can be bad at scaling to large amounts of data, either. Notably, Microsoft had to write an entire new “windowless” one to replace USER’s heavyweight window-based one so that Access wouldn’t collapse under its own weight. They then reused it for IE, for similar reasons. Raymond Chen’s response[1] to complaints about that toolkit staying private to Microsoft amounted to “fuck off”.)
[1] https://devblogs.microsoft.com/oldnewthing/20050211-00/?p=36...