I mean this kind of thing continues to fuel my beliefs that software is going backwards here because frankly, how hard can it be to render some text?
It really depends. If the only thing you care about rendering is US ASCII with a monospace bitmapped font, that's not too hard.
However, a general purpose text renderer will have to handle things like directionality (left to right versus right to left text orientation), wide/half text rendering (for CJK characters), combining characters (for some European, South East Asian languages, and zalgo), line break rules (handling characters like soft hyphens and non breaking spaces), and so on.
On the font rendering side of things, there's kerning (some letters are closer to one another), font ligatures (certain fonts handle things like fi ffi fl ffl differently, not to mention things like hasklig), antialiasing, sub pixel rendering, and the fact that fonts are actually programs running on a stack based virtual machine [0].
That's also ignoring more advanced text rendering features like ruby characters and vertical text rendering. Or that apparently Turkish has different small caps than English ones [1].
In practice, it's probably not the text rendering that's the issue, it's probably just features that are implemented inefficiently.
[0] https://developer.apple.com/fonts/TrueType-Reference-Manual/...
[1] https://docs.microsoft.com/en-us/typography/opentype/spec/tt...
It's a fun meme to blame Electron for everything but the problems with Notion are obviously with its state and data management. Booting/rendering performance is not the bottleneck here, and having used lightning fast Electron apps, I'm sure it never will be.
Put differently: what measurements do you have of the performance issues of Notion and is Electron performance the root problem of them?
Compare it with the few MBs needed by an equivalent native app with exactly same functionality.
By any standard and by any metric, Electron is bloated. Some applications (like VSCode) can disguise it quite well and give a an acceptable user experience.
Text Rendering, CSS Layouts, Accessibility, being good at cross-platform, Canvas/WebGL and a myriad of other APIs make Electron pretty powerful. I don't know exactly, but I think QT would be it's main competitor when it comes to those features. But QT isn't always that easy to develop with.
Here you are complaining that a "hello world" uses a lot of memory. Yes, that's true, but the use case for Electron is not to display just "hello world", it's to build full, accessible applications in languages who are usually native on the web.
What counts is the final user experience.
There is a level of optimization where that is relevant and it's relevant in a bigger context of responsible resource usage but that's not what we're talking about here.
This was exactly my point as to the "memes" of Electron criticisms, your point is completely off topic but because someone mentioned "Notion" someone has to make your point nearly verbatim every time.
It does not add anything valuable to the discussion. Talking about caching strategies, offline/online functionality and layout thrashing is much, much more interesting here.
There’s also situations like German, where, until 2017, a single lower case letter could map to two upper-case letters (but they wouldn’t map back to that single lower-case letter):
toUpper(ß) == SS, toLower(S) == s, toLower(SS) == ss, toLower(toUpper(ß)) != ß
(Since 2017 that’s been fixed, although not adopted by every publication or software yet, by using ẞ. toUpper(ß) == ẞ, toLower(ẞ) == ß, toLower(toUpper(ß)) == ẞ)
I agree that Notion has big performance problems, and I myself left it for logseq a long time ago just because of the performance issues and the non-flexible architecture overall. But Notion's performance issues are not about rendering text, it's rendering everything but text.
Really makes me want a lightweight alternative because I love its editing model.