Ask HN: Do you think Electron is good for building Desktop Apps?

67 points by david90 ↗ HN
At Oursky, we built several apps with electron.

We find that it's easy to set up, you can use npm packages. Yet the build size is quite big and it might not support all native features. What's your thoughts?

165 comments

[ 2.6 ms ] story [ 205 ms ] thread
I agree, Electron apps are way too big. They include so much cruft whether you use them or not.

I prefer to write apps with separate server and client parts and the client JS/HTML is generated by in-house tools and thus is a fraction of the size of anything that would uses any of the popular frameworks.

In any case, I'm finding that WebApps are easier to deploy and update than writing for native deployment. In the rare cases that I do need native features, I can deploy a local server which can then access whatever I need. The clean separation of concerns between client and server does simplify architectural design.

Is anyone aware of a unificate resource from where to learn about all the limitations of a local webpage versus a served webpage?
It makes it easier to get started, and you can often kinda-ish reuse some effort from your webpage at the cost of bad performance and non-native look/feel.

It's a trade-off for me, I use it when the trade-off feels right.

MVP: Yes. Production, complete products: No.
I'd say Electron is "good enough" for many purposes, meaning its advantages overweigh the disadvantages. Lower barrier to entry compared to native solutions, developer productivity, cross-platform sharing of code.. Plenty of large companies use it to build (even flagship) products.

The disadvantage that is most talked about is its final bundle size, and I'm not aware of any developments that are trying to solve it. I'm in a project with a number of Electron apps built and in the pipeline, and we're searching for a potential in-house solution, of a central app that hosts/downloads/embeds "mini-apps" that run on the same foundation, to share the same Chromium run-time. Really hoping for a community solution to this though.

There is an issue on Github with the idea of creating a runtime for Electron: you would only need to package your apps and a shared Electron runtime would execute the different app you have installed on your OS, a la Adobe Air.

https://github.com/electron/electron/issues/673

After seeing what disasters Adobe Air, desktop Java, and Flash have been, why do people think that they suddenly can do better?
Because progress comes after many dead ends.
Thank you for the link, the whole thread was very informative, for the various ideas being weighed and some kind of consensus forming as to the proposed solution.

It got a bit daunting to see in more detail the potential complexity of the problem. Someone noted in the comments here, that there have been countless attempts at solving this "shared runtime for cross-platform apps" idea, apparently with a still unsatisfactory history.

Reading through the thread does give me hope, since the discussion is on-going after 2+ years, which means people are interested in an efficient solution. Seeing the HN crowd go at this Electron topic again and again, always with a kind of emotional "turbulence", implies that this is a worthy problem to solve.

I like that one of the recent suggestions is to "split the Electron", to accommodate bindings with theoretically any language.

Define "good" :)

If you need to have a desktop app quickly (for multiple platforms, even) and it's the difference between launching something or not, then yes it is good.

If memory footprint and performance is a critical part of what you're doing (it's not always), then maybe you should look at a different technology.

I think Electron has allowed a lot of cool things to come into existence that wouldn't have if not for Electron.

good in that it the easiest option for moderm developers to get something done? yes. but it is horribly inefficient and we the industry should provide a better tool than this nonsense
> easiest option for moderm developers

for modern [web] developers.

Contrary to what one might think by reading tech blogs and HN, developers come in more varieties than just "web" and "wizard".

