Electron is flash for the desktop (2016) - <AUTHOR> https://josephg.com/blog/electron-is-flash-for-the-desktop/ <comment><USER9> Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all".

 _Nobody_ in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x the cost), and also in finding specialist developers who know these dated technologies. And as for Qt, Qt has existed for _over two decades_ \- if its massive "Beatles walking off the plane" moment hasn't happened by then, sorry, it's not gonna.

But now? People are making all kinds of great new apps, and more often than not, they come out on all three platforms. People are _excited_ about the Desktop again - Electron is so good it's single-handedly revitalizing the platform that two of the largest tech companies in the world are behind, yet couldn't do.

That is a Big Deal.

<comment><USER10> That's _nonsense_. Desktop apps have been frequently released since forever.

The underlying issue here is that Electron _reduces the barrier to entry for cross-platform development_. That is, it's cheaper to build a single cross- platform application in Electron than it is to build two or three native applications, and you can re-use your existing web experience. I can completely understand why companies might choose this approach.

The trade-off — and there _is_ a trade-off — is that Electron applications are _shite_ in comparison with proper native applications. They fail to integrate with the host platform, they are slow, they hog memory and drink power. It's fine to make those trade-offs – in some ways, it's better that you can get an application at all than the alternative of 'no support for your platform'. But let's be honest here – there is nothing preventing e.g. Spotify or Slack from building native clients for each platform they support, and I find it difficult to believe that the costs would be prohibitive.

<comment><USER11> > Electron applications are shite in comparison with proper native > applications. They fail to integrate with the host platform, they are slow, > they hog memory and drink power.

Are they though? The two applications that use the most energy on my Mac - <USER2> far - are Steam and Skype. Steam still has trouble with HiDPI and freezes when performing various UI interactions. The number of problems with Skype are uncountable.

I'm currently booted into Windows for work, looking at my current process stats, the top memory consumers are:

* Visual Studio (hodge podge of all kinds of things, 800MB)

* Chrome (215MB)

* Microsoft Intune (presumably native, 114MB)

* GitHub (.NET WPF application, 108MB)

* Explorer (native, 103MB)

* Search Indexer (native, 107MB)

* Lync (who knows, 98MB)

Meanwhile, the supposedly terrible Electron apps:

* Spotify - <USER3>

* Slack - <USER4>

* VS Code - <USER5>

As far as interfaces go, Spotify, Slack and VS Code easily outclass GitHub, Visual Studio, Explorer and Lync in usability.

<comment><USER12> Each Chrome (and Electron) app instance is a group of processes. You are probably just looking at the main process, while the bulk of RAM/CPU use comes from the renderer processes.

Here are stats on my (Linux) box:

* atom - ~500MiB (one window)

* slack - ~816MiB

* chrome - ~935MiB (two tabs + hangouts)

* google music electron app - ~500MiB

<comment><USER11> Nope, those figures were after adding up all the processes. What I have noticed in switching between platforms is that applications tend to report a far lower memory usage in Windows than on Linux or OS X.

Might just be an accounting difference. Forked process applications in particular are very difficult to account, because even their private/RSS may be COW from another process.

<comment><USER12> My figures exclude shared memory and are calculated as VmRss - Shared from /proc/<pid>/statm.

