Comment by jfim | Hacker News Reader

Comment by jfim | Hacker News Reader

Parent Full thread

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

"how hard can it be to render some text" as the previous author is a valid complaint, if Notion only rendered text but they do not. There is a lot of data structures around what looks like "just text", including images and everything else.

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.

Not just small caps – turkish has different case mapping for iİ ıI vs the ascii mapping iI.

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(ß)) == ẞ)

All of this can be done quite efficiently on a native widget. The problem with Notion is that it uses Electron.

Which makes rendering text extremely simple.

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?

Let’s just say that the fact that Electron needs to allocate hundreds of MB in memory to display a single “Hello world” text does not depose in Electron’s favor.

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.

I've been Obsidian since a few weeks and it's the most fastest Electron app I've ever used. It's so snappy, it feels like a native app. So, yes I agree with parent comment, Notion is slow and sluggish but Electron is not the one to blame here. The web version is pretty slow as well.

Yes! Good point, web Notion is exactly as slow because the problems aren't the engine.

Maybe that's because Electron isn't made to just display a single line of text?

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.

For what is worth Electron could solve all the problem in the worlds. My point is that in order to display rich text, images and basic UI elements (what Notion and for instance Slack need) it requires an abysmal amount of memory with respect to a native implementation.

Your complaint is basically saying "Hey, I don't need this professional workstation just to run Notepad, what is going on in the world?!" while professional workstations are not for running just Notepad, they are for doing a lot more things than that.

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.

No, my complaint is: I am very annoyed that this professional workstation runs Notepad ten times slower than my old 486.

What counts is the final user experience.

Apart from the notion (heh) that we should compare a hello world app to determine real world performance, memory usage is really not that relevant to the discussion of speed, responsiveness etc.

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.

Reply on news.ycombinator.com