Much better than many native libraries. I added some extra node modules for some specific calls I needed and it went smooth. I'm now converting a second desktop app because it went so well. What disturbs me the most is the numerous process launched. Neither of them really big. I learned that it's also a benefit. not having total scope of a desktop app when you embed HTML+Javascript from uncontrolled sources.
I built Collate (https://collatenotes.com) with Electron and I'm a huge fan. Electron does has its downsides but I think that it's eclipsed by the upsides. For collate, those upsides are:

1. Ease of building and distributing packages with Electron-Builder. I'm able to build for all three operating systems on my Mac, took a few hours to set up.

2. Access to the vast NPM library for all sorts of functionality.

3. Ability to use CSS libraries for styling. I'm no designer so it saves me some time. Collate uses Bulma for styling.

From what I've seen, users are more than happy to have an application that solves their need no matter what it's created in. Most people don't really think about file sizes, or the fact that Chromium is packaged with Node, they just want their problem solved without visual or performance hiccups.

If it wasn't for Electron, Collate would be a very different application or non-existant. I think people need to look at Electron as opening the door to more possibilities.

FWIW, I didn't mind the overhead of Electron when I only used a couple apps built with it. Now that that number is increasing, I find myself having to monitor resources & battery life and selectively killing apps. I have concerns that this approach isn't going to scale.
This is a really good point. Could two electron apps share a chrome runtime? Has to be a way to make this more efficient.
(comment deleted)
They could but cannot as electron versions are different between every app.
The only good point Electron has is 1. All other points are obsolete.

- You can find libraries for "all sorts of functionality" with ease for native languages - Swift, C#, Python (Mac, Win, Linux).

- In the end the ability to use CSS is harming user because now you don't have default OS element styling and every app is using it's own styling for things like buttons - this is very bad.

> If it wasn't for Electron, Collate would be a very different application or non-existant. I think people need to look at Electron as opening the door to more possibilities.

Exactly. If you're building an app yourself you'd never have the resources to make a native app for Mac, Windows and Linux. Nothing is perfect in software development. Electron is a decent tradeoff for certain projects. Regular customers aren't going to even consider disk space or memory usage unlike many vocal commenters in this community.

>"From what I've seen, users are more than happy to have an application that solves their need no matter what it's created in. Most people don't really think about file sizes, or the fact that Chromium is packaged with Node, they just want their problem solved without visual or performance hiccups."

To be frank, most users often don't have a better performant alternative (outside of maybe a browser tab) so it seems like a redundant point.

(comment deleted)
Regardless of whether the HTML+JS+CSS stack is good for desktop apps... The one thing that bums me about Electron is that it bundles an entire web runtime with each app, even though a suitable runtime already exists as part of the operating system.

Seriously, WebKit on Mac and Edge on Windows would be just fine for >99% of Electron apps. Using the available web runtime would be a tremendous saving both in build size and memory usage.

Did you know that Chromium contains 25.3 million lines of code? [1] Each Electron app is bundling a separate copy of that enormous codebase in binary form. It's a terrible waste of memory.

It's true that supporting the native web runtimes would be more work for the Electron framework developers, and sometimes would also mean more work for app developers... But most web apps have absolutely no good reason to be tied to Chromium, so for app developers the diversity would actually be beneficial in the long term IMO.

If someone wants to start a project that's like Electron but uses the native runtimes, I'd actually like to contribute some work. Let's call it "Electrino"?

[1] https://twitter.com/worrydream/status/857794605076500480

It just astonishes me how big the slack install is. It is like installing the latest video drivers from Nvidia or AMD.
What's the purpose of the Slack desktop app? What does it do that the web app doesn't?
Primarily, it sits as its own entry in your task switcher, and can show the number of pending alerts you have. It also uses OS native notifications, though I know that's increasingly possible through the web too.
When I did use Slack to communicate with remote coworkers. I just kept a tab open - with notifications turned on. Most of the time I was working with three monitors anyway.

Now that I only use Slack to communicate with former coworkers I just keep it on my phone.

Only having to target a single browser does make life easier for application developers. It's like programming for the web, but without the hassle of cross-browser compatibility.
Look at it from a product owner's perspective. I want 100% of users to have the same experience. Electron bundling a web runtime that gives the same experience on each platform is absolutely key to giving them the same experience. There may also be security issues to consider.
That web runtime doesn't ensure that people have the same experience. You're still relying on the abstractions of that runtime. Plus that there haven't been any changes to it.
Can you elaborate? Are you saying that Electron apps have portability issues?
Look at it from the computer owner's perspective. I don't want your experience if it comes with 100+ MB of redundant code.
Isn't that size arbitrary? Downloading and storing a 100mb program takes the same (or less) fraction of your available resources today as downloading and storing a 1mb program in 1995.

Are you short on disk space? Download is too slow? Is this a real problem?

Download size is relatively harmless; size on disk is an annoyance and a real concern (a lot of laptop users have an SSD in the 128-256 GB range); but memory footprint is the real killer for me. I don't want every little widget to consume hundreds of megs of memory.

In 1995 my computer had 8 or 16 MB memory... Having a 1 MB app running in the background would have been huge. I certainly don't want to go back to that era.

Memory footprint is my big issue with this too. Related, I've noticed chat for various projects slowly migrating from IRC to Slack and have the same issue there. What could have been another irssi window taking up an insignificant amount of memory is now a 150Mb Chrome tab.

To make matters worse, memory growth has stagnated. A Macbook Pro today, to give an example has the same maximum RAM (16Gb) it did in 2010. That's zero memory growth in 7 years for a popular developer machine.

Wouldn't regular Chrome have the same issue? Each tab is a full instance... your argument is against Chrome and web apps, not Electron.
Chrome splits itself in various processes and usually each tab has a process. But each process is not a full Chrome instance. There's a huge difference.
No, it's different.

Each Chrome tab is a process, but they share the same dynamic libraries in memory. Each Electron app is both a process and a separate copy of the dynamic libraries.

If you run half a dozen Electron apps, those redundant libraries will be taking up roughly a gigabyte already.

Would people give shit if Spotify was 100 Mb?
if Spotify were the only app using Electron, it wouldn't matter.

But when every utility and menubar widget has its own copy of Electron, the footprint balloons quickly. And people are actually doing those kinds of apps in Electron already!

Which product owner? Totally agree with you, but the reason why it's delivered this way right now is a technical implementation detail. Electron could focus on delivering an API that abstracts away differences between runtime engines (as most web frameworks do). I'm sure bundling chrome in is a boon to simplicity inside electron, so maybe the distinction matters within electron, but i'm not sure that distinction should matter for downstream projects...
That is not a valid thing to want. The experience is supposed to be different on each OS.
Not wanting your users to have an "experience" that matches their OS IMHO is bad design.
For me, I'd just love it if progressive web apps would have a desktop offline install mode that allowed them to deliver notifications, a desktop icon, and a separate window.

I was expecting this to happen after chrome discontinued their "chrome apps", that the underlying tech would come back with progressive web apps, but I haven't seen anything in that space.

I think it would solve the problems with Electron apps (wouldn't have to rebundle the runtime for a massive binary size and massive memory use).

If anyone knows if anything is happening in this space (progressive web app installation for desktop) please let me know.

I am looking forward to more PWA and I agree this would replace most use cases for Electron, but not all.

If it's just a web app (network, localStorage etc) then it would be fine. But if you need to read/write to the user's filesystem or need to include other executables then we can't run that in our browser. We don't want a webbrowser to have any possible path to screwing with your filesystem or running executables.

There is a flag for it. I was surprised that my website 'installed' on my Linux PC, created a '.desktop' file and launched in a separate window. It works now, only bug I encountered is asking 'add do desktop' while I already launched it from desktop
Isn't this more of a philosophical problem?

Static binding vs dynamic binding?

Bundling everything up so no outside deps are needed vs using everything that is on the system to save space?

Yes, and I wish developers could make that choice more easily.

The Electron approach is fine for genuinely large applications. But I've seen many Electron-based Mac desktop apps where the UI has a handful of elements. The equivalent Cocoa app would be maybe 100 kB.

I understand that people won't learn Cocoa just for tiny UIs, so it would be really nice if there were a mostly Electron-compatible solution that would use the system web runtime which is already there (and probably already loaded in active memory).

It's funny somehow.

They built a framework for, as you say, "genuinely large applications" but it seems to be so easy to use that it's used especially for small ones.

And if you are building a large app you'd benefit from a statically typed language with better native data type support than JS.
Well, why wait. I made a repo for "Electrino":

https://github.com/pojala/electrino

Sorry, it's totally empty! But I'm hoping to get around to making a Cocoa+WebKit proof-of-concept this week. I guess the starting point would be to implement just enough APIs to be able to run the main.js example from this Electron tutorial:

https://github.com/electron/electron/blob/master/docs/tutori...

Another direction might be to extend Cordova to support macOS and Linux. Cordova already supports building UWP for Windows Desktop/Xbox/HoloLens using the native HTML+JS stack. Seems to me like a lot of existing Cordova plugins just need subtle nudges to support macOS in addition to iOS. Then you just need a good Linux solution and you cover all the desktop environments.

Then narrow the few missing desktop-focused APIs that Electron has but Cordova doesn't have good plugins for. (It would also be nice to support more Node-like background processes in Cordova and more Node-native libraries, but you would need to find a good balance that plays well with mobile.)

Update on Electrino: implemented minimal APIs to load Electron's "Hello World" example. Code is in the repo.
The con is not all browsers support the same features. Sure, we've come along since IE6 and Mozilla but if I'm creating a web-based desktop app, I want to deploy with 100% certainty that the CSS/JS I used works exactly the same when I was developing it.
The only Electron App which I use regularly is Gitkraken and I am quite happy with it. In my opinion it is not as snappy as a native UI but it is still fast enough that it does not matter to me.
Bad idea. We didn't learn from the mess that was bundled vs. installed JREs and if Electron apps become more popular, users will have dozens of different Chrome installations running on their systems, taking up disk space and memory and potentially interfering with each other (that's speculation on my behalf).
Go one step back: why desktop app?
Exactly. I can't think of any use case where I would want to use a desktop app that doesn't have the native performance of a real native solution instead of just using a web app.
There are use cases where a web app is not suitable. For example:

- Sensitive data that you do not want to be known by thid parties

- Very interactive applications where consistent subsecond response times are needed

- Applications that rely on data located in the computer (for example from other desktop applications)

Funny thing, Electron is currently unsuitable for first 2 and has serious trouble with 3rd.
Are you asking why a desktop app in general or why an electron based desktop app instead of a web app? I think it is interesting that the other two answers (at the time I am writing this) answer each potential interpretation of the question.
Produces slow (I've yet to see one that wasn't pretty clunky), resource-hungry, non-native-feeling apps. Not a fan.

Also, bundling lots of different Chromes in apps which may or may not ever be updated feels like a security issue.

Electron definitely isn't the greatest: it's inefficient, duplicative, and makes your app way larger than it needs to be.

With that said, IMO Electron is great purely for the reason that it opens desktop development up massively.

I've written native apps before and it has been a world of pain. Electron lets me use tools and skills I already know to spin up desktop apps. I know I'm not the only one who this applies to, and there are a bunch of apps that probably wouldn't exist if Electron didn't. It's usually a false equivalence to compare Electron apps to full native apps.

If the choice is between an inefficient Electron app, or no app at all, I'll take the Electron app any day.

No, and Never,Since the Electron uses Chromium and Node.js so why not browser? Yes there are something browser could not do , and what I want to say is maybe there is stereotype. I have been using desktop software using web-gui in browser and they work just fine. there need something maybe a protocols that make browser more desktop, but this would never happen since it would give user too many power.

For now all the google-about things would always end up to benefit google instead bring convenient to user. Yes I just hate google, And what they bring to the web(For recent years only)

I think something like Electron should have been made but all I could find now is web browser or game engine.

There are already too many silly Apps on mobile platform, and Electron is just another that silly things in my eyes, since I'm just a stupid and arrogant user

I am a retrograde, grumpy, obtuse old curmudgeon, so let me bite:

No, it is a terror. Applications produced with it are bloated monstrosities, gobbling up hundreds of megabytes in both storage and RAM before getting round to as much as putting a checkbox on screen. Bundling an entire web browser inside your program in order to provide portable GUI functionality like what Tk managed more than twenty years ago without breaking a sweat, and at roughly 1/100 the size, yeah, sure, it flies. So did the Spruce Goose, sort of.

But then, I never took to js, I never took to Chrome, I never took to bloat as a way of life.

[edit: typo]

I agree with you and take it a step further:

It is totally embarrassing that programs are 100-1000 times the size they used to be, and slow. I think it shows an overall disinterest in our tooling and field, and it's shameful.

Another thought, however, an application I wrote is 30MB when packaged. On an average internet speed, this takes ~16 seconds for your average internet speed (15mbps). Even on 1mbps, it only takes 4 minutes for the application.

When unpacked, it weighs about 100MB. This disk space costs roughly £0.004 for an HDD or about £0.020 for an SSD.

In exchange for these extra costs, I get to use HTML, CSS and JS on both our website and our desktop applications and they get to share the same codebase. That alone must saves me 50% of the time. The fact people might have to spend upto 3 more minutes to download my application and that it costs them 2p to install it on their SSD is minimal compared to the fact that I can have twice as many features in the same amount of time.

Download is not the problem, the 10s start-up time is, as is those 100 MB RAM usage, even worse if you hit swap.

Why use JS when you can have Lua for scripting and a less annoying programming language for main code? Why use HTML and CSS when you can have a dynamic portable native UI as in Qt?

I smell laziness and cutting costs in those decisions, or rather offloading the costs onto users.

>Why use JS when you can have Lua for scripting

Have you tried NPM? If I want to write every single line of code for my application, I don't expect it to ship (unless it's extremely simple). When there is a library for almost everything, why not use one instead of trying to reinvent the wheel?

