Hacker News Reader

Comment by seanwilson | Hacker News Reader

I would take opinions on here from developers with a big grain of salt. I read people saying things like Spotify and Atom are "unusable" and slow because they're written in JavaScript when they have plenty of happy users.

A few 100MB of RAM or disk space extra is a nonexistent issue as well to typical users. I know some developers get very offended at a program using a bit more RAM or CPU than it should be but developer efficiency is more important most of the time so it's a completely rational trade-off. Some of these apps wouldn't exist at all if everyone insisted on native everywhere.

It's all just my opinion as well, but approaches like Electron are very efficient at creating good cross platform apps. Developing and maintaining several native apps is a huge resource drain when most users aren't going to care.

View on HN

Every Electron app I tried halved my battery life. Sure, regular people won't complain about your electron "desktop" app, they'll just complain about crappy batteries of their laptop, or about "my computer getting slow".

In fact, every time you hear a non-programmer complain about their computer it's usually not a hardware, but a software like electron that's ruining their experience.

OSes have started to add application profiling recently, so once every mainstream OS starts loudly pointing a finger at offensive applications (like "uninstall Spotify/Slack and you'll get 4 more hours of battery life"), you'll start hearing complaints from non-programmers.

This is absolutely the case.

I can get literally double the battery life on my Thinkpad if I close Slack, Messenger for Desktop, Atom/VSCode. Chrome uses multiple extra watts of juice in powertop than Firefox, and every Electron.JS application is really just a Chrome instance.

I'm not sure about battery life but I was a huge fan of Slack (based on Electron) until I set it to run at startup. Before then I'd routinely have three Visual Studio instances, a SQL manager and Chrome running with 10 or 15 tabs open. No problem. Suddenly, I noticed my Windows machine would bog down with just one Visual Studio and take minutes to load Chrome. I was sure I had a virus.

Actually, Task Manager showed 90% of my 8Gb ram being utilized and caching to disk constantly with most of the ram and CPU being hogged by eight(!) Slack threads. This is with Slack minimized and sitting idle.

The fix was to replace the Slack/Electron app and use the browser version instead. That solved it.

Electron is a super cool piece of tech that could enable all kinds of great app development but needs to go on a serious diet first.

My laptop has 2GB RAM. Firefox takes up about a quarter of it on average, Emacs is about 10-100MB, the system (Xubuntu) seems to take up about a GB, and what remains is indeed a few hundred megabytes. This means that I can run half an Electron app at a time on my machine. And normal people don't have more than 4-8MBs of ram on their computers. And high CPU and RAM usage drains battery, and most people are on laptops nowadays. So RAM and CPU use is still a thing for users. If anybody thinks otherwise, that's probably because they're in their bubble of hackers and have only a guesstimate about an ordinary user's use of a computer.

Speaking as someone with an Ultrabook that had to run Chrome, Outlook, Skype, and various office apps and so forth, this attitude infuriates me.

Slack uses 400-500MB of memory. That's 15% of my RAM. For a chat application. Every Electron app is in this range. None share a runtime or memory footprint.

Believe it or not, not everyone has 16GB of RAM. This level of inefficiency is utterly inexcusable.

Not everyone has 16B of RAM, and those that do get worse battery life because that much RAM is a significant part of a laptop's power budget.

Now that you mention it, this is pretty ridiculous: http://imgur.com/a/HyFay

Code Helper is from VSCode. VSCode, Evernote and Slack are all completely idle right now. I don't think they should be using any memory at all. Especially not over 700 MB. I don't even understand how they could possibly be using that much memory.

Is it just memory leaks?

That image means nothing. Apps and the operating system cache lots of different things. If your system was under memory pressure then you'd see it lower.

Fact is if the ram it available, an app should cache as much as possible. It has no idea what you'll need next, so better it use a free resource to reduce latency.

You cannot think of an app in just terms of the text it handles but also window pixmap data.

Apps and the operating system cache lots of different things. If your system was under memory pressure then you'd see it lower.

There's a problem, though: it doesn't work that way.

The size reported by Windows is (if I'm not mistaken) the committed heap size of the program. Unless the application actively surrenders allocated pages back to the OS (and hint: no application does that), that memory is committed.

Edit: to add some color: when a program calls malloc, memory is allocated from pools inside the process itself. If no memory is available in the internal pool the allocator will call out to the OS for additional pages (in the Unix world this is a call to sbrk). When free is called, memory is returned to the internal pool but is not surrendered back to the OS and thus remains committed to the process. Actually reducing the committed heap size once again requires an explicit call to the OS (e.g sbrk).

Of course it may be swapped out by the OS, but that just means slow disk I/O when that application comes to the foreground or accesses those swapped pages (which presumably contains the precious cached data you refer to).

Should the OS use memory to cache transient data? Certainly. OSes typically contain logic to throw away those caches if memory is needed.

But applications that do this without intelligently surrendering cached pages back to the OS when memory is low (as an OS does with its own caches) just put that much more memory pressure on the overall system itself. And I've never heard of an application that does this. Certainly I've seen no evidence that Electron is that sophisticated in its memory management, though I'm happy to be proven wrong.

Don't know if it's relevant, but that screenshot is from macOS, not Windows.

Anecdotally: I am currently running VSCode and Task Manager reports 19,8 MB of memory usage right now (vscode Window being idle, with 6 files opened on Win10)

The size reported by windows is the private working set. If windows pages out data for non-use it doesn't show unless you add the commit column.

> I would take opinions on here from developers with a big grain of salt.

If you "Ask HN" for opinions how can you take those opinions with a grain of salt?

Surely if you can't trust HN commenters then Ask HN is a waste of time.

I tried switching to Atom a few times, but I couldn't handle the slowness. It's just too laggy. On the other hand, I recently switched to VS Code, and I couldn't be happier. The startup is still a little slower than Sublime, but the editor is blazing fast. I really think this is just a problem with the architecture of Atom.

Spotify is also a bit slow and clunky, but it's not too bad. There's no reason why they couldn't aggressively pre-fetch a lot of pages to make the UI feel snappy. E.g. "Browse", "Radio", and all the tabs under "Your Music". And if you're playing a track, just pre-fetch the artist and album pages. If I can click something in the UI, it should already be loaded.

But even when stuff is already cached, the UI takes about 500ms to render the new page. Sometimes it's only a few hundred ms, but there's a nasty black flash before it renders. the new page. There's really no reason for that either. There are so many ways you could speed that up to make it instant. For example, just render everything above the fold, then add the rest of the content later.

Spotify's internet connection detection drives me crazy sometimes. Sometimes it takes 20-30 seconds to get back online, but I don't think that's related to JS. Their polling interval is just too long. There's no reason why they couldn't poll once per second and come back online immediately.

Maybe Microsoft is making heavy usage of Node native modules. I don't know for sure, but I suspect this is the reason why VS Code is much faster than Atom.

As far as resource consumption goes, VS Code is definitely the lesser of two evils.

I can't help but be reminded of the "VS Code uses 13% CPU when idle due to blinking cursor rendering" post that was on HN earlier last week, referring to the following issue:

https://github.com/Microsoft/vscode/issues/22900

But atom is actually unusable, I've tried it, the lag is terrible, thank god for notepad++

>I read people saying things like Spotify and Atom are "unusable" and slow because they're written in JavaScript when they have plenty of happy users.

Well there isn't exactly a choice of what spotify client to compare it to is there - so users have to use it by default rather than be 'happy' about it.

Reply on news.ycombinator.com