If you are using Windows 10, your missing Atom processes will be under Background Processes in Task Manager. For the sake of the argument, I just did a fresh install of Atom and this is what I see on the first run: [https://i.imgur.com/0ZRSumF.png](https://i.imgur.com/0ZRSumF.png). ~220MiB (no files open, zero extensions).

<comment><USER13> That's really interesting! I have an up-to-date atom install that i've been adding plugins to for about a year now (up to like 50 or so), and has been running for at least 12 hours (windows 10), and currently has 7 ~500 line files open.

Adding up all the processes' (7 of them) private memory gets me 194mb.

<comment><USER12> I installed the 64-bit version, you might be using 32-bit.

<comment><USER13> No it looks like i'm running 1.15.0 x64.

It might just be a difference of platforms.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> People complaining about electron are the same type than the ones that used to say :

\- why are people writing this stuff in C. It's so slow and you don't have as much control on memory. Write it in Assembly.

\- why are people writing this stuff in Java. It's so slow and you don't have as much control on memory. Write it in C.

\- why are people writing this stuff in Python. It's so slow and you don't have as much control on memory. Write it in Java.

Eventually people want to solve a problem with the best ratio cost/quality for them, not "doing it the proper way".

So unless you provide a better solution for them to do that, or pay big money to create such solution, they will find the ugly-hackish-half-baked-working- for-them solution that let them do this.

We had PHP. Now we have JS.

I hate it. You hate it. We all hate it.

But I created portable GUI apps with an installer before in my favorite language and others and it was a pain. All of it. The UI, the event model, the API, the portability edge cases, the new stuff to learn, the packaging, the dependencies...

It sucked.

So get over it or provide a solution, but stop complaining.

And before you start providing an EXISTING solution, remember people tried it and they didn't like it as much as electron. And since electron is so bad, that should tell you something.

So the market is saying you are wrong. You can ignore it from your better tech tower... Try to boycott electron apps all you want. But we know how it has played for betamax, lisp and the ogg format.

P.S: oh, and if electron is flash, remember that flash won the web for 15 years while it sucked. And you know why ? Because it allowed people to do stuff they wanted easily, like videos and animations. And it's not because we couldn't do it any other way, we could. Yet we had to wait almost 2 decades to see it dies, at the price of battery, stability, security and everything else. Feature trumps everything. People. Don't. Care. We only manage to kill it because we finally replaced it with systems that could compete on easiness and features. So you know what to do.

<comment><USER15> > why are people writing this stuff in C. It's so slow and you don't have as > much control on memory. Write it in Assembly.

did anyone ever actually say this?

> why are people writing this stuff in Python. It's so slow and you don't have > as much control on memory. Write it in Java.

this one is odd to me considering Python came first...

<comment><USER14> > did anyone ever actually say this?

Wordperfect is famous for failing because they sticked to assembly while the competition moved to C.

> this one is odd to me considering Python came first...

It is indeed. But date of creation has no importance in this. Java became popular first, and is faster and consume less memory than Python. I'm a Python dev now, and I when I picked up the language more than a decade ago, people where looking at me like I was crazy.

</comment></comment></comment><comment><USER16> FWIW, we're working on [https://github.com/nidium/Nidium](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](https://news.ycombinator.com/item?id=6314961)

<comment><USER17> > 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?

<comment><USER18> 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".

</comment></comment></comment><comment><USER19> > If you want to use JS and react to make a native app, try react native > instead.

Given the discussion of the recent ReactXP thread, I'm guessing most people don't realize you can do this _today_. React Native supports macOS [1] and UWP [2].

Edit: There's even some early work on Ubuntu support [3].

[1] [https://github.com/ptmt/react-native- macos](https://github.com/ptmt/react-native-macos)

[2] [https://github.com/Microsoft/react-native- windows](https://github.com/Microsoft/react-native-windows)

[3] [https://github.com/CanonicalLtd/react- native/blob/ubuntu/REA...](https://github.com/CanonicalLtd/react- native/blob/ubuntu/README-ubuntu.md)

<comment><USER20> I'm probably in that camp too, I thought it was just for android and iOS still (even though I consider myself to keep up to date with these types of things).

Do you know if they have anything for linux yet?

<comment><USER21> I originally thought React Native was for all platforms, then I read their website and docs which made me realize it was only for mobile. That all went down a few weeks ago. Now, today, I find out I had it right the first time. How big a shortcoming is it of their website that it made me go away thinking it was something it wasn't when I had the right thing in mind?

<comment><USER20> Same here, it makes me wonder how hard it is to build for all the platforms as well given that they are all spread out across so many different repos.

</comment></comment></comment></comment><comment><USER22> At Nylas we made a huge bet on Electron-- our desktop app Nylas Mail actually started as a fork of Atom Shell before the project was rebranded to "Electron."

To be honest, we would have never built this app without Electron. It allowed us to have a small team (2 devs) ship the first version of the app without learning an entire new dev toolchain on multiple platforms. There certainly can be performance issues with building on Chromium/Node but those can be pretty easily addressed.

We even had an early engineer with tons of Cocoa/ObjC programming experience and they still preferred shipping with Electron.

The HN crowd complaining about Electron kind of feels like the early criticism of Dropbox or the iPod. "This is technologically inferior and has fewer features so it is clearly worthless."

For some reason there's a deep-rooted philosophical opposition to Electron- like technologies from lots of hackers. But I predict it will be like Java-- everyone "hates" the JVM for years and calls it slow and then one day it's running nearly every mobile device and being used across Google.

It's not crazy to think Electron will evolve like this-- it certainly has the momentum. And the ideas of a web-based desktop app platform have been pushed by Google, Apple, and Microsoft in the past. Seems like we're finally getting there...

(For the curious: [https://github.com/nylas/nylas- mail](https://github.com/nylas/nylas-mail) )

<comment><USER23> It pains me to see how a person responsbile for a pretty important app is as oblivious as you are to the real issues.

Many people use laptops and their battery life matters a lot, being one "minor" factor. Not to mention that in a technical sense, your app _really shouldn 't_ take any CPU while idling. Doing a socket wait is something a Raspberry Pi Zero handles without going to more than 1% CPU, for half a second.

At any rate, other people in this thread explained it much better than I could: [https://news.ycombinator.com/item?id=14091782](https://news.ycombinator.com/item?id=14091782)

<comment><USER24> > [...] oblivious as you are to the real issues [...]

I understand that you're frustrated, but this kind of language does not foster productive discourse.

As I understand it, Nylas (grinich's OSS Email product/platform) wouldn't have been possible to build with a two-person dev team had they chosen to implement it in something other than Electron.

Are you suggesting we're better off without competitors to the existing email desktop-clients?

<comment><USER23> > _Are you suggesting we 're better off without competitors to the existing > email desktop-clients?_

This is a false dichotomy and you are aware of that fact. This polarization shouldn't exist in the first place. And it can be eliminated with a small time investment.

As developers of important apps, your contribution to the world influences culture. Other follow in your wake. Is that the influence to the world you _really_ want to give to other programmers and business people? Time to market is not the only priority.

That you treat a non-flattering language as me being frustrated tells me you will not understand that side of the argument however. So let's agree to disagree and move on.

<comment><USER24> > [...] you treat a non-flattering language as me being frustrated [...]

You're right; I was being presumptuous about your emotional state. I apologize. -_-

Let me try to clarify: Companies like Slack and Nylas and Spotify understand the performance implications of using Electron and it _is_ a real problem, but the _benefits_ of using something like Electron, at least currently, outweigh the performance troubles.

There's simply a _much_ lower cost to iterate quickly on a web-driven application.

That said, we're all frustrated about the performance implications (users and companies alike), and this this is reflected in the direction the industry is taking.

I predict Electron _will_ become less popular in the next year or two as React Native desktop support becomes proven by one or more major players:

\- Linux: [https://github.com/CanonicalLtd/react- native](https://github.com/CanonicalLtd/react-native)

\- OS X: [https://github.com/ptmt/react-native- macos](https://github.com/ptmt/react-native-macos)

\- Windows: [https://github.com/Microsoft/react-native- windows](https://github.com/Microsoft/react-native-windows)

<comment><USER23> > _You 're right; I was being presumptuous about your emotional state. I > apologize. -_-_

Upvoted for you being nice and constructive. =) I could've been less harsh myself. Sorry!

> _...the _benefits_ of using something like Electron, at least currently, > outweigh the performance troubles._

I get it, man. I've been there in the past. I understand your position.

> _There 's simply a _much_ lower cost to iterate quickly on a web-driven > application...That said, we're all frustrated about the performance > implications ..._

Not arguing that, that's an undeniable fact.

> _...as React Native desktop support becomes proven by one or more major > players:..._

Yes. Nothing would make me happier. I started with Windows' crappy MFC, ATL etc. horrifying libraries and I've been immensely let down by the promise of Java Swing community that never managed to get its act together well enough to give you a quick and easy way to create cross-platform UIs. Desktop UI is like a hobo on a celebrity wedding: everybody knows it's there, everybody feels awkward about it, and nobody wants to improve its situation. And that's going for like 20 years now.

Us the slightly older generation of devs are guilty for the situation as well. We too had to go on about our day jobs and find a quick way around.

I guess I was a bit harsh because I expected the next generation to pick up the ball and dribble it better than us... >_< Which is a very wrong and egotistical expectation, I'll be the first to admit.

Just don't give up! Make sure that you educate management periodically. Talk to them, convince them, give them analogical examples from the physical world so they get the problem on their level. Never give up the good fight; educate, iterate, improve.

I loved your app, by the way. I only uninstalled it because I am moving away from Gmail.

<comment><USER22> You can still use it with any IMAP service! :) We actually just launched the Windows & Linux beta today: [http://www.omgubuntu.co.uk/2017/04/nylas-mail- client-now-ava...](http://www.omgubuntu.co.uk/2017/04/nylas-mail-client-now- available-linux)

<comment><USER23> Thanks! I'll give it a try when I move to one of the paid services.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> A 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 parrot cartoon.

I'm not sure if this is a bug in Slack or Electron. Doing the same in Chrome does not cause any issues, as GIFs seem to be suspended when the window is not in view. CPU usage goes down to almost 0 when you switch away from your GIF- filled Chrome window. For Slack, however, it barely changes. A big shame.

(On that note, I wonder how much power is wasted by party parrots via CPU usage. Where I work at least one is almost permanently visible in any conversation as a reaction emoji, so it's probably not insignificant.)

<comment><USER26> > A lot of Slack's high (background) CPU usage is caused by GIFs, in my > experience.

Holy fuck, can you imagine the supercomputers that were required to display Geocities websites in the 1990s?

<comment><USER27> 48x48 gifs with four frames of animation?

<comment><USER26> The GIFs were significantly more complex than the single emoji that the parent comment mentioned. Actually, I think even a four-frame 48x48 gif is more complex than that "single animated parrot emoji" :-).

</comment></comment></comment></comment><comment> d--b Electron is just another proof that ease of programming matters.

Node.js too was a terrible idea. Who in their right mind would write server- side javascript? It turns out: pretty much anyone who didn't want to have to screw around for hours before being able to respond to a simple http request.

Similarly, it is way harder to write a desktop app than a browser app. DOM / CSS manipulation, however bad they are, are years ahead compared to what you can easily do with WPF and friends.

And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance. Again: ease of programming.

The success of electron only shows that there is a market for a UI library that can be written just like what you do in the browser but for native desktop apps... Please someone, write that !

<comment><USER28> Your Python example doesn't really support your argument. Python succeeded for data analysis and scientific computing in part because it provided easy access to existing numerical libraries written in C and Fortran. So you got the best of both worlds: ease of use and near-native speed. It would not have succeeded if everything was done in interpreted Python.

<comment><USER29> > ease of use and near-native speed

And still when we want actual speed we port it to C++ or at least need to use Cython.

</comment></comment></comment><comment><USER30> It'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.

<comment><USER31> Blog author here. Thats a fair criticism. I wanted to pick on Spotify and Atom more in my blog post, but both Spotify and Atom have cleaned up their act. I couldn't get either one to reproducibly use lots of CPU. Props to everyone involved in fixing that.

But I'd also argue that Flash could always be written to be efficient too. The problem with flash was never the little games people made. The problem was that one tab with a stupid punch-the-monkey banner add playing somewhere that would sit on 20% cpu even when the tab was in the background. I think Electron is similar, except in the desktop space. Well written apps seem to be able to keep CPU load down (although they still have a huge download and a huge RAM footprint). But there's been a running trend of noticing some dumb software running somewhere on my machine eating all my CPU. And in the last year or two its been an electron app, every time. Just like flash before it.

<comment><USER32> > ... I couldn't get either one [Spotify or Atom] to reproducibly use lots of > CPU. Props to everyone involved in fixing that.

It seems deceiving to conceal that information when your call to action is to ditch Electron for the sake of performance.

<comment><USER33> The original blog post is from Oct 2016... can't reproduce the bug now. That's ok; not deceiving.

<comment><USER34> It's not at all clear from their statement that they tried to reproduce that now, and not that they attempted that in 2016 and didn't manage to.

</comment></comment></comment></comment></comment><comment><USER35> A while ago I had been working on a native Mac slack app. I was 70% complete but sidelined it. Should I pick it up again? Would ppl here be interested in paying for something like that? Here are some links to screenshots so you know its not just vaporware :)

[https://twitter.com/harisamin/status/727634194814373889](https://twitter.com/harisamin/status/727634194814373889)

[https://pbs.twimg.com/media/ChkTccjVAAAZ0Kt.png](https://pbs.twimg.com/media/ChkTccjVAAAZ0Kt.png) [https://pbs.twimg.com/media/ChkTcbMUkAIYolx.png](https://pbs.twimg.com/media/ChkTcbMUkAIYolx.png)

<comment><USER36> Most users will accept issues with their free program if the alternative is to pay. I'm pretty sure the message pane you have there is a WebKit controller so it is debatable how native this would be.

<comment><USER35> There actually isn't any webkit here at all, except for the slack api oauth login. Everything is native. Trust me, I'm not faking this :)

</comment></comment></comment><comment><USER37> This is Electron scapegoating. The real issue is twofold:

1\. Electron makes it trivial for developers who don't regularly reason about native performance to release desktop apps. The result: a flood of apps that "don't do much" but use more resources than you'd expect.

2\. At the other end, Electron makes complex apps easier to build. The Slack app might be low-to-medium complexity, but the Spotify app has a ton of functionality, and I bet dev effort was orders of magnitude lower than for a native app like iTunes. The result: in this day and age, complex cross platform apps with higher resource requirements are _more likely_ to be built with Electron.

In short, there's some selection bias going on in both cases, and it isn't directly related to Electron. Electron is just the enabler.

I agree with the author on point 1: performance matters, memory usage matters, and we as web developers should broaden our horizons and learn lower-level languages. I feel that way regardless of Electron though.

On point 2: I spent the last year building a cross platform continuous sync app (basically, a Dropbox V1) in Electron [0]. We were a team of 2. I also write C and C++ for a living, and I simply can't imagine building the same thing in a lower level language in the same timeframe. It's not just a UI concern either: writing a sync engine in node (the backend half of any Electron app) worked out amazingly well. Node is a great I/O orchestrator. The app runs at < 1% cpu when not actively syncing, 40MB backend process, 70MB frontend process. Reasonable for what it does. Dropbox uses more than double that although, granted, it's also not native code.

[0] [https://blend.io/download](https://blend.io/download)

</comment><comment><USER38> Why would a tech company not build its flagship product natively on the platforms where it runs? It seems like a generation drift: an obliviousness to the world outside of JS/web dev, and a general disregard for application performance.

<comment> 52-6F-62 Put simply: time to market. Experienced front-end devs with a designer on hand could put together the UI inside of a day, with a workable user experience.

Hell, if you're not afraid of bloating in the codebase, you could use a large number of libraries to put together a basic, working version inside of a day or two. Stretch that to a couple of weeks (at most) and you have a prototype you can release.

The proof is in Atlassian and Microsoft chasing after Slack on this. Very few people came forward to wave the "Let's just go back to IRC" flag.

It's shiny, new, you can drag and drop gifs and files into it, and it runs pretty swiftly (ignoring all of the obvious flaws). Most, especially less technical, users would find it a charm to work with. In my experience, they do -- and above all of the competitors.

The rest of your points are rather valid. But maybe its not so much obliviousness, as eagerness and impatience, and the reality of the market being as timely and pressing as it currently is. It's a race -- just like the telephone and the radio (for my point I'm ignoring the scale of impact here).

<comment><USER39> > Experienced front-end devs

That's the problem right there(?). People bringing a DOM to the desktop because the developers were fluent in JS.

> time to market

If there were no drawbacks in terms of complexity/performance/size etc then I'd agree, but now when you have a perf issue that is too large it might be a huge issue to fix. You also only get one chance for a first impression - <USER6> poor performance is a huge turnoff. Looking blingy and having all the features doesn't save an app with a 200ms lockup. or a 10% CPU at idle.

<comment><USER40> Agree, I think this is a combination of lack of imagination by developers who only know JS, and management who has bought the myth that cross platform development is 3x faster than making native apps.

I saw this happen at work. My team were all experts on native mobile development. We could crank out stuff fast, because we knew our tools well. But then some management dude got the idea that we would do it 2-3x faster if we went with JavaScript.

Turns out it was more like 2-3 slower than making all the native versions, because we did not have strong experience with these tools and APIs were more limited, poorely documented, buggy, and the tools were subpar.

</comment></comment></comment></comment><comment><USER41> Telegram Desktop is very good example of modern desktop client done in the most efficient way. C++ and qt, nothing else. Works like a charm an all major operating systems. Easy to install, use and update. Great stuff.

<comment><USER42> Except they've rewritten their Mac app in Swift now. So there must be a reason they moved away from that.

<comment><USER43> They didn't rewrite the app. There are multiple official apps, you could also write your own (that's what is happening for Unigram, an open source UWP client for Telegram)

</comment></comment></comment><comment><USER44> All of this extra memory and CPU power has made us lazy.

Simple applications often lag, because they are written on top of heaps of crap. Yet you look at a 4k demo that does more impressive stuff with a fraction of the resources.

When we step really far back, an application should not require that much code. Nor should the process of abstracting an application on top of a native system. These things only get muddled when you depend on specific functionality of the system that is difficult to abstract (i.e. native GUI component and layout), which you can easily simulate with your own GUI renderer, potentially in a more optimal way.

Anyhow, I'll sit here waiting patiently until someone figures out how to write once, run everywhere in a relatively bloat-free manner. :)

</comment><comment><USER45> I'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.

<comment><USER46> Well, the question is: Does your app run always like a daemon or just when you actually need it?

It can be fine to prototype in Electron, or to make _tools_ in it. But if you're making a chat program or anything similarly long-lived, it's the worst decision you can make for your user.

<comment><USER47> "it's the worst decision you can make for your user" \- Is it? Because there are a lot of Slack users who don't care at all about your tradeoffs. Most of them don't even notice. We're just the unfortunate ones who do notice.

<comment><USER46> Whether they notice or not is orthogonal to whether it's a bad decision for them or not though.

<comment><USER47> "bad decision" !== "worst decision"

</comment></comment></comment></comment></comment><comment><USER48> Very timely article. But I have been told to shut up and use Atom/VSCode/Slack like everyone else and upgrade hardware if software runs slow.

I find memory/cpu efficient applications not just useful but respectful to users specially when upgrading hardware is not possible due to financial or policy reasons.

<comment><USER49> We're also in an era when the speed of laptop and desktop CPUs has essentially stalled. Put another way, if our apps hog more resources there aren't necessarily faster machines we can buy.

<comment><USER50> Yes, this is extremely important to remember. The days of "who cares if we use a few extra bytes of RAM or a few extra CPU cycles here and there as computers will be twice as fast and have twice as much memory this time next year" are long over. And with the huge push for mobile and slim, portable computers, power efficiency is paramount as users really care about battery life. Yes, sure you can get a more powerful laptop than your nice, sleek, portable macbook air, but it's going to weigh 5x as much and the battery life will suck, especially if you actually use that power. People want to be able to use their CPU and RAM to run multiple applications efficiently, not waste it on a few laggy memory and CPU hogs.

</comment></comment></comment><comment><USER51> >But that's not abnormal for slack. In fact, slack often idles at 5% CPU usage. Whats it doing? I have no idea.

Probably something like this: [https://github.com/Microsoft/vscode/issues/22900](https://github.com/Microsoft/vscode/issues/22900) (not the cursor thing specifically, but something that feels lightweight, but isn't)

Which is probably fixable. I would guess Vscode is more code than Slack, and they were able to fix this, albeit with very good help from a customer.

</comment><comment><USER52> I think JavaScript is the new PHP -- it's accessible enough that people are going to be coding in it for the foreseeable future.

Chrome eats a lot of RAM, and frankly, most of these apps don't need all of Chrome. But any solution that requires moving away from JavaScript (e.g. C++/Qt apps) is too expensive in terms of retraining developers. (Facebook found it was cheaper to create Hack and HHVM than to train its engineers to stop writing PHP-like code.)

Maybe the answer here is a "React Native" library that results in native Windows/Linux/OS X desktop apps. But, with larger corps focusing on "mobile first" and "responsive design" memes, I don't imagine either Facebook or Google being the first to build such a thing.

</comment><comment><USER53> Electron is flourishing because of low barrier to entry like many already touted. But lets ask something [probably] more constructive?

I've made 3 apps with Electron that I could probably never make since I would be busy learning OS specific things.

Can we not have low barrier to entry for creating native apps? Are there any solutions/frameworks that one can utilize? Is it just a matter of poor documentation/support from OS makers? What is it?

Edit: Some of the contents that said something along the lines of: Is it really slow? It opens so fast for me...

The worse thing a developer can do is judge their application anecdotally and not through something more empirical. Its our job to make our shit available to more users and support more platforms (hence Electron is used) but it is also our responsibility to make sure they can use our app and have 50 tabs open and do other more important shit like... watching genitals in a flash player. I was in this Electron phase but I started to run traces and see how much of a hog it is.

If you really care about what you are working on, use Electron as a prototype, get it out there, then start making a native app. I think this is the best of both worlds. You get your shit out there, people let you know how it stinks and in the mean time you make something that is better suited for their OS.

P.S: Sorry for the overuse of "shit". I am fishing for upvotes.

<comment><USER54> So many up votes (thanks for taking the bait!)

But I really am wondering:

> Can we not have low barrier to entry for creating native apps? Are there any > solutions/frameworks that one can utilize? Is it just a matter of poor > documentation/support from OS makers? What is it?

</comment></comment><comment><USER55> > Also all you web devs: Go learn C or Rust or something. Your program runs on > a computer. Until you know how that computer works, you're doomed.

I can only encourage everyone to heed this advice.

<comment><USER56> Won't happen. All the signs point to more and more developers understanding less and less of what is going on underneath the covers.

If anything, we are < 50 years away from only AI and machine learning algorithms understanding chip design and microcode. Soon enough, no human is going to be able to parse the tech stack below the operating system.

</comment></comment><comment><USER47> The best perf improvement for slack is to disable animated images in the Accessibility Settings... this also removes some of the fun from Slack. I have suggested to them that they should have a setting to only play gifs when they're hovered-over, but still waiting on that to be implemented...

Other tips I've ritualized, use /collapse very often when on slack, and avoid message reactions with animated gifs. Animated things are why Slack will idle at 5%+. Lots of them and you're going to idle even higher.

Don't leave slack open on a channel where people frequently use /giphy or post lots of animated emojis (#random, etc). Reactions to comments with animated gifs are the worst, because /collapse wont hide them.

In my test locally, a chat window with no animated things is idling at 0-1.5% CPU. I just added 1 animated gif reaction to a comment and it's idling at 4-6%. It's absolutely horrible. I removed that comment and then posted using /giphy, now it's idling at 2-3%. A Slack Helper task started to run at 12%. Ran /collapse and both are back down to 0-1%.

Reacted to a message with 10 animated gifs, slack is idling at 9-12%. Slack Helper is at 26.9%. Brutal. Can't /collapse to fix this, either.

\- In Advanced Settings, just turned on "Disable Emoji Spritesheet" and slack is idling at 7-9%, Slack Helper at 27-30%.

\- In Accessibility Settings, disabled "Allow animated images and emoji" and Slack is idling at 0-1% and Slack Helper at 0-1%.

</comment><comment><USER57> 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.

</comment><comment><USER58> There are two totally different points mixed up in that blog post.

1\. Delivering your app with electron 2\. Writing a web app versus writing a 'native' app

Yes, delivering an app with electron might be subpar as it brings code to your computer which it probably already has. Most Computers which are targeted by electron apps already have a browser and lots of them have up-to-date chrome or firefox browsers which offer features very similar to electron. So I don't say there is no reason why one should use electron, but I urge every developer to make their web apps accessible to browsers too and let people use their browser if they want. Even offlines usage is no problem anymore as we have serviceworkers in the majority (by market share) of browsers nowadays.

The second point, however, is very poorly laid out in the blog post. Web apps do not have a general problem with performance as suggested by the article. Maybe some are badly developed but in the end, they are all backed by the tremendous efforts that were put into browser performance in the past years. The question if web apps can deliver the required performance was answered by the 60 FPS discussion a few years ago.

At the moment, the web is the only truly OS independent platform I know of. That is a very valuable feature and one we should treat with the deserved respect. So please write quality web apps and do us all a favor, instead of just choosing one specific platform. Yes, react-native is an option too, but I think it is a bit limiting to define just one framework as the one true way.

</comment><comment><USER59> Saying that "React and friends" are the good thing you want (without Chrome) is kind of nuts. React is insanely bloated for what it is, and it's also highly dependent on the bloated browser (and especially Chrome). React Native is an intermediary layer between a work in progress VM and JavaScript. So, we can't win there.

In a sense what we really want is for the browser to be an OS-level feature so that the browser-based-app is low cost, as is the case with chrome OS and you could argue was Microsoft's vision with IE. This is doable today if you write cross-browser code and wrap your web app in a platform-native web view, but then you lose the conveniences of Electron (cross-platform APIs to solve common problems such as menus) AND you have to deal with browser incompatibilities. All this to save RAM and 5% Of one CPU core.

Perhaps in an ideal world we'd have a lightweight VM with nice JavaScript APIs. The immediate problem we run into is that really fundamental UI gadgets, such as styled text fields and canvases, are not implemented similarly on the platforms we care about (Windows, Mac, Gnome, Android say), so we have to reinvent that wheel and before you know it you have another bloated virtual machine, except this one isn't battle tested and it only exists three years in the future.

</comment><comment><USER60> I have a couple of hobby desktop (macOS) applications in various stages of done-ness, which, if there were a low-effort solution, I'd like to port to Windows. Yet even with the business logic nicely separated out into portable C++, it's a huge pain. In the 10 or so years since I've done Windows, the development environment on that platform became totally foreign. C++/MFC seems to be dead and buried, now we have WPF (which is also going away if I'm reading things right) and C# and XAML and Windows Universal and all these layers of exotic technology I now need to learn and master just to get a simple native looking port of this thing. Screw that, I'll find something else to work on thankyouverymuch.

I totally see the pain and the burning need out there for a way to write something that works across the "big three" platforms that have grown more and more distant from each other over the years. But Javascript and a browser? Really, that's the answer? I'd even be willing to toss out my investment in Objective-C native code on macOS if I could keep my C++ business logic. Is Qt really viable? My understanding (again, maybe dated) is that a Qt application looks like a Qt application, not a native application. Is this still true?

</comment><comment><USER61> > Maybe we should be buying slower computers so we feel the pain. Facebook has > been internally intentionally slowing down their office internet once a week > to help build empathy with their users in other 3rd world internet speed > countries (coughAustraliacough).

Yep. I've just got back from spending over a month on a ship in the middle of the Atlantic, with two very flakey 256kbps satellite connections (capped to like 125kbps each as well). Shared between roughly 50 people. Our policy is to let anything through (it's a research ship, so being able to look up stuff on the internet is a must) but aggressively apply QoS rules and caching to the network. With the sheer amount of applications that assume they have a low- latency high-bandwidth connection which they can open hundreds of TCP connections on, just tweaking the firewall / bandwidth shaper / application control is a full-time job just by itself.

First observation, relevant to Slack: Before we locked down the firewall, Slack running on 2 laptops was by far the highest traffic application. Even though the few Slack users just had the client open but minimized - <USER7> actually using it. It was persistently using 20kbps, all day every day, until we blocked it outright. What the hell other stuff does it have to do other than download text!? Slack / other devs using Electron oughtta test their apps on extremely slow shared internet.

Second comment, relevant to Facebook intentionally slowing down office internet: The Mobile Facebook site (m.facebook.com) was by far the nicest to use on our severely degraded uplinks. No timeouts, pages took under 10 seconds to load, we didn't have to wait several minutes of blank page while another F%$£ing web font that's Arial but with the letter T slightly more aesthetically pleasing to download. No massively parallel loading of resources. Good use of caching.

It struck me that a lot of our problems were problems because devs never have to deal with that kind of crappy internet, it's not an edge case that gets tested. It results in people unable to load important stuff like Google, GMail, Outlook web app, and as such their products lose users. No matter how much we tweak our network internally, even restricting the internet use to a single computer doesn't result in usable web apps anymore. This is probably something that we share with third-world internet; a much larger market than our "research ship" niche.

Finally: People who put company logos in their email signatures hate other people. Base64-encoded PNG images make one-line email responses increase in size by like a factor of 100.

</comment><comment><USER40> Good someone pointed it out. The web hype has gone of the rails. We got perfectly good development tools for native development which works fine. There are lots of cross platform GUI tool kits too. They offer a better development experience, more dev tools and better performance and memory utilization. It is only because the world is drowning in JavaScript developers who don't want to learn anything else. They want to reuse their latest hipster framework everywhere.

They go on and on how terrible desktop development is, because hey it wasn't equally fast as JavaScript when they had never tried it. Newsflash it is slow and hard to do things you have no experience in.

As a counterpoint, I was able to create a mobile app with native tools for both Android and iOS in less time than it took me to create one in JavaScript. Cross platform JavaScript is highly overrated. It really isn't all that cross platform, often buggy and with primitive debugging and development tools.

</comment><comment><USER62> ...and you know what Flash did for the web when it came out?

Allowed us to watch videos, drag and drop, consume all kinds of media and have interactive applications on the web which were at the time totally unachievable with JavaScript.

Is the internet's memory so short that you've forgotten how recently we have largely switched to HTML5 video?

<comment><USER63> We've just spent the last 10 years spinning to get back to where we were, because Steve Jobs vetoed Flash support. Before that, we bailed on similar capabilities from Java applets, and had to reimplement them.

Doubtless there's multiple technologies before my time that gave us the same powers, but were abandoned because _reasons_.

</comment></comment><comment><USER64> The other day I read a blog post that argued how "Fight for the users" should be a core tenet for every developer. I agree; and, unfortunately, the main undercurrent of the defense of electron, at least in this thread, is one of almost complete disregard for the users.

Yes, most of them probably won't notice the performance impact. Most of them also don't notice whether their applications are insecure or overstep their privacy boundaries. It doesn't mean we shouldn't care about security or should build hidden trackers into all the code we produce.

That aside, Electron is just an ugly idea in general (obligatory IMO). I wouldn't want to run an entire browser just to run my own apps, next to the actual browser.

And I say this as someone who works almost exclusively in web development and who _likes_ javascript.

</comment><comment><USER65> If I wanted to make a desktop App work on Windows and macOS today, without using Electron, what are my options to build something very quickly that also include the benefits of Electron: self updating, app crash reporting, windows installers, no licensing fees?

<comment><USER66> react

</comment></comment><comment><USER67> Long time javascript programmers are the loser (if they never learned more than javascript) they don't know how to programming an almost perfect program. That is the reason why they using javascript on Desktop. The average programmer learns just one fucking language but being a good programmer you need at least to learn 2+ languages. That you can see the performance issues in your stack. I started with PHP and javascript while this time I didn't care about performance and now I'm a c/golang programmer. When I started to study c and golang I just released how bad the whole javascript stuff is actually.

<comment><USER68> Or maybe it has something to do with time-to-market for existing web apps, or other loserish things. No, can't be. You must be right. Especially because you know more than one language. After all, when you learn more languages, it makes your words more true!

<comment><USER67> Can you tell me why Microsoft and google trying to write either supersets or a javascript clone to replace javascript? Because that language is an issue itself. I don't know one good programmer who is saying that you need javascript to make real money or that language is awesome. This language is a bug nothing else.

<comment><USER68> Just because that tangential point can be made to appear valid in a different context, it does not mean that it is the proof to support your original argument. Sounds like you're primarily just upset about Javascript and/or front-end web technologies.

</comment></comment></comment></comment><comment><USER69> Meanwhile, we're still waiting for those "pro-native" people to give us better user experience.

I agree that Electron has its issue like having multiple copies of Chromium (and not Google Chrome).

Obviously native apps are better overall, but only if they provide a better UX. Being a vscode user, I don't know which native editor provides the same UX.

<comment><USER70> Emacs provides a better UX, Visual Studio (proper) provides a better UX, Sublime provides something close, although not as good. Slack's UX is incredibly basic. It's a couple of steps above a basic CRUD app. There are billions of IRC and XMPP clients ranging from toy to professional-quality, I use IRSSI, which is admittedly basic, but I find it hard to believe that there is no better native chat UX in existence than Slack's.

<comment><USER71> >Emacs provides a better UX

VSCode is clearly aimed at people who disagree with this statement. It's hardly a matter of objective fact.

</comment></comment></comment><comment><USER72> If you like Node.js and HTML/CSS, just have a node daemon running in the background with an HTTP server to your app! It's just like Electron, but without the CPU/RAM/Battery usage. You can even have binaries that stay open after a double-click and automatically open your browser to localhost:40023 (or whatever).

<comment><USER73> That's horrible and are not native at all.

<comment><USER74> So it's basically no worse than Electron.

Seriously, if browsers supported an app:// URL which just ran a local site with special privileges and allowed for some custom branding Electron would be dead overnight.

<comment><USER75> if they'd be giving you access to the complete node.js ecosystem maybe. With electron you can easily integrate native c++ libaries for high performance stuff or things that require hardware access. It's not like electron is just a webbrowser.

<comment><USER72> You can do all the C++ fast stuff you want on the server.

</comment></comment></comment></comment></comment><comment><USER76> Would it make more sense to distribute electron as a dependency and allow apps to use it? That way, instead of 10 apps requiring 10 different electrons we have 10 apps that can use a pre-installed electron.

<comment><USER77> How does an app bundling Electron in that way differ from an app using a native embedded browser widget (other than that it can run in Chrome vs. Edge/Safari/etc.)?

<comment><USER76> > using a native embedded browser widget (other than that it can run in Chrome > vs. Edge/Safari/etc.)?

I didn't know that was possible, do people do that?

<comment><USER77> Not too many apps do it, but it is possible.

[https://developer.apple.com/reference/webkit/wkwebview](https://developer.apple.com/reference/webkit/wkwebview)

[https://docs.microsoft.com/en- us/uwp/api/windows.ui.xaml.con...](https://docs.microsoft.com/en- us/uwp/api/windows.ui.xaml.controls.webview)

</comment></comment></comment></comment><comment><USER78> I fully agree with the author, only I'd call Electron the PHP for the desktop (it does help people get started quickly, at a cost).

There are working solutions for cross-platform native UI development and high- performance, slim code: [http://wiki.lazarus.freepascal.org/Multiplatform_Programming...](http://wiki.lazarus.freepascal.org/Multiplatform_Programming_Guide)

The problem is: most people don't bother learning new languages unless it's very easy (well, Pascal is!). I hope Go will have a cross-platform UI soon.

<comment><USER79> What does PHP have to do with this?

And Go already has bindings for QT which is a cross-platform UI framework.

This has nothing to do with people not wanting to learn new languages, it's just the time it takes to build an app. For you to build a QT hello world app takes probably 20 minutes worth of downloading, setup, and coding. To do the same you download electron, create an index.html with hello world and drag and file into electron, bam a hello world app.

The problem is desktop development is overly complex. React and modern Javascript make creating desktop apps using HTML/CSS with some combination of Javascript easy.

What we need to do is find a way to create a very slim browser that contains just an HTML/CSS to 2d context and a Javascript engine. Call it Electron slim and release that.

<comment><USER78> > _What does PHP have to do with this?_

It's the RAD choice for beginners since... ca. 1997?

> _For you to build a QT hello world app takes probably 20 minutes worth of > downloading, setup, and coding. To do the same you download electron, create > an index.html with hello world and drag and file into electron, bam a hello > world app._

Perhaps the first time ever, the 2nd attempt you will be equally fast.

Does a well-funded startup not have 20 minutes to test a platform?

As far as Lazarus is concerned: give it a try, it won't take 20 mins.

> _What we need to do is find a way to create a very slim browser that > contains just an HTML /CSS to 2d context and a Javascript engine._

Christ, no. There are no slim browsers anymore and it's a pitiful environment for native applications.

</comment></comment></comment><comment><USER80> Electron is a sub-optimal solution to the fact that desktop development today is _horrible_. You either have to write your app twice (or three times if you want Linux) or use Qt, which limits you to either C++ or this weird langauge/ecosystem nobody knows called Qt Quick.

Electron lets you write desktop apps that work decently well everywhere in a language you already know.

<comment><USER81> > use Qt, which limits you to either C++ or this weird langauge/ecosystem > nobody knows called Qt Quick

Hmm, PyQt would remove the need to use c++ if that is an issue.

<comment><USER82> Then you have to bundle and distribute Python, which is also a huge pain.

<comment><USER83> Distributing a PyQT app with PyInstaller is absolutely painless. It's a single binary and "just works", the interpreter is automatically bundled.

</comment></comment></comment></comment><comment><USER84> The electron bundle zipped without any extra app code is only 40MB. This is barely any bigger than the smallest of most iOS that get auto-downloaded to your phone every day. I haven't ever noticed any significant performance hits and I use Slack/Spotify every day. The problem you are speaking to is the same one that comes with any framework that is distributed. Any app using Swift 1.0 had to ship the Swift runtime with the app bundle until they eventually baked it into the OS and allowed sharing framework versions. The same problem happens with JVM if you've ever used a java app on Mac that doesn't use the built-in Java runtime. Its not really a concern to me, as I think this size is negligible and the runtime for Chrome is already the model of isolation so this just extends that slightly further. However I'm sure the Electron folks would be happy if you wanted to contribute to further the performance/usage requirements of the platform.

</comment><comment><USER85> Flash was a relatively slim runtime that enabled high performance applications; Electron is the polar opposite.

</comment><comment><USER86> I'm a big fan and total believer that deletion of few apps like Spotify, Slack and Atom could improve the performance of CPU. Recently I have been getting lags with my WebStorm for even firing up smallers commands like $ git status $ git log

I downloaded bunch of cpu profiler tools to observe how much CPU does spotify, slack and atom and also some other fancy react, electron app built apps take. Results are unbeliavale.....FYI: My Ram is 4GB with two 2GB slots. But after a complete cleanup and deletion of above troublesome apps performance is just amazing. I'm having a happy life with my WebStorm. I'm very positive that for my future node.js apps that is running nodemon would be fine too.

RIP Electron Family of Apps .

</comment><comment><USER87> I tweeted SlackHQ back in May 2016 about how Slack was using 17GB of RAM.

[https://twitter.com/NickPoorman/status/737647940026634240](https://twitter.com/NickPoorman/status/737647940026634240)

</comment><comment><USER88> I know I'm being completely naive but can all electron apps share one runtime (sorta like one browser with multiple tabs)?

<comment><USER89> Yes, they would simply link stuff dynamically (.so, .dll, .dylib files).

But everyone is using a slightly different version of Electron and macOS and Windows don't have a good enough package manager, so everyone is static linking everything.

</comment></comment><comment><USER90> Actually, there was a long running discussion about making a runtime mode of Electron, in order to address many issues: [https://github.com/electron/electron/issues/673](https://github.com/electron/electron/issues/673)

I also recently joined the discussion with a more general idea which I (partially) expressed here: [https://github.com/electron/electron/issues/673#issuecomment...](https://github.com/electron/electron/issues/673#issuecomment-292617796)

</comment><comment><USER91> I 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.

<comment><USER92> There is native support for Windows (from Microsoft), macOS, Ubuntu (from Canonical) in addition to the first party support for iOS and Android.

<comment><USER20> Thanks, I was looking for a linux version.

</comment></comment></comment><comment><USER93> That is why I do not use Slack for Desktop, and just keep a pinned tab of Slack open almost all the time. I also tend to reduce my usage of any Electron-based app because I want to better make use of my laptop resources in my development workflow requirements.

I feel like I agree with most what's said there, the same would apply to NW.js and the likes.

This should be a heads up for GUI developers to [re]consider Qt and QML. It made real progress in the last few months. and there are some nice bindings to it.

</comment><comment><USER94> I love how the latest generation of interest in a particular development area like UI goes down the road of reinvention thanks to the latest in thing or programmer prejudice. The wasted bandwidth is insane.

Somebody needs to write a variation of Sisyphus that turns the boulder into UI development. Suggest not spreading this web dev lunacy onto desktop. The issue has already been solved with reasonable solutions for 25 years. Desktop development, automatic software updates, all that stuff.

</comment><comment><USER95> The best way forward for Electron is probably to get a very thin, light core instead of the current Chromium-based one. Even on a good 16 gigs of ram and an i7 you feel Electron-based applications' effect on a system.

If you want a compromise between easy multiplatform desktop app development and not wasting resources, the ideal way there may be something like Microsoft's React-based desktop framework that they just released. (in my opinion at least)

</comment><comment><USER96> People grew up and stopped using Flash, slowly phasing it out. If Electron is as influencial as some comments here seem to think it is, the big players in the desktop market will (hopefully) step up and put together new APIs and tools which fill the gap Electron is currently filling. And they'll do it all natively and without the terrible bloat, poor productivity and bad accessibility that Electron currently brings to the party.

</comment><comment><USER97> I've slowly started to remove Electron apps from my workflow. I used to use Atom, but I've switched to an paid for Sublime. The last two apps I have which use electron are Hyper and Slack. Hyper could go, but I really like the interface and Slack probably isn't going anywhere.

Real-time update:

I just checked Activity Monitor and Hyper is leading average energy impact followed by Xcode. Looks like I might be switching back to iTerm this weekend.

<comment><USER98> What is the draw of Hyper over iTerm2?

<comment><USER99> It runs Javascript! You can tune and theme it with CSS and JS!

That's actually the biggest selling point. I couldn't imagine using Hyper: I open terminals very often and waiting for Chrome to load when I need to just run a command would be very exhausting.

</comment></comment></comment><comment><USER100> Is there a Servo + WASM based alternative to Electron yet? Would it be more effective?

<comment><USER101> I won't touch these kind of apps until Servo is here, with 60 FPS animations. If they can deliver that it will be a game changer.

I find disgusting that Electron (or even UWP apps) can't do that on PCs with high-end hardware. A simple laggy fade effect on a modal and my eyes start rolling to the back of my head.

</comment></comment><comment><USER102> So when are we gunna start seeing Web Assembly targeting Electron and go full circle?

</comment><comment><USER103> Electron has its place, but I'm not entirely certain touting Electron-powered text editors is a satisfactory success story. The success story is on the business side, IMO: it is another write once, deploy everywhere mechanism. Text editors are a very personal choice, but if I had to choose between an Electron-based text editor or Emacs in say, a developing world context, Emacs would win every time because re-purposing a 5+ year old laptop that only gets power from a solar panel is feasible with Emacs, at the cost of a steep learning curve. There are always tradeoffs.

Electron is very suitable for the particular contexts that it fits within, and OP made some salient points that there are some settings where it clashes with user demands. For the paying market that say, Slack cares about though, they are not sensitive to the tradeoffs made to run Electron underneath to the point that it hurts Slack's revenue to a level Slack cares about. This opens up an opportunity for someone else to step in and take the niche that Slack has currently declined to occupy, and that's not a bad outcome.

</comment><comment><USER104> I always thought Electron was a great idea, but it definitely seems like something that should only be used for prototyping.

There's some excellent software that uses it, but using the Chromium browser as a runtime is a dirty half-measure. I hope they're trying to pare it down in future releases and make an effort to utilize host-OS resources.

The less your code is doing, the better!

</comment><comment><USER105> Just reminding everyone that Telegram (a self-funded company, also a messenger) builds cool NATIVE clients for all platforms.

And Slack (a company valued at $4 billion) writes some intern-level Electron apps.

This comes from a desktop dev living in Europe (also frontend dev, backend dev, "you name it" dev).

This goes to you bay area folks, you hipster-coders, JS-framework lovers ;) No offense.

</comment><comment><USER106> I get the idea of Electron Apps having some hate for the performance. I mean if I have to open a large SQL file (> 250MB) and compare the performance between Atom and Sublime... well the difference will be day and night.

But there are a few differences between Flash and Electron that are not small. I mean the first thing is, Electron is open source in a open Standard, and have a fast development cycles to fix performance and security issues.

I think it's like a PHP situation. Electron is easy to use and sells itself as a cheap way to build apps, so this attracts lazy developers so we have a lot of problems, but that doesn't mean the technology is bad. But this is not a Electron problem, I mean web pages right now are heavy and slow for nor real reason. We need better fron-end developers.

I love VS Code, Hyper, and others, so maybe I'm biased, but I think Electron will be a interesting option to make desktop Apps something again.

<comment><USER107> > but I think Electron will be a interesting option to make desktop Apps > something again

For most of the computing world, desktop apps have never stopped being a thing.

<comment><USER106> Sorry I was vague, and yeah you're right they have never stooped.

I was thinking more in the Hype thing for new developers. You know like a small Renaissance in the Desktop UI/UX deparment, you know would be cool see beautiful desktop Apps in sites like Behance, Dribbble, etc spotting the first places, instead of the classic App with default OS UI or weird adapted ports of Mobile apps.

</comment></comment></comment><comment><USER108> All nice comments from the author. Good ideas, except that most of the time these should come from upper-management: security and performance? They are additional features. We'll bother with them later.

Lots of developers have great ideas when they are given space, meaning when it's in the "sprint". Some developers simply don't know about the existence of benchmark tools, etc., but, by experience, many of them know how to google.

What matters is 1) time-to-market, 2) it's swooshy enough, 3) it does what it's supposed to do.

I may also completely wrong: it's not always management to be bad here. Sometimes, it's a "bunch" of people who think they are doing the right thing (like choosing a technology instead of another). Management can't always be blamed for it (of course not) - especially when one of the people choosing is trustworthy.

</comment><comment><USER109> Flash used to work on the desktop as well, they had this little "projector applications" iirc

<comment><USER110> You could "compile" your animation as an executable file, as well as an SWF file.

<comment><USER111> you still can, it is called a "projector", you basically merge the Flash Standalone player exe with a SWF into one executable.

</comment></comment></comment><comment><USER112> For something like a music player maybe electron it's not the best choice. But Slack might have several features where they need to parse and show html. Also, they're probably using webrtc for calls. On top of that, they can reuse most of their code which is a web app. That means less bugs and if they fix a security issue in the web app they also fix the desktop/electron app.

I wonder why the author doesn't just use the web app in chrome. The notifications works pretty well.

Personally, I prefer the performance penalty and enjoy apps in Linux than having great desktop apps that only work on Windows and/or Mac. It would be great to not have to choose but we all have limited resources and Linux often doesn't make it in native desktop apps.

</comment><comment><USER113> Why would anyone use electron for an app that requires being constantly online - just use the site?

</comment><comment><USER114> On macOS, the alternative would be to use Fluid[1]. You can build mini-apps from a lot of websites and the footprint is very little. (No affiliation, just a happy user)

[1] [http://fluidapp.com/](http://fluidapp.com/)

<comment><USER31> Unless I'm missing something, isn't that just wrapping the webpage in an embedded WebView? If so its basically doing the same thing as electron, except using Safari instead of Chrome and not giving the app any native API access.

This helps in 2 ways:

\- Safari is less of a resource hog than chrome

\- It avoids the huge 380 meg download of electron

But it doesn't solve the runtime problems. The app is still running inside a VM (safari), so its still going to be way slower than its native equivalent and it'll use way more memory. Also in a real browser background tabs get throttled in dozens of ways. But I bet none of that throttling happens via Fluid, because even background windows can be visible at any time on macos.

I'd be curious to see a quick comparison of CPU and RAM usage of slack-for- desktop and slack-in-fluid if anyone is willing to give it a whirl. I'd do it myself except I deleted slack after writing that blog post.

<comment><USER115> Slack with Fluid: 1 process, 208 MB.

Slack Electron: 4 processes, 56 MB + 355 MB + 64 MB + 29 MB = 504 MB

This is after signing in to one team, (janky) scrolling through a couple of channels and running for a few minutes.

</comment></comment></comment><comment> c-smile Just in case: FreeConferenceCall / StartMeeting ( [https://www.startmeeting.com/spring-2016-updates](https://www.startmeeting.com/spring-2016-updates) ) is using Sciter ( [https://sciter.com](https://sciter.com) ) for their UI.

This app provides video communication, screen sharing and chat so is comparable with the Slack, Skype and others.

Sciter core is a single dll of 5-8 mb in size (StartMeeting uses it as a static library ).

Sciter does not create any processes or even threads (modulo HTTP client that uses thread pool). StartMeeting runs the same UI on all supported desktop platforms: Win/Mac/Lin.

</comment><comment><USER116> Electron as is, consumes relatively more resources than QT and it's obvious because uses Chromium under the scene. But this is not the only reason for a slow electron based program. Code is the most important thing in any application and it's the primary cause of bad performance. A well writen and optimized application will have a good performance, no matters on which platform is based (good ones, obviously). "Electron is slow" is like "Java is slow" right now. Do you want a probe of a well writen electron app? Check VS Code; it's fast, it have a good performance and consumes a lot less resources than Atom, for example.

</comment><comment><USER117> yeah yeah. It's bad. So big. So slow. So bloated; so... What's your alternative?

I don't see any meaningful suggestions in this article, just complaints.

You don't like how resource intensive electron apps are? Well, don't use them. If its really a big deal, people not using the apps will inform the people making the apps that they're bad.

That's not happening, so clearly it's not a big deal for most people.

Still... things could always be better in a perfect world.

Are you building desktop applications? What are _you_ using for it then, and whats your cross platform perf story like? How long do cross platform releases take you? What are you paying for your tools and tooling?

<comment><USER118> The alternative mentioned in the article is React Native, which runs on iOS/Android/Ubuntu/OSX/Windows.

Another lightweight alternatives to Electron are: Mozilla Positron ([https://github.com/mozilla/positron](https://github.com/mozilla/positron)), Webkit for Android/Windows ([https://github.com/daewoong-jang/webkit- android](https://github.com/daewoong-jang/webkit-android)) and Qt Quick ([https://www.qt.io/qt-quick/](https://www.qt.io/qt-quick/)).

</comment></comment><comment><USER119> _Sure! You say. Disk size is cheap you say!_

Here's some irony for you: You really need an SSD in a modern PC - <USER8> because of exactly this sort of insane bloat - and as a consequence, _no_ , disk space isn't so cheap anymore.

</comment><comment><USER120> On Windows I was a huge proponent of Chrome's "save to desktop" feature, which basically gave me the same experience of a native app (separate window, no window chrome, pinnable to start and taskbar, notifications, links open in separate window, etc). I have recently switched to Mac and I miss this feature so much. I have found [https://applicationize.me/](https://applicationize.me/) but it's not seamless as "save to desktop". I wonder why they dropped it from the Mac version of Chrome...

</comment><comment><USER121> From what I understand, a barebones JS-on-desktop framework at minimum needs blink, V8 (or equivalents) and some custom bridges to provide native APIs to JS, right?

Which one of these is the resource hog?

</comment><comment><USER122> Very late to the conversation!

I'm not going to offer an opinion, but just anecdotal evidence. We don't use Slack, but since we have Office 365 I was tasked with evaluating if Microsoft Teams was something we should start using instead of Skype, etc.

I have advised to wait. I was seeing similar metrics to what OP is describing where the Teams Client was using 200+ Mb of RAM (many times more than VISUAL STUDIO).

Also the UI seemed laggy. I'm not 100% sure it is Electron, but the installer and interface seemed as much.

</comment><comment><USER123> tl;dr: Everybody wants native apps, but nobody wants to write them.

</comment><comment><USER124> I would prefer progressive web applications, which are stored in a cache and run in the available "browser" of the system, might it be Chrome, Safari, Firefox, or Edge.

</comment><comment><USER125> Good article. I've almost always had slow computers... My current cell phone is faster than my netbook, with more RAM too. So I know the pain. So please give everyone a break. My internet access isn't crap either, but when browsing the web is painful to the point where the only thing running on your 'desktop' machine is the browser, there's a big problem. Not only the machine, but developers' mentality.

</comment><comment><USER126> I disagree with the "flash" sentiment. The biggest disadvantage of Flash was and is that it's closed-source. Which means it's likely _still_ filled with exploits waiting to be exploited. Also, it could not be ported to any other platform by the community.

Electron, on the other hand, is open source and can be built for a wide variety of systems and CPU architectures, as well as it can be audited for security issues.

</comment><comment><USER127> There is competition, for example between Slack's electron app and their website, or between Sublime, Atom, and VS Code. It seems like the author of this post doesn't trust users to choose memory usage and battery life over other things.

I expect that's correct - they are sometimes less important to users than other things. Emacs is tiny now, but at one time it was considered a memory hog and people kept using it.

</comment><comment><USER128> While I love Node.js and its environment, I totally agree with this post. I don't have the Slack client installed for this reason and only use Electron when I write code. React Native seems like a nice middle ground: Javascript, but _compiled_ to native.

PS, I notice that the author is using Ghost for the blog, so I am guessing the author is in the same line (like Node.js but not Electron).

<comment><USER129> Not sure what line that is but Ghost's desktop app is definitely Electron. For the record, it was also built handedly by one open source contributor (Felix Rieseberg) and absolutely would not exist if not for Electron.

<comment><USER128> Cleared up (I hope)

</comment></comment></comment><comment><USER130> There actually is a Flash for the desktop. It's called Adobe AIR. And it suffers from the same CPU/energy hog problems.

I do wish big, well-funded companies would invest is proper native apps. I get that making it easy to crank out cross-platform apps has benefits, but is it really too much to ask for nice native implementations of our most important tools?

</comment><comment><USER131> There was some effort in the past to allow browsers to provide desktop app- like experiences for webapps. Progressive Web Apps are doing similar, though the target is very strongly toward mobile. It would be more efficient for disk space, though likely not CPU/RAM, to just make webapps be able to work more like desktop apps.

</comment><comment><USER132> It seems to me that there is not much to worried about ... it is an ecosystem ... things would naturally evolve ... if electron happens to consume too much power n conserving power is an important concern ... the developers will need to do the right thing .. otherwise the app developed will not get used by that many ppl ...

</comment><comment><USER133> Lately I've been playing around with Red language and their view feature. Easiest way I've created an interface before. The Red language is really interesting and cool, but their view construct is the coolest. If you haven't played around with it, it's worth about try at least.

</comment><comment><USER134> When I profile Slack on x.slack.com, it seems to be pretty good about being "idle". The flame chart is mostly empty. As the article also points out, I think this is a problem with Electron/Chrome. Just want to be sure the Slack devs get their credit here.

</comment><comment><USER135> I understand why you'd want to wring every last efficiency out of your computer, but I run Slack, Spotify, and many windows of VS Code on my bottom of the line MacBook all day, frequently on battery power, and don't have a problem. What's the big deal?

</comment><comment><USER136> Btw, I can tell you exactly what the "Preventing Sleep" is all about. I'm 100% positive there's a bug in Chrome's WebRTC stack that causes that to happen.

Fire up Chrome, doesn't happen. Go on a Hangout, yip "Preventing Sleep".

<comment><USER137> But... isn't this correct? I wouldn't want my machine falling asleep while on a conference call, so preventing sleep is a good thing?

<comment><USER138> I'm pretty sure GP is talking about CPU low-power state like OP did, not OS sleep. They're entirely different things.

</comment></comment></comment><comment><USER139> This guy compares electron to react native...totally invalidated his opinion, in my eyes.

</comment><comment><USER140> I think Electron is really great for developing an MVP. But yeah, Slack should probably build their next version with Visual Studio and Xcode the way Microsoft and Apple intend for people to build apps for those platforms.

</comment><comment><USER141> So minimize your use of the Electron APIs. And then when someone releases a leaner Javascript runtime, port to that, keeping 90% of your application intact.

This would be a good idea even if Electron didn't have these problems.

</comment><comment><USER142> I'd take this a step further and posit that JavaScript is the modern equivalent of Ethernet (the original protocol): simple enough to actually work despite all its shortcomings, hence doomed to success.

</comment><comment><USER143> > _I just ... don 't care about your app enough to justify running more chrome > instances_

Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then?

Electron has won out because key apps have opted to use it and decided that the trade-offs of user CPU and battery are worth some amount less than their productivity as developers. Yes, there are alternatives to developing native desktop apps in JavaScript (I'm not sure I've seen React Native used this way, but it probably exists somewhere out there.) People opt for Electron because it's holistic, battle-tested and easy to use.

I'm not excusing Electron's (many) flaws. There should be a concerted effort by the team to "disable" parts of Chrome that don't make sense for native apps, or at the very least let it be configurable. He's right, there's no reason Slack should have access to the GamePad API (or WebVR, etc.)

My overall point is that like everything, productivity of the end-user is always going to have some kind of trade-off with the productivity of the developer (or more specifically, the business considerations of the company.) Always. We don't write assembly anymore even though the apps would be a gajillion times faster than writing Electron-wrapped web apps.

Now, complaining that Electron/Slack/etc. are CPU/battery-hungry is completely valid and a good discussion to have, but you only get me to jump into the HN comments once you start delivering global developer edicts with no regard for the other considerations those projects have made.

> _The other sad fact is that even most developers have no idea that this is > even happening on their computers. They run slack but have no idea how > hungry it is. As a developer its your responsibility to know this stuff._

I'm not sure I completely agree here, "responsibility" is a bit heavy of a word.

> _Users: Please complain more about slow programs. Its 2016. We carry > supercomputers in our pockets. Its simply not ok for apps to be sluggish._

Wait, this is the first instance (edit- second, but mentioned in passing in the previous paragraph) the author mentions "sluggishness" as a metric. IMO sticking with measurable stats like CPU and battery life are better because you have no idea if someone other than yourself experiences or even perceives this sluggishness. What about non-developers at BigCo that only run Chrome, Slack, Spotify, and Word? Would they feel sluggishness? I would guess not, since I rarely experience it as a developer on a Macbook using Chrome, Slack and Atom. (Things only get dicey when I start doing Vagrant stuff.)

> _Also all you web devs: Go learn C or Rust or something. Your program runs > on a computer. Until you know how that computer works, you 're doomed._

Doomed to have a successful career? I prefer being "doomed" then. (For the record, I do know

> _And until then get off my lawn shakes fist._

Aaaaand there we go. Maybe next time don't bury the lede? :P

> _Oh, and read this talk on the website obesity crisis. Its very funny. And > very sad. And very true._

This is an entirely separate concern (and one I agree with.) Heavy web pages are heavy because they are multi-megabytes to download, not because their "installed" wrapper (Chrome) is hundreds of megabytes.

<comment><USER144> > Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then?

I read Slack in emacs. I write code in emacs. I browse the web in emacs & Firefox. I play music via my phone's native Google Play Music client, although if I wanted to I could use emms, an emacs music-playing mode.

I have no desire to run some GUI-only, CPU-hungry, memory-ravenous, of-the- moment JavaScript nightmare of a program. _My_ productivity as a developer is hindered by those things. I have no desire to write JavaScript: I'd rather write Lisp, or Go, or Python.

Yes, it's possible — and preferable! — to uninstall Slack, Atom, Chrome and Spotify. Try it today.

<comment><USER145> I find it interesting how many devs I have met in the last few years who seem so tied to GUI's... as a sysadmin who lives mostly on the cli, I never understood it.

Side note; many of said devs also used OSX instead of linux, maybe some correlation there.

Emacs is where it's at. Really, it's my main operating system. Email, org- mode, erc for IRC, RSS reader, editor, twitTER, eww (for some things like documentation), dired for folder management etc. Currently working on learning ledger.

"Using a free version of vi is not a sin but a penance."

</comment></comment></comment><comment> richsu-ca I get < 1% CPU usage when it is idling on a Windows 10 desktop. Will check later on the MacBook Air and see what I get.

Memory used is 71 MB Total no. of processes: 5

Measured using Windows Sysinternals - Process Monitor.

</comment><comment><USER146> You'd think they'd afford a Mac & windows developer.....

</comment><comment><USER147> I even got more used Slack memory than the article's writer: [https://imgur.com/a/AQGYD](https://imgur.com/a/AQGYD)

</comment><comment><USER148> I just noticed this morning that VSCode has started causing my MBP's fans to spin up whenever I type in it. I spent about an hour updating my MacVim setup to replace it.

</comment><comment><USER149> Flash player was A pretty minimal download and was not a resource hog. Shitty punch the monkey ads hacked together by people who couldn't program were the CPU killers

</comment><comment><USER150> Isn't it more like Adobe Air with JS instead of AS?

<comment><USER151> The analogy is _extremely_ weak. At best, "flash" is a stand-in for "bad performance".

<comment><USER152> The funny part is flash and air have way better preformance than html 5 and electron.

</comment></comment></comment><comment><USER153> What strange things to want to be in 2017. "Desktop" and "Flash" are not exactly hot spaces or desirable technologies.

</comment><comment><USER154> I didn't realize react-native could be used on the MacOS desktop. Anyone have experience with it, is it ready for prime time?

</comment><comment><USER155> Is being "Flash for the desktop" considered a good thing?

Wasn't AIR Flash for the desktop? And didn't that already flop?

<comment><USER111> considering Adobe MAX 2016 Resources about 8 Billions AIR Applications installs, I would not call that a flop

see here for more numbers and details [https://discuss.as3lang.org/t/adobe- air-by-the-numbers/476](https://discuss.as3lang.org/t/adobe-air-by-the- numbers/476)

</comment></comment><comment><USER156> How is "We carry supercomputers in our pockets. Its simply not ok for apps to be sluggish." not a non sequitur?

</comment><comment><USER157> I tried Hyper, listed in their "apps made with Electron" gallery thing. lol 250 megabyte fancy command-prompt

</comment><comment><USER158> Good to see I'm not alone, I've been complaining about this "bloat" and mindset for ages.

</comment><comment><USER159> Electron exists to allow JS devs to bypass browser vendors slowly coming to agreement on new features.

</comment><comment><USER160> Computer resources are like a budgets. It doesn't matter how much you get, it will all be used.

</comment><comment><USER161> Or you could use Chrome Apps, i.e. a desktop shortcut which opens a web page in a separate window.

</comment><comment><USER162> Spotify runs at less than 1% for me but maybe that's because I don't own a crapbook

</comment><comment><USER163> Electron is amazing. It's the best thing to happen to desktop since I can remember.

Yeah it makes slow apps, but these apps wouldn't be possible otherwise. It's perfect for prototyping new exciting ideas, it's fun to use, and there's no alternative.

When your app get super popular maybe you should rewrite it in gross native code though.

</comment><comment><USER164> Election really is flash of desktops, just use 3-4 years old hardware to feel the pain.

</comment><comment><USER165> Shipping the prototype is hardly a new problem, this is just the latest iteration.

</comment><comment><USER166> "It would take 450 floppy disks to store these three simple apps."

</comment><comment><USER167> "The modern web makes me want to throw up", "Electron is flash for the desktop", "Databases have failed the web" — wow... author does not look very happy with the state of the web development today.

</comment><comment><USER168> It's not Flash, it's the new Visual Basic 6.

</comment><comment><USER169> I thought director was flash for the desktop?

</comment><comment><USER170> So. Where is the html5 of electron apps ?

</comment><comment><USER171> Look at WebAssembly, then consider...

</comment><comment><USER172> In most cases it's either an Electron app or no desktop app at all. It's simply not feasible to write native apps.

<comment><USER173> 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.

<comment><USER172> No one would bother writing Electron app if there was no demand. Most users, (even tech savvy users) prefer using Electron Slack instead of keeping the webapp open in a browser.

</comment></comment></comment><comment><USER174> No mention of Adobe Air? :)

</comment><comment><USER175> Better than JRE based ones. They eat far more memory and are slow and often buggy.

</comment><comment><USER176> So many divisive opinions here, but in case anyone reads this far down, here's my 2 cents:

\- Yes, desktop apps existed before Electron. But the top comment is right. How many desktop apps. _NOT_ utilities but full featured apps (like Spotify and Atom) that you loved either got swallowed up by other companies (Mailbox) or discontinued due to "lack of use" (read: lack of profitability). I'm sure if you dig deep you can remember quite a few...

I'm a game developer with a background in C++. But I'm developing my company's prototype in electron. This is because I can do it myself without needing to tap a bunch of people to help and find funding. I can bootstrap. Electron allows this and it's incredible. I couldn't make a cross platform game engine in a year on three platforms using native. Maybe you can and you're just a better human/coder than me (but seriously, email me in a year with your progress!) but Electron is allowing it.

What does this allow? This allows me to release a product (yay) and maintain a product easily (double yay!) and when you guys don't throw money at me.... I can KEEP maintaining it because of my low overhead. With native code and a staff of 20 I would be forced to shut down the product.

THAT BEING SAID

If the game does well? I'm not only using Electron, I'm using React (yes, it's a game. Yes I know, I've had this discussion. I'm crazy) so the next step is to port it to react native on the desktop and remove the Electron dependency. Totally doable since Microsoft is supporting it on the Univ. Windows Platform ([https://github.com/Microsoft/react-native- windows](https://github.com/Microsoft/react-native-windows)) but macOS? Someone's working on it but it's of course not apple ([https://github.com/ptmt/react-native-macos](https://github.com/ptmt/react- native-macos)). Ubuntu is on top of shit though ([https://developer.ubuntu.com/en/blog/2016/08/05/introducing-...](https://developer.ubuntu.com/en/blog/2016/08/05/introducing- react-native-ubuntu/))

I can't speak for Spotify or Slack or any of the people mentioned (yes I know Spotify isn't using electron) but for a small company of 1 and a half people Electron is allowing innovation and project completion in a way that nothing else is for me. It's a great door to open to allow future optimizations. And hey, maybe Electron will slim down too... give it time. Remember how bad Windows development was? No? I do. But .NET has come a long way, maybe electron will too. If not, we can always port!

<comment><USER177> Why not use Unity instead?

<comment><USER176> Mainly two (honest) reasons:

1) After years of C++ in games, I've written a lot of JS. I believe in where the language is going and I saw an opportunity to use JS to write a cross platform 2-D game engine with low overhead and went for it

2) Unity lends itself very well to 3D games in my experience, or 3-D games with a fixed camera to look 2D. So this would likely lead to overhead involving "Well, let's just render the 2-d components in 3-d" which easily spirals into needing a modeler, a rigger, an animator, a concept artist and a programmer MINIMUM to run the game. As it stands now I need a 2-D artist and a single dev.

Oh, I lied:

3) I can't create a business as easily marketing a unity mod than marketing a stand alone FOCUSED engine on one type of game. But if my plan fails, I can still write a unity renderer for my game since most of my logic is serverside and platform agnostic. So who knows! :)

</comment></comment></comment><comment><USER178> So much this.

</comment><comment><USER179> I don't get this article. What does the author propose instead? Cross-platform is tough to get right and it places much burden on developers focusing on application logic for his niche.

I don't think it's fair to label Electron as Flash just because it's doing things in the background that Chromium authorizes. We know that Chrome Browser and it's underlying technology is in use everywhere and anyone can open it up and take a peek or embed Chromium in their C++ projects.

On top of that Electron takes care of cross-platform issues, and it's performance is under constant iteration by Google, so you have a much better chance of getting to market without having to do the plumbing work.

While I share the concern that Electron seems to spin up fan on my Macbook, it's quite rare that I don't think much about it.

If anything, Electron improves desktop user experience by leveraging web technology. I shudder to think what Slack will look like if it was done with Java Swing. But in some HN'ers mind, that is the "right" way of building this world. I see a big split in thinking amongst the demographic well marinated by Java Is Everywhere (TM) vs Javascript is Everywhere.

</comment><comment><USER180> I wonder how a JS/HTML desktop using the Adobe AIR runtime would compare.

<comment><USER181> heh, speaking of Adobe Air, I remember Air based twitter clients running smoothly on my Eee PC 900 (single core Celeron 900 MHz!!)

</comment></comment><comment><USER63> I'm surprised to see so little mention of Java as a cross-platform native app platform. Maybe I'm just old enough to remember coming up though when Swing and AWT were the next big thing. Nowadays, IntelliJ and it's derivatives are all Java-based, and pretty popular and performant.

I love getting a chance to get out of web-dev world and go build some ugly tools with WinForms from time to time. You have to do more work yourself, but there's so much less magic involved.

<comment><USER182> To continue in the Java vein: weren't Eclipse SWT & RCP supposed to be the ultimate answer to native cross platform UI development in Java?

I had no experience with them: did they gain some adoption or recognition at least?

Maybe all cross-platforms app solutions are just doomed to stagnate, at least until the next hype one rises, after all.

</comment></comment><comment><USER183> it's a stop gap will WASM is used for both desktop and web.

</comment><comment><USER184> Most 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.

</comment><comment><USER185> It's not flash for the desktop, the author just wants to say something mean about electron cause he's angry.

The flash analogy doesn't hold in any way. "Well, flash was errr ummm BAD you know.... and this electron thing it's BAD too .... err umm SAME AS FLASH!

Grumpy grump just wants to yell and stomp.

</comment><comment><USER186> I am a young programmer, student, front end developer/designer, with some knowledge of languages such as java, php.

I am developing one electron app, and it is going great. And I don't even know javascript that much. But in my case, usage of browser engine is essential, since it has to do with rendering HTML and so on. I have less than 1000 lines of javascript and almost everything was working after 2 weeks.

It is not that big of a project anyway, but from the begging I knew that it should be fairly easy and doable.

In fact, I can imagine that I could do so many kinds of apps with electron, and I can easily see how I would approach it.

Let's say music player. No problem. I believe that electron can easily play media, and it would all look great. Or some productivity tool, or note taking app. Working with files, editing text files, even viewing documents like .pdf would be easy (would just use some plugin). Or even embedding youtube videos in notes would be easy. And all that with easy control of layout and great rendering of fonts and images, plus animations.

With little knowledge of front end stuff, and some general programming principles, you can already see how you could build app on the top of electron, which is a platform everyone here knows without even trying. It makes me feel kind of powerful to be able to do such a nice apps myself.

<comment><USER186> but if there was something exciting like red-lang with easy to do custom UI ( if needed ) and with some ecosystem around it, i would definitely look into it

[http://www.red-lang.org/](http://www.red-lang.org/)

</comment></comment><comment><USER187> Holy shit! Are we behind reddit on this? [https://www.reddit.com/r/programming/comments/64oqaq/electro...](https://www.reddit.com/r/programming/comments/64oqaq/electron_is_flash_for_the_desktop/)</comment>