Have you used anything other than javascript? NPM is not unique, half the stuff it contains is also in the standard runtime of other frameworks.
I would thoroughly disagree with you that there is any other repository of libraries nearly the size of NPM. Take a look at ModuleCounts[0] and you'll see that NPM is growing 4x faster than the next sized repository (Maven) with already over double the number of modules.

[0] http://www.modulecounts.com/

Module counts aren't relevant. A good chunk of them are micro libraries (left pad) that are already covered by anything with a standard lib, half of them are abandoned crapware. I'll take 1 good library over 10 similar shitty ones any day.

We also had libraries long before every language needed it's own package manager.

PHP, Python, ColdFusion. ColdFusion didn't have a package manager until a couple of years ago and it was so bad, I built one for it. PHP Composer is just okay. Python's is a disaster.
You've got a knack for going with the worst programming languages available (python aside) don't you?
Eh, when you know nothing and you start programming, you start with what you can find, understand and use.

I have written Java, C and C++ when I was younger but I enjoy scripting languages more and they have provided for me well enough.

But, let's be honest here, "worst" is your bias for the languages which doesn't actually say anything other than your opinion.

There are such things as taste, esthetics, craftmanship and professional pride. Although of course I'll give you, we all make compromises all the time.
The only real issue I have with Electron, that I don't see brought up when it's discussed here, is the process model.

