Back in the day people coded lightweight because it wouldn't run otherwise, and speed mattered in single core sub-GHz CPUs. We don't have that same constraint today, how do we get people to write more efficient code?
It’s not perfect but the battery menu on macOS pointing out apps consuming a lot of energy has inspired a good amount of efficiency work for macOS ports of things because users see it and gripe at developers about it.
I would like to see that taken a step further. Something like the system showing a notification banner saying something to the effect of, “BadApp is consuming excessive amounts of energy. Quitting it will increase your battery life by approximately 3 hours and 15 minutes.” I believe quantifying the loss that the user is suffering as a result of the developer’s laziness will go a long way to inspire displeasure in users, who will then apply pressure on developers to fix it and opens up space for competitors who sell themselves with better efficiency.
Several reasons why this principle doesn't apply in this specific (Electron) situation:
(1) Every single Electron/webtech application I've used hasn't just consumed tons of RAM, but also had a noticeable CPU (-> battery & performance) impact.
(2) Most webtech apps I've seen have had memory consumption in the 200-400 MB range - which isn't a problem on my 16 GB desktop, but is a problem on my 4 GB RAM laptop. People have less RAM than you think, and want to run more applications than just yours. Which is better: to be able to run Spotify, Discord, Slack, Matrix, Obsidian, your web browser and a video game all at once, or to have to manually open and close applications when you OOM?
That is - wasting 200 MB of RAM isn't bad if your available RAM is far in excess of 200 MB. For most people, it isn't. If Electron apps each used only 5 MB more than necessary, you would see virtually no complaints at all.
(3) Inefficiency is making bad use of available resources. Not only are chat applications like Slack and Discord not intrinsically difficult problems, but the very existence of third-party clients like Ripcord[1] show that these applications are making extremely poor use of the resources given.
Memory is a limited resource to be used judiciously, not an all-you-can-eat buffet.
At the end of the day, if my system wildly misbehaves under high memory pressure, and forcing the pressure down resolves the misbehavior (or keeping a certain amount of headroom prevents it from happening outright), "linux ate my ram" is an accurate description of what happened and no amount of tut-tutting telling me that it doesn't work the way I just got done seeing it work changes that.
I'll give zram a try, but the problem here is poor usage of memory (both in priority and badly-behaved bloatware), not quantity of memory available. I'm not a kernel developer, I shouldn't have to dork around with these kinds of knobs to get sane behavior.
Worse, this often happens when there's plenty of cache to evict. I can and have restored a nigh-unusable desktop to normal operation many times with a painfully entered `echo 3 > /proc/sys/vm/drop_caches` from a new TTY, instantly resolving the pressure and giving me time to find and terminate the presumptuous program who thinks its entitled to 3/4 of system memory (usually some flavor of web browser or electron bloatware).
Why's the kernel so jealously guarding its cache allocation and making the UX suck harder? Not a clue. Whatever performance penalty I take from nuking caches is far, far less than from allowing free memory to fill up and dealing with the pathological behavior surrounding that.
Just to again note that just because a program says it's using N MB of RAM doesn't mean that all of that RAM is actually paged in. Every thread you execute has an 8+MB stack but most of it won't get allocated for the majority of programs.
> we start digging into swap, and at that point, the UI is starting to significantly chug.
Only if you're constantly swapping in and out of swap. Just putting something into swap and never retrieving it won't case issues.
I'd generally recommend disabling swap altogether though and just letting OOM take out misbehaving processes.
This isn't all to say that using less memory is 'bad', but when people say 'oh that program is such a memory hog' I wonder if they might be measuring incorrectly, or not realizing what it's doing with that memory.
Which, in the experience I just gave, is what's happening. System memory at some high 90s percent utilization, swap usage creeping up, kswapd with a ton of CPU usage, and worst of all, UI chugging. If it wasn't 'actual' memory usage, why does dropping caches, instantly freeing up some amount of memory, restore responsiveness?
I've tried operating swapless before, but that just means OOM killer kicks in even when there's cache to evict. That seems like a priority inversion to me - of anything paged in, shouldn't cache have the absolute lowest priority, and be the first thing to go when memory's needed for other things?
Besides, memory usage is hard to measure. Lots of memory may never get paged in.
There's little else until/unless people see enough well performing applications that they start complaining or move away from the slow ones.
Of course it's a trade off! We enabled this miracle by training people that have a very focused, narrow understanding of not even a field but a particular tech. Electron is basically the perfect fit for this type of education. It enables someone to build something where previously they could build nothing. It makes getting from 0 to 1 that much easier.
From a business standpoint, it's simply smart to be wasteful with resources that are abundant (average computing power on personal devices), when it helps you save on resources that are not (dev time). But of course, there is much not to like about the side effects.
Making GUI apps using Electron tech for front end is no less time consuming than doing GUI in Lazarus for example. But the end result is way more frugal in the latter case.
It is a lot faster if you already know web tech stack, and you would have to learn Lazarus/pascal
In any way I am all in for the type of developers that know how to screw size 8 bolt into size 8 nut and the rest be damned. It keeps some healthy niche and remuneration for little more versatile types.
Bad developers, bloated software and technical debt go hand in hand and eventually bite back.
The world needs more good developers, not just more developers.