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...
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.
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(ß)) == ẞ)
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.
Really makes me want a lightweight alternative because I love its editing model.
edit: To clarify, using they mobile app will require paid subscription in all scenarios, I think (not sure, as I don't need that).
Nope. They've said they'll support opening a folder on a phone. Therefore, as long as you sync the folder using some cloud software, the mobile app will work just fine.
But of course, you can pay them for the convenience and they'll sync them for you.
You can try the "Focalboard Personal Desktop" to run locally where your performance won't be affected by other users.
We made it available in Windows Store and Apple AppStore to make it easy to try out.
This is just a v0.6 right now, and we would love bug reports and enhancement ideas.
It's the early days of the project and we are excited to hear input: https://github.com/mattermost/focalboard/issues
I would prefer a simple non-store app, a portable app perhaps. Can I get a classic zip/whatever?