How much of all this nonsense is caused by devs using any and every JS library out there? We've seen this problem on the nodejs side before, and it's even more painful on the browser side. Sure, Slack almost certainly doesn't know all 15m LOC in Chrome, but they sure as hell should know every LOC in their JS, whether that's from in-house code or 3rd party libs.
Electron is flash for the desktop (2016)
31–40 of 1001 posts
Re: Electron is flash for the desktop (2016)
#32Most users will never notice this, and if some problem is solved using Electron well then Electron solved the problem, life goes on. If you don't like an app or how it behaves then just don't use it.
Re: Electron is flash for the desktop (2016)
#33A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience. Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-view with nothing animated in view gives it a CPU usage of 0,1% with spikes up to 2,5%. Switch to a conversation with a single animated party parrot emoji, go to another fullscreen app once again, and CPU usage never drops below a whopping 22%. For an animated par…
have you reported such behaviour to Slack devs?
Re: Electron is flash for the desktop (2016)
#34In most cases it's either an Electron app or no desktop app at all. It's simply not feasible to write native apps.
Then don't, it's really wasteful to have webdevs write desktop apps using Electron. I don't see a gain over using a webpage. I use slack this way and I don't see any problems.
You might not necessarily want something like code-editors rely on external servers, while still taking advantage of the UX of web-development.
VSCode gets around this by running an npm node locally.
Re: Electron is flash for the desktop (2016)
#35I've been working on a hobby app for some years that is a modern refresh of an old idea. As the article exhorts (and just for funsies, it's just a hobby) I'm writing it using native code and to be conservative on resources.
Every place I need to render text or make a thing respond to a mouse click I need to manually do all my own text layout and event handling and so on. (The app is in a domain where it needs special rendering -- I can't just reuse a system widget or library like Qt for this.)
Meanwhile, people are making apps similar to mine on top of Electron and banging out features way faster than I ever could. If they want some popup to have some bold text, or use the GPU to animate, or properly handle Arabic text layout, they get it all for basically free, they just need to bang out some divs. I am jealous.
Re: Electron is flash for the desktop (2016)
#36A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience. Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-view with nothing animated in view gives it a CPU usage of 0,1% with spikes up to 2,5%. Switch to a conversation with a single animated party parrot emoji, go to another fullscreen app once again, and CPU usage never drops below a whopping 22%. For an animated par…
Slack and Spotify (Atom usually behaves alright) use a ton of CPU for me, and I almost never have GIFs in my Slack.
Re: Electron is flash for the desktop (2016)
#37I don't understand the React Native comparison. AFAIK, you can't build desktop applications with that, nor can you build mobile applications with Electron like you can with React Native.
There is native support for Windows (from Microsoft), macOS, Ubuntu (from Canonical) in addition to the first party support for iOS and Android.
Re: Electron is flash for the desktop (2016)
#38It's appropriate to call Chrome an OS-like platform, and it's quite convenient to ship apps with, but it's not "Flash for the desktop". As someone who is opposed to bloat but sometimes appreciates convenience, I think Electron is getting a bad rap here for something that was screwed up by the JS app developers.
Go to Electron's website and download the demo (called API Demos). It's 3 processes and consumes 0.0 CPU on idle. Is it super efficient space-wise for what it does? Certainly not. And RAM usage is a valid concern. But churning CPU cycles on idle is not Electron's / Chrome's fault. I also suspect that if an app is behaving grossly on Electron, it's probably a bad actor within a generic browser environment, too.
My recommendation would be to not ship simple web apps wrapped in this huge machine without a good reason. But there are good reasons to use Electron or NW. It's just a poor choice when all you need is a thin wrapper around your website.
Re: Electron is flash for the desktop (2016)
#39FWIW, we're working on https://github.com/nidium/Nidium presicely to fix this. A new kind of browser engine, not based on any existing engine, allowing developers to use a subset of the web (webgl, 2d, layout) without being forced to use a bloated ecosystem (and which also works on mobile and low end device). Previous HN discussion : https://news.ycombinator.com/item?id=6314961
> To build nidium you need at least 5.7GB of disk space. A build from scratch may take 30 to 90 minutes, depending of the speed of your computer. Is this abnormally large for a project like this?
Building Chromium/CEF requires several times more disk space and takes several hours on my new MacBook Pro. So I guess the answer is "not abnormally large".
Re: Electron is flash for the desktop (2016)
#40FWIW, we're working on https://github.com/nidium/Nidium presicely to fix this. A new kind of browser engine, not based on any existing engine, allowing developers to use a subset of the web (webgl, 2d, layout) without being forced to use a bloated ecosystem (and which also works on mobile and low end device). Previous HN discussion : https://news.ycombinator.com/item?id=6314961
> To build nidium you need at least 5.7GB of disk space. A build from scratch may take 30 to 90 minutes, depending of the speed of your computer. Is this abnormally large for a project like this?
Well, it has a lot of dependencies to build :
- mozilla spidermonkey
- Google Skia
- ffmpeg
- portaudio
- leveldb
- OpenSSL
And various other stuff.