Remix.run Logo
▲ bagacrap 3 hours ago

why I would think this is because both logic and every online resource indicates that it is true. There are a lot of shared utility processes, binary, etc in a browser. I'm not sure why you wouldn't think it was true, but if you assert that task manager reporting is untrustworthy, I guess we'll never be able to measure. Given how hard Slack is constantly pushing on getting me to install their desktop app, I'm just gonna assume they spend little to no time optimizing the tabbed experience. But that doesn't make me trust them enough to install and run another full browser runtime for a chat app.

Btw, up to the point that my desktop environment actually runs out of RAM, I actually don't care how much RAM is in use. In fact, if any less than the full amount is in use (less some buffer for new actions), I'm probably being underserved. So when a full browser has things like pre-rendering taking up some amount of memory to serve the next link click 0.2s faster, that's a benefit, not something I score against it.

> I regularly see tabs running at over 1.5GiB of RAM

But would they use less as an electron app is what we're debating.

▲dijit 3 hours ago | parent [-]

Ok, but we could make a test.

1) Launch a fresh browser and open teams and slack - check total system usage, then close

2) Launch Teams and Slack as electron apps - check total system usage, then close

3) Check the system usage with everything closed.

Probably the closest to a proper test we'll get.

Also, the debate about "unused ram is wasted ram" falls very short when it's storing numbers vs caching documents that are in frequent use.

Your choice of using 64-bit double-precision floating point numbers for things that could otherwise be a byte (or a BIT in some cases).. though I know JS runtimes jump through hoops to avoid this in the modern day, those hoops also cause needless computations and overhead.

When every object is heap allocated with all the cruft that it entales, when it has no value types or structs, when it needs GC headroom and runtime metadata (for JIT) and when strings are immutable requiring more allocations when "mutating"... and also while the ecosystem builds itself around stuffing as much code as possible into the browser... well... that doesn't provide a lot of value for the user..

Preloading the next page I might click and making sure the files I most access on my disk are in memory already: ARE.

Your argument falls short because memory is never wasted if chat programs didn't gobble it all up, it would go to something that the user perceives as higher performance even if it was not used by any application.