Last time I checked, each window in your Electron app had to run in a different process. This is a design that makes sense for a web browser like Chrome, but not for the majority of desktop apps.

If your app is simple enough to only need one window, this won't be an issue, but otherwise, I found it a major pain.

Ugly, bloated, poorly integrated and weird UI bugs, like scaling randomly failing on high DPI displays.

Only useful for web-only teams who have no desktop experience whatsoever. If you can afford to hire a desktop team, do it.

I don't know if Spotify is Electron but it's some kind of embedded Chrome and I'm really happy that it scales so well on my Linux HiDPI setup. The regular zoom shortcuts for Chrome just work. I also love that about Slack. Arbitrary user zooming in native apps is usually not implemented at all.
Try to use VSCode or Atom on Windows on a 4k display - blurry text, text that random switches between blurry and not blurry. Seriously, I had it so every even scroll was crisp and clear but every odd scroll was blurry and awful on VSCode for some reason, I confirmed this looking at it on a 100dpi screen.

The relevant bugs are upstreamed to Electron.

I wonder if HiDPI is handled better by the other cross-platform UI toolkits that people recommend over Electron...
Kotlin?
No. The current iteration of Kotlin Native doesn't target Windows due to some peculiarities in it's exception handling mechanism. And Windows is the #1 platform for desktop apps. As much as I wish I could reuse our mobile Kotlin code in our desktop app, that isn't very practical at the moment.
Python Devs: What would you recommend as an alternative to Electron ? I've heard of PyQT, Tkinter or even PyGTK but not sure what to choose ... Cheers
PyQt works well. Tkinter is simpler, but the UIs you can create are simpler as well.
Tkinter:

