Hacker News Reader

Comment by dkns | Hacker News Reader

Here's what's been bugging me lately about electron apps. They often take disproportional amounts of ram compared to what they do/have to offer. Common response is that it's not an issue because ram is plentiful and even if my terminal takes 500 mb of ram that's not an issue because I have 8 gb or 16 or whatever. Yes, but if this trend continues soon we'll end up with electron based text editor, music player, terminal, 2 - 3 chat apps, git browser, etc. etc. That starts to quickly add up and I don't feel like buying more ram just because it's cheap. RAM is cheap but so is a trip to the zoo and given the choice I'd rather go to zoo than buy more ram.

View on HN

>electron based text editor, music player, terminal, 2 - 3 chat apps, git browser

So... Atom, Spotify, Black Screen, Slack & Discord, GitKraken. "Soon" is now.

+1 You beat me to it.

Spotify is close but not actually an Electron app, although it does use the Chromium Embedded Framework on-top of a C++ core and modules. Basically, only the view is web-based.

Well, a chain is only as strong as its weakest link. And Spotify is a bloated monster and a disgrace just because of "only the view".

I'm 100% with you on this, but the real problem is that, while maybe RAM is relatively cheap, the most common computers today, laptops, cannot be arbitrarily upgraded!, and any developer who ignores that is just not doing you a favor.

They cannot be upgraded because ordinary users didn't actually ever upgrade them when it was even possible.

Why do you think the reason matters? It doesn't change anything.

> if this trend continues soon we'll end up with electron based text editor, music player, terminal, 2 - 3 chat apps, git browser, etc. etc.

I can imagine at some point the runtime, being so popular, getting heavily optimized by some stakeholder. I already heard that there are some significant contributions from Microsoft. They had also did the same for node.js.

> and given the choice I'd rather go to zoo than buy more ram

While I generally agree with your comment, I personally like shopping for hardware much more than pitying caged animals.

That 500-700MB for an ordinary single application is already using heavily optimized electron. I do not think electron is some sloppily written piece of software. That monstrous ram consumption is just the effect of using browser framework for non-browser application. Nothing will change until people simply stop using electron.

You may be right, I don't know the internals of the Webkit. Then I suppose an alternative with an easy migration path would pop-up... or the supply of developers with good native experience would need to magically increase, which is very less likely to happen.

> or the supply of developers with good native experience would need to magically increase

Well one of the thing I notice despite all the new apps made with electron, none of them opened a category of new type of software which wasn't there before. It is just quickly made chat app, notes app, text editor and so on. So it is not that we need dramatically more native developers but to ask do we need 100 more apps of same type.

The only real benefit I see to Electron is it's finally delivering what Java promised, which is apps that run on all platforms from a single code base. Although, just like Java, they end up having non-platform-native UIs, and I imagine there's still some amount of platform-specific work you need to do (e.g. providing appropriate keyboard shortcuts on each platform).

> finally delivering what Java promised

Isn't this mostly true for Java already? I certainly recall downloading various applications bundled in .jar's and having them work fine on whatever platform I happened to be using.

I think people moved away from writing end-user apps in Java because they were bloated and slow and had ugly UIs, not because cross-platform development was super hard.

Can anyone comment on the relationship between memory usage and the number of windowed instances of Black Screen?

Right now I have 8 terminals open, some tabbed, some not, Sometimes I can have over twice as many. Many of them sit untouched on an Awesome workspace for days ready for me to come back to whenever I need them. This isn't a issue since their memory footprint is almost non-existent on pretty much any machine. Could I get away with this if I had to run an instance of Node + Chromium per terminal window? Is Black Screen one step ahead of me and it'll reuse an already running instance and open up another window? Do I want all my terminal instances to be managed by a single node process? Despite my reservations, still going to give this a go.

On a side note, anyone looking for a slightly more useful shell that is still very lightweight: check out fish: https://github.com/fish-shell/fish-shell

Eventually we may end up with shared system-wide electron instances, that are shared between all applications that claim they're compatible with said version. Kind of like Chrome tabs all share the same Chrome browser.

Then someone will come up with ElectronOS.

And then someone will write a web browser for Electron, and then someone will make that browser headless. Electrons all the way down!

It's going to start with a browser based desktop ('not OS') and trickle down from there inception style. That way when we build a mirror out of raspberry pi we can CSS/js the calendar into the desktop background.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Unfortunately some people seem to have missed that this talk was labeled "comedy" and "absurdist", are actually trying to implement a JavaScript kernel. The talk just got the name wrong - it was "Electron", not "Metal".

I know it's an experimental project, but that's exactly the time to learn Ruby+Tk, or {anything}+Qt, or any of the other cross-platform toolkits. If you have to bundle an entire GUI server ("the browser") with your app to shoehorn HTML into use cases it wasn't designed for, you're doing it wrong.

> you're doing it wrong

"wrong" is subjective here. You could also argue that Ruby+Tk is "wrong" because Ruby is not as efficient as coding in C++, or C, or Assembly.

What we're talking about here, (and every time this comes up, again, and again, and again, over and over) is what shortcuts you're willing to take to get to MVP. There are a lot of Electron success stories out there, and when you're a solo dev starting out, and want to make a cross platform app, Electron is approachable and proven.

Wouldn't shared resources lead to security vunerabilities between electron apps(genuine question, not something I've really looked into at all)

Depends on the implementation, but I'm sure it's possible to do it safely. Chrome already has most of the necessary tools https://www.chromium.org/developers/design-documents/multi-p....

Question is how much memory would actually be saved.

As far as I understand, there's nothing impossible in optimizing the internals of Electron while keeping more or less the same application-facing API. And if it's possible, it will get done, sooner or later - after all, Java had a reputation for being slow too.

I also like the zoo.

It's definitely a band-aid, but has anyone tried ksm on linux with a web/electron-heavy desktop to see how much ram is duplicated across multiple instances?

You can't buy more RAM in most small laptops anyway, and even big ones have limits.

Reply on news.ycombinator.com