Hacker News Reader

Comment by therealmarv | Hacker News Reader

I don't understand the hate on Electron. I think most people here never shipped cross plattform apps ever and even less maintained them across cross platform. It's a financial decision. Electron (in the age before AI) enabled to stand on the shoulders of giants to build a reliable product with one code-base among many OSes. Something which Java promised Electron really delivered for most end-user apps. Google poured billions into making the fundament of Electron fast and reliable and bugfree. And it enabled many Linux ports of apps which would have otherwise not happened.

Best example is vscode.

Are Electron apps more wasteful than native: sure. But I rather stand with Electron and that Windows, Mac and Linux is supported.

View on HN

Sort of, you're right that it's zero sum.

But electron applications that are forced by the first party (IE; third party clients are explicitly forbidden and will be an EULA violation- possibly resulting in expulsion from the platform) is an issue.

We talk about a global RAM crisis now due to AI, but I don't even want to think about how much RAM is hoarded by Teams/Slack and Discord in aggregate- these are applications that are intended to be run in the background by everybody, so you're talking at least 2GiB per person because you can be pretty sure that people are running more than one of these.

1.5GiB * the number of people in work = what.. 150 petabytes of RAM in Europe alone? For chat.

Is that really electron's fault though?

Compare vscode memory + cpu usage to whatever IDE you were using before that. It's probably an order of magnitude more efficient.

VS code is not an IDE, its more similar to Sublime.

In comparison to Sublime, it is indeed slower and more resource inefficient- however, it is free and good enough.

Not everything boils down to technical purity, there can be other important factors.

That used to be true but with plugins vscode really has eaten the whole IDE workflow for most people

That’s true of sublime text too. and vim, for that matter.

Perhaps a useless comparison if one thing can be converted into something else; it doesn’t mean that the base of a thing is the thing that can be evolved into.

I don't use vscode (vim user) but I'm horrified by the gigabytes of disk space wasted on shared servers by vscode remotes.

I run slack in the browser and don't understand why anyone would do otherwise.

1) Being able to switch to it is easier if it's an app

2) notifications become native rather than driven by a browser (which is a preference for some, due to reliability and permissions issues)

3) Browser vs Electron doesn't really change much in terms of performance or resident usage

4) Most people keep these chat programs running in the background, modern browsers are starting to suspend tabs (as they should) which could make the application behave strangely in future.

Not saying I don't do this with Zulip, but I also treat Zulip as "something I'll get to when I can"- like Email, rather than how many people treat Teams/Slack/Discord where it's really leaning on the instant messenger aspect and a much more realtime communication flow.

> Browser vs Electron doesn't really change much in terms of performance or resident usage

This isn't true?

As to the rest, I simply haven't had these problems. Seem like prioritization issues? The browser is doing a poor job if it's treating a tab that one switches to multiple times a day the same as a tab that hasn't been used in two weeks.

> This isn't true?

Heh, I’m not sure why you would think this- there is some sharing of resources for browser tabs but not a lot when you consider the javascript runtimes memory requirement and sandbox isolation features.

Safari is perhaps the best (or worst- depending on how you look at it) for sharing resources between tabs and weakening the sandbox for that, but I regularly see tabs running at over 1.5GiB of RAM (Tab+Renderer in Activity Manager).

It just becomes harder to track if its part of the normal browser, I think. Many browsers don’t show you a true per tab breakdown (firefox doesn’t) and often there are multiple threads per tab making the aggregation difficult (Chrome/Safari to some extent).

Even the “tab resource monitor” extensions and menus that exist only show part of the resources a tab is using, basically its DOM and in memory resources but not its renderer, runtime or other harness’

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.

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.

Reply on news.ycombinator.com