- Bindings to Tk (Tcl; cross-platform GUI toolkit).

- Bundled with Python.

- Easiest to use but has the least features.

- Ugly on Linux and is difficult to theme.

- Good choice for small applications if you only care about utility.

PyQt (or PySide):

- Bindings to Qt (C++; cross-platform GUI framework).

- PyQt is GPL licensed and supports Qt 4 and 5.

- PySide is LGPL licensed and supports Qt 4 (support for 5 is in development).

- The pixel perfect purists dislike it on Windows and Mac.

- Good choice for large applications where an almost native look is sufficient.

PyGTK:

- Bindings to GTK+ 2 which is obsolete.

PyGObject:

- Bindings to GTK+ 3 (C/GObject; cross-platform GUI toolkit).

- Comparable to Qt.

- I've heard Windows support isn't the greatest (this may be obsolete now).

- I'm biased and perfer Qt over GTK on Linux.

- Good choice for large applications where an almost native look is sufficient.

wxPython:

- Bindings to wxWidgets (C++; cross-platform GUI toolkit).

- Comparable to Qt.

- Uses native widgets on Windows and Max, uses GTK+ on Linux.

- Good choice for large applications where a native look is required.

Kivy:

- GPU accelerated GUI framework.

- Does not look native.

- Good choice for graphically intense applications that do not need a native look.

