A theory I've often had: the Jevons paradox explains why desktop software remains so slow despite the massive improvements in hardware speeds. When you improve the efficiency of the hardware, software starts to demand more CPU cycles, since there's less of an incentive to optimize.

> ...software starts to demand more CPU cycles, since there's less of an incentive to optimize.

Node and Electron and crew would agree.

A "modern" chat client (Element, Signal, etc) will lag on a quad core 1.5GHz system in terms of "typing into the text input box" (RasPi4, yes, I've set the governor to performance), when a single core 66MHz 486 could manage that trick without any lag in a range of chat clients. Hexchat still works fine, at least.

What we need to do is stop letting developers use high end, modern systems, and put them on something a decade old for daily use. Then maybe they'll stop writing crap that only works well on a 1-2 year old Xeon workstation. Google, I'm looking at you. Buy all your devs a Pi4 and make them use it once a week for a day.

Some of it is explained by bloat but some of it is explained by things like 4K-5K displays, pretty antialiased fonts, support for multiple languages and unicode, support for inline images and videos, emojis, support for all kinds of inline objects like polls or HTML documents, transport encryption everywhere (sometimes multiple layers of it like Signal ratchet over TLS), scrollback history with search going back to the beginning of time, real time sync between devices, and so on.

High resolution displays for example impose an exponential cost right out of the gate. Just printing "hello world" requires more pixels as a function of the square of the increase in resolution. That's more memory, more memory bus traffic, larger bitmaps, scalable vector graphics formats that take more processing power to draw, antialiasing, ...

Again I am not writing off bloat. We could probably shrink most software by at least 2X and most Electron stuff by 3-4X. I doubt we could shrink it 10-100X though without sacrificing some of the things I listed up there, especially all the eye candy and rich interaction media.

And don't forget accessibility. I don't know exactly how much accessibility contributes to the total size of Chromium (singling it out since Electron is everyone's punching bag), but it's something. In my AccessKit project [1], I'm probably going to spend at least a few weeks working on the accessibility of text editing alone. And that's just multi-line plain text; hypertext is way more complicated.

[1]: https://github.com/AccessKit/accesskit