Lord.io is the personal blog of a programmer writing on text editing, spreadsheet recalculation, Rust and WebAssembly, and reactivity.
HN commenters call the spreadsheet post one of their favorite technical posts, and cite the text editing post as proof that some problems are complex.
> It goes both ways. I certainly hate un-needed complexity but somethings are just complex. Good examples are font rendering https://gankra.github.io/blah/text-hates-you/ and text input https://lord.io/text-editing-hates-you-too/ You think it's going to be easy. It's not. It just isn't.
This reminds me of a talk by Venkat Subramaniam, called "Don't Walk Away from Complexity, Run", here's a recording of it: https://youtu.be/4MEKu2TcEHM?t=343
In it he talked about inherent complexity and accidental complexity, the former being a part of the domain that you're working in, while the latter is introduced accidentally and isn't actually necessary to address the problem at hand.
Often people talk about managing and decreasing the accidental complexity, but what if instead you could reduce the inherent complexity by just trying to do less? For example, instead of trying to do advanced font rendering for almost every single language and writing style known to man, why not just limit yourself to ASCII, left to right typing and monospaced bitmap fonts in certain devices? I'd argue that in many cases, such as embedded devices, that's all that's actually worth doing, though seeking out ways to not drown yourself in complexity due to having limited resources to get stuff done applies elsewhere as well.
As someone else pointed out, a light switch would suffice nicely, instead of trying to write software to handle every possible use case for smart lights. Alternatively, just have an API…
I have been thinking about building an open-source RPI Pico-based E-Ink writer for a long time. I was primarily motivated by my opinion that the Freewrite seems way more expensive than its components should cost. I also didn't like the industrial/mechanical design, and I didn't like a lot of the choices made by the company (cloud storage). I wanted a little more flexibility, such as being able to use my own keyboard. I haven't started a GitHub project page and unfortunately, I don't think I have the capability of pulling this off as a single hardware/firmware developer, so I'm putting my ideas into the ether so that maybe someone picks this up and brings it into a reality.
The webcomic "The Guy I Almost Was" put me down this path twenty plus years ago. There's a part of the story where the author daydreams about buying a typewriter at a garage sale - the same one William Gibson used to write Neuromancer - to pursue his own fantasy of becoming a beatnik novelist after nearly becoming broke, homeless, and rejected for not having the latest Apple Newton. https://www.electricsheepcomix.com/almostguy/
Writing and editing became a large part of my career in technology, but I've felt I never developed the habits of a 'good' writer and am distracted like everyone else by the Internet at my desk and my cellphone everywhere else. Several writers have talked about using old word processors to write their novels and I thought I could be one of these people. Back in 2016 my iPhone 5…
What's frustrating is people who think that they can radically simplify something without knowing anything about it. The same people think they can implement a text editor in 1000 lines of code because that's how the first text editors were made. Why can't we go back to those simple days?
We can't because modern software handles cases that those didn't. For example, rendering and editing text seems straightforward until you look closer. Text Rendering Hates You (https://gankra.github.io/blah/text-hates-you/) and Text Editing Hates You Too (https://lord.io/blog/2019/text-editing-hates-you-too/) are two amazing reads that analyze this in detail. They explain the hidden complexity to the vast majority of us who never knew. We simply slapped down a <textarea> or <EditText> and called it a day.
If we tried to reimplement this stuff from scratch, we would likely start with a simple implementation, then tack on bits when we tried to handle issues like right-to-left layouts, Unicode, emoji, anti-aliasing, text overlapping and so on. All this before getting into implementing features that Dennis Ritchie didn't have to, like supporting plugins, releasing on multiple operating systems, accessibility or even syntax highlighting. Problems already known to and tackled by existing text editors today.
If you look at work outside of your area of expertise and you feel like starting a sentence like "why don't you just ...", then reconsider. If the person you're talking to is halfway…
Lots of reasons.
Font rendering for all of unicode is extremely hard.
https://gankra.github.io/blah/text-hates-you/
Multi-language input is extremely hard
https://lord.io/blog/2019/text-editing-hates-you-too/
Having to download an extra meg or 10 of code does not make your website responsive to start, worse if you're updating it constantly so you're users have to re-download that code every few days, hours.
Support for assistive technologies disappears. A page of HTML is relatively easy to scan for text to read or turn to brail or translate to another language. A screen (not a page) of pixels is not.
Similarly extensions all break. Extensions work because there is a known structure to the page (HTML)
UI consistency disappears. Of course pages already have this issue but it will be much much worse if every site rolls it's own pixel rendering GUI because none of the standard keys will work. Ctrl/Cmd-Z for undo Ctrl/Cmd-A for select all? Similarly maybe the user has changed those keys or is using some other assistive device which all works because things are standardized.
Letting the browser handle what's best for the device probably disappears. Cleartype for fonts? Rendering Text or SVG at the user's resolution (yes that can be handled by the page but will it? up to the site)
Password managers break including the browser's built in one. There's no text field to find so no way to know if this is the place to fill them in.
Spell checking breaks. Same as…
> Instead of trying to decide whether a GUI toolkit is native or not, I recommend asking a set of more precise questions:
>
> * Does text look like the platform native text?
>
> * To what extent does the app support preferences set at the system level?
>
> * What subset of expected text control functionality is provided?
>
> * Complex text rendering including BiDi
>
> * Support for keyboard layouts including “dead key” for alphabetic scripts
>
> * Keyboard shortcuts according to platform human interface guidelines
>
> * Input Method Editor
>
> * Color emoji rendering and use of platform emoji picker
>
> * Copy-paste (clipboard)
>
> * Drag and drop
>
> * Spelling and grammar correction
>
> * Accessibility (including reading the text aloud)
>
> If a toolkit does well on all these axes, then I don’t think it much matters it’s built with “native” technology; that’s basically internal details. That said, it’s also very hard to hit all these points if there is a huge stack of non-native abstractions in the way.
This is it! Browsers handle all of this. It's a ton of work. Many many gui kits start with just ASCII and really don't realize how deep the rabbit hole is for making all of this work.
And as always, if you haven't read them
https://gankra.github.io/blah/text-hates-you/
https://lord.io/text-editing-hates-you-too/
If your framework has a broad audience, please make sure it accounts for the full complexity of text rendering [1] and editing [2], particularly when it comes to internationalization. You may find that there are good reasons for Cocoa to be as slow as it is in the measurement phase, if not the rendering phase. And of course, please don't forget about accessibility.
[1]: https://gankra.github.io/blah/text-hates-you/
[2]: https://lord.io/blog/2019/text-editing-hates-you-too/