While IDLE, the gmail tab uses 10-30% of an M1 CPU core.

That stuff is not down to tracking - it's because the damn thing keeps messing with the DOM, because it has some insane structure where javascript controllers are attached as strings to DOM elements, because it uses about 100 divs to render every row in the list of messages, and because every message is nested literally 15-30 layers deep in a pointless tree of divs.

I am sorry, but web frontend is an insane dumpster fire.

I’m not arguing for using hundreds of divs, because that’s a sign of engineering insanity imo, but it’s not a performance issue. You can create a static page with thousands of them and (likely) see that it still doesn’t use 250Mb+ neither idles at 30% cpu core.

Added:

damn thing keeps messing with the DOM … web frontend is an insane dumpster fire.

Totally agree with these parts.

—————

… I just tested 50 div-rows with 200 spans containing numbers from 1 to 199. Total 10k elements, text doesn’t fit on the screen. Bootstrap css+js is imported via CDN.

Mithril.js implementation uses 50Mb of RAM consistently.

A static page with the exact same content uses 71-96Mb depending on the run.

Both use 5-14% cpu when I shake my mouse and 0% when I don’t.

Refresh is significantly faster with Mithril, idk why, probably because static html parser is slow. (Opera, Windows 10, no extensions).

With a single span per row instead of 200 both take 23Mb.

Removing bootstrap from the head inconsistently frees 0-2Mb for both.

I do have a lot of emails, but I think it should only have to worry about 100 of them at a time, so I don’t know why it’s different for me and you. It is possible that my account still receives beta features, because I used to work there, but I remember it being like this for multiple years, since the new gmail came out.

I have very clean mailbox, though.

From what I understand (no special insider information) React is essentially non-existent inside of Google, and NPM is not even available to engineers (be default)

You have to remember that a large chunk of "web apps" means "electron apps" which are absolute bloated pieces of junk next to their desktop cousins.

You also have to remember a 'framework' typically doesn't stand in isolation - tens, hundreds, thousands of dependencies typically lurk.

We all agree tracking junk makes it even worse, but the whole thing is already overcomplicated before you get to that point.

While this is true, at least by having a large number of people commit to the same set of dependencies, you stand a higher chance of complications between those dependencies being ironed out, either directly by the framework maintainers or by the user base of the framework.