Perhaps the math will change if the hardware market stagnates and people are keeping computers and phones for 10 years. Perhaps it will even become a product differentiator again. Perhaps I'm delusional :).
Well, some of the "old school" has left the market of natural causes since the 2000s.
That only leaves the rest of 'em. Wer dey go, and what are your top 3 reasons for how the values of the 2000s era failed to transmit to the next generation of developers?
I have an example.
I use Logos (a Bible study app, library ecosystem, and tools) partially for my own faith and interests, and partially because I now teach an adult Sunday school class. The desktop version has gotten considerably worse over the last 2-3 years in terms of general performance, and I won't even try to run it under Wine. The mobile versions lack many of the features available for desktop, but even there, they've been plagued by weird UI bugs for both Android and iOS that seem to have been exacerbated since Faithlife switched to a subscription model. Perhaps part of it is their push to include AI-driven features, no longer prioritizing long-standing bugs, but I think it's a growing combination of company priorities and framework choices.
Oh, for simpler days, and I'm not sure I'm saying that to be curmudgeonly!
--
[0] - Having https://sectograph.com/ as a watch face is 80%+ of value of having a modern smartwatch to me. Otherwise, I wouldn't bother. I really miss Pebble.
("Why don't you just close firefox?" No thanks, I've lost tab state too many times on restart to ever trust its sessionstore. In-memory is much safer.)
You have to close Firefox every now and then for updates though. The issue you describe seems better dealt with on filesystem level with a CoW filesystem such as ZFS. That way, versioning and snapshots are a breeze, and your whole homedir could benefit.
For the rest: I agree with you.
And when, for whatever reason, having a "desktop application" becomes a priority to developers, what do they do? Write it in Electron and ship a browser engine with their app. Yuuuuuuck!
I haven't noticed any kind of difference when using Teams. That piece of crap is just as slow and borken as it always was.
> I haven't noticed any kind of difference when using Teams.
If the device is a laptop, also the thermal design (or for laptops that are in use: whether there is dust in the ventilation channels (in other words: clean the fans)) is very important for the computer to actually achieve the performance that the hardware can principally deliver.
The issue is with applications that have no business being entitled to large amount of resources. A chat app is a program that runs in the background most of the time and is used to sporadic communication. Same for music players etc. We had these sorts of things since the 90's, where high end consumer PCs hat 16mb RAM.
these days individual _tabs_ are using multiple gb of ram.
tl;dr, no one is looking for their RAM to stay idle. They're looking for their RAM to be available.
In not trying to excuse crappy developers making crappy slow ad wasteful apps, I just don't think electron itself is the problem. Nor do I think it's a particularly big deal if an app uses some memory.
The issue with Electron is that it encourages building desktop apps as self-contained websites. Sure, that makes it easier to distribute apps across systems and OSes, but it also means you've got front end web devs building system applications. Naturally, they'll use what they're used to: usually React, which exacerbates the problem. Plus it means that each app is running a new instance of a web browser, which adds overhead.
In real life, yeah, it's rare that I actually encounter a system slowdown because yet another app is running on Electron. I just think that it's bad practice to assume that all users can spare the memory.
I'll admit that my concern is more of a moral one than a practical one. I build software for a living and I think that optimizing resource usage is one way to show respect to my users (be they consumers, ops people running the infra, or whatever). Not to mention that lean, snappy apps make for a better user experience.
This is why the top model of the previous generation of the iPhone (the iPhone 16 Pro Max) has only 8 GB of RAM, bumped to 12 GB for the current top model (the iPhone 17 Pro Max at the higher tiers of additional storage). If Apple had decided to put more RAM than that into any iPhone, even the models where the price is irrelevant to most buyers, they would not have been serving their customers well.
So, now you have to pay a penalty in either battery life or device weight for the duration of your ownership of any device designed for maximum mobility if you ever want to having a good experience when running Electron apps on the device.
Are they slow because they're Electron? No idea. But you can't deny that most Electron apps are sluggish for no clear reason. At least if they were pegging a CPU, you'd figure your box is slow. But that's not even what happens. Maybe they would've been sluggish even using native frameworks. Teams seems to do 1M network round-trips on each action, so even if it was perfectly optimized assembly for my specific CPU it would probably make no difference.
I wonder if there’s a computer science law about this. This could be my chance!
https://en.wikipedia.org/wiki/Wirth%27s_law
Not exactly the same (it's about power rather than price). But close enough that when you said it, I thought, "oh! there is something like that." There's also more fundamental economics laws at play for supply and demand of a resource / efficiencies at scale / etc. Given our ever increasing demand of compute compared increasing supply (cheaper more powerful compute), I expect the supply will bottleneck before the demand does.
I guess this might be happening with LLMs already