My recommendation is:

- Small, utility program: Tkinter.

- Large application: Qt (if an almost native look is sufficient).

- Large application: wxPython (if a native look is required).

- Graphically intense application: Kivy.

The only one I use is VSCode. It's a great IDE-lite, but after a day or so it pretty reliably gets into a state where it's permanently and unusably slow, and needs a restart. I can't prove this is Electron's fault, but I'm inclined to give the VSCode team the benefit of the doubt. I certainly do not need to restart Sublime Text every day in order to use it.

And as an Old, I do believe there's a serious cultural problem, caused by the Web Rush, where the industry as a whole does not care enough about zero/low-cost abstractions.

My personal take on using electron if the following: If you are creating a big app that gets a lot of attention from the user electron is fine. If you are creating a little tool running in the background, electron doesn't work so well because it often uses a lot of memory. So, building a chat application with electron is bad and your main text editor for your dev work in electron is totally fine. Ultimately, the deciding factor should be your users, is it best for them that you use electron or are they better of, if you are using a different solution.

Something else to consider are your development skills. If you never worked with something else than web technologies, electron is hard to beat in terms of dev experience.

I can't say that I'm not a fan, I'm a hater who rolls his eyes off anything built with Electron.
I used to use linux desktop since 2012(ish) and I remember the time when most of my apps were Windows and Mac only! As a broke university student, I could not afford to upgrade to a Mac just to use some tools!

Electron has made me forget those days! Today, most of the tools I use are available on all platforms and while they do take up a lot more ram and disk space - both are generally things I can buy and fit on my computer and will be supported out of the box but not having those apps won't.

I know it's great to hate Electron because of how much ram and disk space it takes, but for those few on Linux, it's truly made life easy!

I am the retrograde, grumpy, obtuse old curmudgeon of a comment somewhere above. Running everything on Linux for all of this century and a bit of the last one as well.

As you may surmise, I do not entirely agree with you: I have tried the odd Electron application, but I don't think any of them lasted a week on my desktop. It's not just the bloat in itself. Software built on what I consider iffy technologies - somehow I never really manage to trust them or just feel reasonably comfortable with them.

oh I totally agree, almost all those apps don't fit in with Gnome or even Unity (almost all electron apps feel out of place). But imo, it helps make life slightly easy!
To each his own. I'm most certainly not out to stop anyone. And I realise I'm too much of a purist for some :)