RAM prices soar, but popular Windows 11 apps are using more RAM due to Electron, Web components

Open source developers are just like you and me. They'll get fed up with the bullshit and start developing things they need with the resources they have, just like they've always done.

that has very little to do with JavaScript though 🤷‍♂️

Even Electron apps aren't necessarily ram hoarders: Stretchly, which is a break reminder and thus needs to always run in the background, takes something like 20 or 40 MB of memory.

3/5 of the way through 100% Final Fantasy II. Figure by the time I catch up to modern final fantasy either hardware will be better again or people will optimize again. Either way I got time

That'll be 800€ and all change you own.

That's been the thinking for the last couple of decades at least. But it can't continue if people can't afford new hardware.

This is what bothers me so much... Browsers should be improving their PWA implementation (looking at you, Firefox) and electron apps should be PWAs more often. Another decent middle ground Is Tauri. SilverBullet and Yaak are both so much lighter and better than anything else on my system.

I wonder how much exact duplication each process has?

https://www.kernel.org/doc/html/latest/admin-guide/mm/ksm.html

Kernel Samepage Merging

KSM is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y, added to the Linux kernel in 2.6.32. See mm/ksm.c for its implementation, and http://lwn.net/Articles/306704/ and https://lwn.net/Articles/330589/

KSM was originally developed for use with KVM (where it was known as Kernel Shared Memory), to fit more virtual machines into physical memory, by sharing the data common between them. But it can be useful to any application which generates many instances of the same data.

The KSM daemon ksmd periodically scans those areas of user memory which have been registered with it, looking for pages of identical content which can be replaced by a single write-protected page (which is automatically copied if a process later wants to update its content). The amount of pages that KSM daemon scans in a single pass and the time between the passes are configured using sysfs interface

KSM only operates on those areas of address space which an application has advised to be likely candidates for merging, by using the madvise(2) system call:

int madvise(addr, length, MADV_MERGEABLE)

One imagines that one could maybe make a library interposer to induce use of that.

I tried the PWA route with Discord. It wouldn't stay logged in, and acted generally janky. That said, I do PWA with any app that's Electron, at least to try and avoid the RAM bloat.

Or, even better, let’s start developing for separate platforms again, and optimise software for the platform that’s going to be running it. Rather than just developing everything for Chrome.

Memory hogging browsers usually do release memory when pressured. You can take it further by getting extensions that unload unused tabs.

The problem is electron apps that load the whole browser core over and over.

So what was the original saying? As I see it, this phrase is wrong no matter how you look at it. Because all ram is used at all times, for example if you have 32GB of free ram, the kernel will use all of it as a page cache to speed up the file system. The more free ram you have the more files can be cached, avoiding access to the disk when you read them.

Yep. My 64 gigs of RAM died in my old setup a few weeks ago, and instead of paying out the ass for replacement DDR4 RAM, I decided to pay out the ass for DDR5 RAM and upgrade while I was at it. Only did 32 gigs, because I really wasn't using most of my 64 gigs (I thought). A few days ago, I ended up having to set up a swap file because a Rust project I was working on kept crashing VSCode while it was running the analyzer. What are we doing here.

We kinda have that already

Some frameworks/standard libs do support that, making use of OS webrendering capabilities.

For example MAUI WebView

WebView uses different browser engines on each platform to render web content:

• Windows: Uses WebView2, which is based on the Microsoft Edge (Chromium) browser engine. This provides modern web standards support and consistent behavior with the Edge browser.
• Android: Uses android.webkit.WebView, which is based on the Chromium browser engine. The specific version depends on the Android WebView system component installed on the device.
• iOS and Mac Catalyst: Uses WKWebView, which is based on the Safari WebKit browser engine. This is the same engine used by the Safari browser on iOS and macOS.

I mean, ymmv. The historical flood of cheap memory has changed developer practices. We used to code around keeping the bulk of our data on the hard drive and only use RAM for active calculations. We even used to lean on "virtual memory" on the disk, caching calculations and scrubbing them over and over again, in order to simulate more memory than we had on stick. SSDs changed that math considerably. We got a bunch of very high efficiency disk space at a significant mark up. But we used the same technology in our RAM. So there was a point at which one might have nearly as much RAM as ROM (had a friend with 1 GB of RAM on the same device that only had a 2 GB hard drive). The incentives were totally flipped.

I would argue that the low-cost, high-efficiency RAM induced the system bloat, as applications could run very quickly even on a fraction of available system memory. Meanwhile, applications that were RAM hogs appeared to run very quickly compared to applications that needed to constantly read off the disk.

Internet applications added to the incentive to bloat RAM, as you could cram an entire application onto a website and just let it live in memory until the user closed the browser. Cloud storage played the same trick. Developers were increasingly inclined to ignore the disk entirely. Why bother? Everything was hosted on a remote server, lots of the data was pre-processed on the business side, and then you were just serving the results to an HTML/Javascript GUI on the browser.

