Why Electron Is a Necessary Evil
federicoterzi.com
federicoterzi.com
I have played around with Electron in the past for fun "nothing" projects, and also tried to understand what many on HN would want as the "correct" way to build native apps. It's an indescribable difference how much easier Electron is to get up and running from my experience, as someone who primarily does front-end work.
Are there better ways to build native apps? Of course. Electron still solves a massive problem for many developers and end-users that I don't understand why so many here get on their high horse refusing to acknowledge. It's similar to PHP hate to me. Of course there are better languages to use, but things like WordPress using PHP are so much more approachable for so many developers.
Electron is approachable because it eschews all of these things in favor of convenience to the developer, but these things are important to the user, and the user is who we should care about. We write software to serve users. We need to be asking ourselves if the benefit of the barrier to entry on producing applications be so low as to give up all the benefits of more traditional ways of application development (I'd argue no) and whether it's worth trying to bridge the approachability divide with easier APIs for developers and making the development experience as user friendly as possible (I'd argue yes).
More broadly, I think the popularity of Electron apps is evidence that users are actually very happy with them. There's an argument to be made that modern software is in general bad for users, but plenty of Electron applications (e.g. vscode, Obsidian) are IMO relatively unimpeachable in terms of offering real useful functionality with a minimum of dark patterns and/or other sketchy practices.
Widely used doesn't mean popular. Teams for example. Many widely used Electron apps are chosen by employers. Or are free and have network effects. Or became dominant as native apps and have a moat.
Arq went back to native because users hated the Electron version. Slack users who see Ripcord say the company should hire the developer. I almost never hear anything positive about the Spotify app.
Do you claim Electron apps have fewer sketchy practices?
Another extreme outlier here, so according to the 100/10/1 rule of 100 readers/10 voters/1 commenters we have 200 extreme outliers just in this thread ;-)
(Although I should note that I don't use all of them every day. Mac is a Mac mini in our office at home, Linux is both on a work laptop and also on an old personal laptop that gets used for personal learning and personal projects, Windows is a work laptop. Telegram an Joplin gets used across all of them.)
Sure? I just wanted to make note of something I think is great and underrated about Electron. The outlier-y nature of that something is exactly why my next paragraph starts with "More broadly,".
> Widely used doesn't mean popular. Teams for example. Many widely used Electron apps are chosen by employers. Or are free and have network effects. Or became dominant as native apps and have a moat.
> Arq went back to native because users hated the Electron version. Slack users who see Ripcord say the company should hire the developer. I almost never hear anything positive about the Spotify app.
VS Code and Discord are the big ones that come to mind as both widely used and widely preferred by their users.
I don't think the fact that it's possible to build shitty applications in Electron is very interesting, since that's true of every other UI framework. Neither does the fact that some people actively dislike e.g. VS Code contradict the fact that a great many people like it very much and independently choose to use it.
> Do you claim Electron apps have fewer sketchy practices?
I'm not sure where you think I claimed this, but since you asked: I think sketchy practices are common throughout the consumer software industry, and I don't think there's anything about Electron that forces developers using it to implement sketchy practices.
If they do, that's on them. And since Electron is so common in consumer software these days, I'd caution you to remember that correlation does not imply causation.
Discord is free and has network effects. Lots of users complain about it. It competes with another Electron app mostly.
VS Code is free and has network effects. And high overhead and lots of custom UI are the norm for IDEs. I don't think anyone meant Electron is suitable for nothing.
Arq users didn't hate the Electron version because it was shittier than other Electron apps. They hated it because it was the normal level of shitty for Electron apps. Teams, Slack, and Spotify show many users doesn't mean happy users.
I didn't say you claimed Electron apps have fewer sketchy practices. But it's strange and pointless to just praise Electron apps for a minimum of sketchy practices if you don't.
Unless you have a true captive market or some crazy sales-focused enterprise business, you can't get network effects without first achieving that critical mass of users more or less on your product's own merits, and if your software is shitty and/or pointless then you are not going to get there.
> Lots of users complain about it
Discord has like 200M+ MAUs, so of course "lots" of users complain about it.
> But it's strange and pointless to just praise Electron apps for a minimum of sketchy practices if you don't.
I'm not praising them for any such thing—I was just calling out the fact that most consumer software these days is abusive, so we have to be careful to speak about abuse in relative terms. I don't think Electron "apps" are on average better or worse, and if (looking at data) they did turn out to be better or worse in this regard then I would attribute that to the widespread adoption of Electron "apps" in certain market segments that tend toward abuse, rather than some inherent property of the framework that encourages it.
In other words, the baseline for modern consumer software is to abuse the user, and I don't believe there is some inherent property of Electron that encourages (or discourages) that trend.
No one said VS Code and Discord had no merits at all.
Discord's core users were gamers. People who can afford to run much more demanding software for fun. People who don't care about accessibility mostly. It's free like I mentioned. It competes with Slack mostly. Slack has the same problems mostly. And 1 of Slack's merits on its way to critical mass was compatibility with other apps.
VS Code's early merits were it was faster than Atom and free unlike Sublime Text.
> Discord has like 200M+ MAUs, so of course "lots" of users complain about it.
A large fraction in my experience. "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize."[1]
> I was just calling out the fact that most consumer software these days is abusive, so we have to be careful to speak about abuse in relative terms.
Who said anything about abuse before you?
Most users only care about features which is directly connected to speed of software development.
You are speaking for all users but I'm certain that things you are saying are not true for example, users don't care if an app uses "unnecessary resources" unless it's fast enough. Users definitely do not care about UI conventions, most probably don't even know there are conventions. As for security, if you are using anything written in C or C++ you already lost there.
Considering that the average user refuses to wait longer than 2 seconds for a webpage to load, it's clear that people do care about more than just features. To dismiss that reality seems like a very "let them eat cake" attitude to take. Users care very much when an application makes their computer run sluggishly, and despite your disbelief, users actually do notice when an application looks different from their other applications, and they may or may not care about that. You say that users don't even know that there are UI conventions, but let me ask you this: if you created an application on a mac and moved the three buttons to close/minimize/maximize the application window from the upper left to the lower right, what percentage of users do you think would notice that UI convention change? I'm willing to bet about 100% of them. UI conventions are more than just a pretty facade, they provide hints about functionality using symbols and patterns that we've grown accustomed to, and don't even think about consciously. As for security, it's never a good look to point out how bad one thing is to justify another thing being bad also. Just because we've already lost doesn't mean we should give up.
Will pressing Alt+F4 close the entire window? (See MS Teams, if you open the settings dialog and and to close it).
You can find probably dozens of such examples
Users care transitively since there is a correlation between the amount of effort it takes to write a piece of software and the price required to sustain the development of said software. In my experience, many users care more about price than consistency or speed.
In cases where users are willing to pay more (such as with some professional software) you'll often find a lot more native applications.
I have never heard a non nerd say anything like that.
Is that necessarily true? Fuel economy is only where it is because of government regulation.
I don't know who failed to realize this. I rarely see comments refusing to admit that "building one electron app is easier than building 3 native apps for Windows/Mac/Linux". Most of people criticize the use of electron when megacorps undervalue user experience and make all sorts of excuses to use electron for the sake of cost saving in software development.
In many HN posts, as users who are technical enough to understand the impact of electron apps on their computers, I think the general idea is that native apps simply feel better and electron should not be encouraged.
Front end focused? It makes desktop apps accessible period. Someone inevitably mentions QT in these conversations. Find me a single successful QT based app. Electron is really the only cross platform option.
Let me start with Telegram. The ux is universally liked (yes, even by the Mac crowd!)
> Front end focused? It makes desktop apps accessible period.
If someone just wanted to create cross platform applications quickly and push them upon people who don't have a choice (i.e. in an enterprise) there always used to be Java Swing as well.
Far easier than Electron, even approaching VB6-simplicity in GUI design, but with a sane language behind.
So, GP was right: It makes it easier for frontend devs.
Edit: yes, a lot.
What?
https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...
What a weird thing to say. Ableton, 3ds Max, Photoshop Elements, Google Earth, Mathematica... Qt probably has a longer list of success stories than any other cross platform UI toolkit.
No-nonsense? Why does software have to be no-nonsense? I'd prefer for software to be beautiful.
People complaining about resources mean the limited resources of their computers usually. But it does lead to wasted natural resources by making hardware obsolete faster. And wasted financial resources. And slow and inconsistent interfaces waste cognitive resources.
No nonsense means functional. Not ugly.
> Find me a single successful QT based app.
And you've been provided a long list. Please don't move the goalpost.
Do you think Slack can't hire enough developers to build native platforms for Mac/Windows/Linux? Spotify? Discord?
I get it for small dev teams to build a cross platform app - but at a certain size, I don't understand why they can't go build native apps that aren't garbage.
Have you tried to hire developers with eg AppKit experience in the past 5 years? I have, twice. Neither were small companies. Both routes went electron because 95% of the native Mac developer pool works in Cupertino or China, and it’s a kiddy pool at that.
Specifically, if Slack created new development teams to build native clients for Mac and Windows, would that effort eventually yield enough additional revenue to be worthwhile?
(Mind you, I don't know the answer to that question because I don't know Slack's financials, just pointing out that it's the real question governing whether they should use Electron.)
It is good for small teams to be able to rapidly build cross platform apps that are good for MVP.
Slack is bad for using electron.
You can get a functional, graphical, Hello World! WinForms app running in like 10 seconds, ok, perhaps 20 seconds if your computer is slow
I can teach anybody with very basic programming skills to build something fancy in like 2 hours
No idea about Mac environment, but I guess it must be similar.
And if I succeed then my prize is what? I get to do it again on two other platforms?
Any advice?
Usually, you won't need to directly call any API function to build even a complex program.
.NET comes with everything included
Enabling more sht being shipped is not a badge of honor for a technology. Same goes for Visual Basic and Go, and for all those effort to dumb down software development when what the world needs is for quality* in software to be valued over quantity.
> Are there better ways to build native apps?
Depends. Is it a choice between using Electron or drowning in complexity and not shipping anything at all? An app is better than no app.
Also, I'm pretty sure it's easier to fire of Visual Studio and start clicking-and-dragging controls onto a form in C#, and you get a better programming language with it to boot. It's just too bad WinForms/WPF aren't cross-platform...
Why are so many people slobbering over web developers and front end people any way?
Electron does not solve a "massive problem". It solves a very minor problem. But web developers are precisely the people who rather than studying the target's platform or studying their own platform (you probably don't need Electron) would just do the most nonsensical thing that comes to mind.
Oh so true. It is such an indicator of lack of experience, too. Clearly they have never tried to support a cross-platform application, because Electron is utterly seamless from Win10 to Mac to Linux, even for USB and serial hardware. It has shaved literal man-years off development of our primary application at my company.
It's like haters are just admitting how junior they are.
I, too, can tear down a straw man. But there are economical factors at play here and it's strange that you think that technical workers are oblivious to them.
Electron is compounding a problem that is not going away soon, or ever. People will not buy more expensive laptops to do their work (many simply can't). In the era of remote work the costs more laptops that can take the load that an Electron app introduces, is swallowed by employers -- and some don't want to do it.
This pressure is mounting, I assure you. Employers keep complaining there are no employees -- and what they actually mean is "we can't find people with laptops good enough for Slack and Discord and Excel and we don't want to buy them those". And I am not talking about programming jobs -- there it's usually very well understood that you have to buy the staff good machines (although I've been issued some pretty average machines but hey).
So employers keep screaming that they need more and better workers. The potential workers are like "eff this crap, I am not getting paid enough to buy a MacBook", plus many people have enough common sense not to reinvest their income in tech that company should have bought them in the first place.
How do you think this tug of war is going to end? By proclaiming "coding with Electron" (or PHP / WordPress since you mentioned them) is a basic human right? (lol) At one point something will give out and I can assure you it's not going to be society. It's going to be the tech companies who can't ever be bothered to invest a little bit in creating a cross-platform GUI toolkit.
So yeah, keep going on and on about how the technical people don't understand important things. From where I am standing it looks like that it's you who doesn't get it -- you are only bringing up ease of development, and there are much more factors in this situation.
I'm not saying it's not useful but I'm not falling over myself to argue we should all be using this stuff.
So whiner need to shut up already and buy a new computer annually where electron run normally.
I don't think anybody is on a particularly high horse.
The APIs are a complete mess, half of them are not working properly, things constantly get broken between even minor version revisions, the documentation is usually outdated and incorrect and you need to plaster your code with OS-specific if-else statements all over the place because many of Electron's APIs behave differently on different OSes. The whole thing is just a complete disaster.
Speaking as a user I don’t care about your production costs and your programming knowledge. I care about my experiences. That’s why many Electron-based programs are marketed to managers as “solutions”, not to the actual end users.
As a macOS user let me add to the list of complaints mentioned by the author. Despite having fully functioning native iOS apps, some companies will not allow installing those directly on M1 based Macs, nor would they produce a rather simple ports for macOS. They will insist for you to use Electron-based client, like everyone else does. Teams, Slack, Discord. So I do agree that at least in this case Electron is evil.
I think tech people tend to assume this way too much without having any kind of evidence.
I actually prefer electron apps. They usually have a nice looking, modern design and are more consistent with web where I spend most of the time anyway. I doubt I am alone in this.
They might choose the former but then what? I would too, as a user, but in practice as the article mentions the alternatives aren't yet that great. So quite often the user can choose between the Electron app... or nothing. Many users accept the drawbacks and in fact it's mostly developers or technical people in general who complain about Electron. Most users don't even know about any of this.
Obviously, this can exists only when there's no or minimum competition for the end users.
I'm still working on learning C++/something like QT but I was able to deploy an app to Win/Lin/App.
For reference
Cross platform CRUD app (desktop, Android RN app) https://github.com/jdc-cunningham/cross-platform-app
Basic news slider app but it was transparent https://github.com/jdc-cunningham/frameless-electron-news-re...
Also as a user of many electron based apps, I currently use apple silicon native electron apps on my m1 macbook air and they are extremely snappy with only 16gb of ram (go download the canary version of discord which is compiled to apple silicon if you want to see the difference). If there is one entity that I'm truly angry at it is intel for completely mishandling and holding back the desktop processor ecosystem for the past decade (or longer).
This is such FUD. The normal way to use Qt is dynamically linked, it is not difficult to use the LGPL version, you most likely don't use the premium features, and the restrictions are about using Qt to create embedded devices.
There are good reasons not to use Qt, like that many teams don't have the discipline to maintain a large C++ gui application. There are plenty of crap broken Qt apps because it is easy to screw up. There are few responsive electron apps because it is difficult to make fast.
Easier to make a mediocre app in electron -> classic worse is better in action.
For Sciter Quark ( https://quark.sciter.com ) I've measured size of minimal "Hello World".
- Electron: 50 MB on disk, 200 MB of RAM and at least 2 processes running.
- QT: 5 MB (and 30 MB if + QtWebKit) and ~70 MB (200 MB if QtWebKit) of RAM.
- Sciter Quark (standalone Sciter executable): 5 MB on disk, 32 MB in RAM. That includes HTML/CSS UI, JS engine, NodeJS alike runtime.
Out of the box Sciter works on same platforms as Electron.
As a side question, Do you parse JSON in your apps? If yes what package do you use? I tried built_value, I suspect the people that developed this really hate me personally ;)
Another I find personally frustrating is so many libraries assume you are using the Material stack.
RE: JSON--I have used json_serializable in the past: https://pub.dev/packages/json_serializable. For my current project, I am using a data format I created call Traindown (https://traindown.com) and it's all local so I haven't hit JSON or SSH/SFTP issues personally.
Sorry I don't have a silver bullet suggestion for ya! I'm sure they don't hate you personally. Maybe all of us as collective "users" but not YOU! haha
Thanks for the suggestion.
well, this is patently false. https://developer.apple.com/design/human-interface-guideline...
If I keep Tabby open for too long it starts to spike the CPU and I suspect that this would be the case for any active Electron apps.
"Unless you’ve been living under a rock for the past 5 years..."
I see this sort of thing and I just want to stop reading. Only worse is
"This isn't your father's..."
One little bonus is that my browser extensions also apply to these installed PWAs. For example, the Todoist PWA now shows me the Toggle icon next to each task as an easy shortcut to start the time tracker.
In my case, I have these running as Chrome PWAs:
- Raindrop.io
- Grammarly Editor
- Todoist
- Discord
- Element
- Whatsapp
- Twitter
- 1Password
- Obsidian
- VSCode
- Gitkraken
- Slack
- Spotify
Another app I use that has this problem is Spotify. While it isn't electron, it is using CEF (chromium embedded framework) and can be dynamically linked to a distro one with some effort. Using the web version means I dont have my music available offline for listening.
He also fails to consider that there's bindings for all native platform UIs for a ton of languages. You could write gtk code in javascript or C# if you wanted, and this is especially relevant when mentioning WxWidgets. You don't have to write your business logic in C++ these days.
I am able to do and automate all sorts of very cool and amazing things that wow friends and family, mostly through bash as well as some Python.
And then there's GUIs. It makes no sense that they are this hard to program. If it's the tiniest bit more complex than something that can be done with Zenity, it's probably not going to happen. Nothing comes close to being as easy as some web-type GUI, which aren't themselves that easy.
But most of my furniture still comes from Ikea and the like because it costs at least an order of magnitude less to build and ship.
Electron will continue to grow in popularity for similar reasons.
There is, however, a big difference in the effects of scale.
The marginal cost for another piece of high quality (or even low quality) furniture is high.
The marginal cost for one more copy of Microsoft Teams is almost nothing no matter which technology Microsoft uses to make it.
In my experience what's really happening here is the "hypercard" problem. Namely, there is a tendency, perhaps subconscious, for programmers (or perhaps meta-programmers) to NOT make "tools for building" too easy because they're scared of writing themselves out of a job or a market -- or they're trying to create or retain some exclusivity. I'm not necessarily saying this is always evil, but it's always a thing to consider and is likely happening all the time.
It’s the same reason why people gravitate towards MIT and Apache licenses over things like lGPL. It doesn’t require a developer to think as hard if they are in violation of the license with their project. Though plenty of developers still screw this up even with those licenses (see the devs of sonic colors ultimate and the violation of the Godot Engine’s MIT license)
After enumerating the problems with Electron, the article outlines a wide range of alternatives. This is such a great exploration! I love love love for example the idea of localhost http servers. The article discusses them! I feel differently than the author, but great & honest review:
> I know this is highly subjective, but I really appreciate having a separate window for each application, along with good OS integrations such as native menu bars and dialogs.
Covering up & coming webview embedders like Tauri really won me over. The author showed a deep & expansive knowledge of up & coming alternatives, that still make use of the wonderful great web platform so many folks know & enjoy:
> Many projects are trying to overcome Electron’s drawbacks using this approach, such as Electrino, webview, Tauri, and many more.
And it highlights that these alternatives still lack a lot of standard native integration, that it's not yet baked in anywhere near as well as Electron does:
> You see, if you choose this approach, you will need to do a lot of “plumbing” yourself, as you don’t have access to any of the convenient APIs exposed by Electron. Do you want a menu bar? You have to write the low-level bindings yourself, often multiple times depending on the number of platforms you are looking to support.
I'm hoping some of these up & comers continue to advance, continue to make inroads. Electron has been 100% a magic bullet for countless great apps, big and small. Is it 100% painless? No. But it's pretty damned good, and it marries good UX development to the power & capabilities of server-side technology, in pretty excellently & unique cross-platform way, and that's a really great combination.
This is a major pain point of electron. Sure you can save some costs, as you only have to write one GUI, but the result is always really bad.
The only electron application that is even remotely usable is VSCodium. MS Teams is a slow dumpsterfire and a mess of UI (Why do they even implement own "Close Window" buttons?)
Furthermore it is simply annoying if an application does not look like the rest of my desktop
In our case, C# was the right choice because of what the application did. (There was no way we could be web based.) For many applications, Electron (or similar) is the right choice.
We did have two native UIs: WPF and Cocoa. The Mac developers eventually figured out how to use C# models and controllers from Objective C.
Again, I would only recommend such an approach if you need close integration with the UI. We had tray/taskbar icons, filesystem watchers, drivers... Things that really don't make sense to do in something like Electron.
I'd also like to point out one advantage of Electron, if you can do it: Garbage collection. I personally find memory management in C/C++/Rust a chore, so if Electron is "good enough," you get all the advantages of V8's garbage collector.
At my workplace I'm using Electron to build a data heavy application (bill of material, 3D visualization). Performance is spectacular, especially 3D visualization of very large models (threejs). I'm using agGrid for the tables. Also extremly fast and powerful.
The users don't care at all that the app is 93 MB and takes 3-5 seconds to start. They love the app for the performance, features and ease of use. I consider Electron as a great success in this case.
I'm using VS Code, Obsidian and Todoist daily. I love them and don't care that they're Electron apps.
I doubt anyone is going to chance their mind about it. It is the jQuery of cross-platform development.
The same amount of effort spent in Electron wouldn't get you a better native app. It would more likely get you no app.
Unless you’ve been living under a rock for
the past 5 years,chances are you have used
an Electron-based application at least once
in your life.
I have never used an Electron app because all my needs are covered by termial applications, Firefox, LibreOffice and Gimp.
Which rock do I live under?
"Living under a rock" is an idiom used to describe one who is/has been cut off from the mainstream.
> Which rock do I live under?
The rock of literally never having used any of the ubiquitous communications tools built on Electron (Discord, Slack, Teams off the top of my head), or any of the very popular^[1] code editors built on it, or any of the countless other applications that use it.
I'm sure you get your work done just fine, and this is not a value judgment. It's just an observation that, at least in the set of people likely to read (or "read") this article, you are a member of a (presumably) small and ever-shrinking class. Electron is everywhere.
^[1] https://insights.stackoverflow.com/survey/2021#section-most-...
$ ldd /usr/bin/spotify | grep gtk
libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007f06b545d000)
The Web is just fulfilling Java's 'Write Once Run Everywhere' promise.
Linux, apparently.
I have tried some but that's about it
npm install --save electron