Lord.io

https://lord.io/spreadsheets/ is one of my favorite technical blog posts of all time. Highly recommend everyone check it out!

Oh, that's me! Feel free to ask me any questions. There's some great discussion over on lobste.rs (https://lobste.rs/s/2zk3oe/pushing_pulling_three_reactivity), but I particularly recommend this link that someone posted there to a post that covers much of the same topic but in a lot more detail with reference to various existing libraries and tools and how they do things: https://lord.io/spreadsheets/

> 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/

> 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…

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…

hard is this: https://faultlore.com/blah/text-hates-you/ and this: https://lord.io/text-editing-hates-you-too/ those are both things most ImGUIs ignore. And, even if you pick some library that somehow handles the first you're left with all of the issue mentioned above. To be clear, if I was writing a devtool (and I am actually) i'd reach for an ImGUI (and I did). But I'd be unlikely to use one for user facing tool.

> Few more additional ones, more about editing than just rendering Right after TFA was published, someone put together the text editing version: Text editing hates you too: https://lord.io/text-editing-hates-you-too/

See also: Text Rendering Hates You https://faultlore.com/blah/text-hates-you/ and Text Editing Hates You Too https://lord.io/text-editing-hates-you-too/

Can we please stop with abusing ligatures for things like != into ≠? If you want APL, please use APL and leave the rest of us alone. != is two bloody characters not one. And now people are doing it for 3 characters. With this kind of thing, you get all the text editing idiocy of combining characters (like emojis) for no benefit at all. See: Text Editing Hates You Too https://lord.io/text-editing-hates-you-too/

It’s not a spec, but I like “Text editing hates you too” [1] and the article that inspired it, “text rendering hates you” [2]. Also Apple’s old documentation about how their text layout system works. That link is annoying to find so I don’t have it on hand. [1]: https://lord.io/text-editing-hates-you-too/ [2]: https://faultlore.com/blah/text-hates-you/

Text alone is already a painful domain [1][2] and text is just a small subset of the full UI domain. -- [1] https://gankra.github.io/blah/text-hates-you/ [2] https://lord.io/text-editing-hates-you-too/

Do you mean this [1]? It links to the referenced article too. [1] https://lord.io/text-editing-hates-you-too/

Related reading: https://lord.io/text-editing-hates-you-too/ However, I do think Drew has missed some necessary nuance here; especially with <select>, which is painfully limited. There are situations where a decently-implemented custom control will work better than a native control, even when it necessarily misses some of the nuance the native control would have had.

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/

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…

This post is pretty good: https://lord.io/spreadsheets/