Now it seems like tech companies are trying to get the entire computer interface to be a dumb terminal to the remote data center. Our migration to phones and pads and away from laptops and desktops illustrates as much. I wouldn't be surprised if someone finally makes consumer facing dumb-terminals a thing again - something we haven't really experienced since the dawn of personal computers in the 1980s.

But TL; DR; I'd be more inclined to blame "bloat" on internet web browsers and low cost memory post '00s than on AI written-code.

In Tauri, the rust backend is the glue between web/js and OS functions. Yet you don't need to do any rust code, it's delivered ready.

Of course all must rust, return to the oxide!

Just use the website then?

It is a good solution for some apps but if you need to store data locally, use push notifications, run something in the background or access any native APIs you have to go with a native app.

WebBluetooth, WebUSB, WebSerial and the File System Access API aren't universally available in Browsers for example.

Tauri would be a lesser evil compared to electron, but that then involves libwebkitgtk.

VSCode history is so messed up. Microsoft buys github and stops production of github team's IDE, then uses the framework developed for that IDE to make VSCode.

Fucking 1600s colonizer behavior.

No thanks. Any software that has AI integration as one of its main selling points is shitware imo.

"unused ram is wasted ram"

yeah yeah yeah, great. but all you motherfuckers did that and i'm fucking out of ram.

They used Cloud Computation and AI ("Actually Interns") way before it was cool.

Hardware keeps getting kore powerful but programs aren’t really doing anything more for us. Games look pretty much the same at anything but the highest settings and a browser does the same shit it did ten years ago, but with all this hardware the devopers stopped giving a shit. “Who cares if it’s good for a 2070, a handful of 5090s exist!”

Sometimes it is even worse, as some apps get native clients on mac/windows but for linux, the webapp packaged as electron is “good enough”

I would be interested in seeing how you have it set up that firefox or linux are using any substantial amount of ram. That wouldn't have anything to do with 'badly written code'.

Correct! The difference is the OS.

Windows is a ram hog. Using 4GB or more just to exist. Linux uses 1-2GB, sometimes less.

Microsoft FORCES electron web components.

Linux has choice.

So yes, linux has electron as well, but Linux is a lot lighter and nowhere near a hog like windows.

Don't remind me, I am high on copium right now. I can't even play any of my steam games, but I have my Miyoo Mini+, so I'm surviving haha

There is also the advantage of an army of web devs who can build somewhat functional software for the desktop day one.

There are, but few of them also work on the web as an alternative to the desktop. Writing one shitty web app and offering Electron wrapped versions of it gets you a webapp, a Windows app, a Linux app and a MacOS app. And you already have web devs on the team because everyone does.

We were laughing at Java back in the days. Now they use JS instead...

Electron is fine for what it does. It's just that every problem was turned into a nail and Electron is the hammer.

https://releases.electronjs.org/release?channel=stable

I mean don't you know that firefox loads a FULL web browser with an engine and all every time it boots up?

And it always used Chromium under the hood.

The article mentions Chrome/Chromium: 9 times
The article mentions Google: 0 times

Google made Chrome. Chrome had that multi-process architecture at its core which allowed to consume as much memory as needed even on 32-bit OS. Chromium was always inside it and open source. Then they created CEF, which allowed webdevs to build "real" apps, and that opened the floodgates. Electron was first built on it but they wanted to include Node and couldn't because it required too much experience in actual coding. So they switched to Chromium. It didn't change much in the structure, just basically invited more webdevs to build more "real" apps (at 1.0 release Electron advertised hundreds of apps built with it on its website).

Google could do something about how the web engine works in frameworks (that don't need that much actual web functionality), but didn't. They invited webdevs to do anything they want. Webdevs didn't care about security because mighty Google would just publish new Chromium update eventually. They never realized they don't need more security in their local "real" apps gui that connect to their websites because there is not much room for security danger in such scenarios. They just always updated the underlying engine because why not. Chromium dll is now at 300 mb or something? All of that code is much needed by everyone, is it not?

So, for me the sequence was always seen as this:

Google (caring about webdevs, not OS) ->

Webdevs (not caring about native code and wanting to sell their startup websites by building apps) ->

Reckless web development becoming a norm for desktop apps ->

Corporations not seeing problems with the above (e.g. Microsoft embedding more stuff with WebView2 aka Chromium)

So yes, Google has everything to do with it because it provided all the bad instruments to all the wrong people.

Personally, I don't care much about hating Microsoft anymore because its products are dead to me and I can only see my future PCs using Linux.

It must take so much R&D to achieve anything remotely comparable to what Samsung, Micron (/Crucial... RIP) and SK Hynix can produce.

Fingers crossed they can either undercut the 3(now 2) big producers, which is doubtful. But hopefully they can help reduce the maximum price that decent memory can inflate to. Because at some point a medium sized customer is gonna get fed up of the Samsung/micron/skHynix bullshit, and custom order the ram they need, and such a smaller producer will provide a much better service for a similar price