Electron, a popular framework that allows developers to write code once and deploy on multiple platforms like Mac, Windows, and Linux, has been under a state of steady attack over the past year.
Those against it are rallying to hinder the speeds at which Electron is gaining adoption by new and established startups alike. Two of the most popular tools used by developers today are proudly built with Electron: Slack and Atom.
Opponents of Electron say that “it’s too memory intensive.” Or, “It hogs the CPU.” Or even better yet, “It runs the entirety of the Google Chrome engine in every window.”
Even more, anti-Electron posts are usually filled with charts and tables, along with screenshots of Activity Monitor with memory and CPU usage, outlining the evilness of the framework and why it must be stopped at all costs.
Focusing heavily on how it makes a robot computer feel, these posts ultimately neglect what will be the deciding factor in Electron’s success or failure: how it feels for most people to run Electron apps day-to-day.
A User’s Perception
By no means am I 'most people'. I use a relatively advanced laptop: a 2016 MacBook with 16GB ram (which came standard). But advanced development machines of today are the entry level computers of tomorrow. Electron’s dream world would be one where every computer user had a luxurious amount of ram. But I think this world is fast approaching. Do we wait till then to begin taking advantage of a plentiful world, or do we start planning now?
If I were a convenience framework developer, I ought to be more concerned with where the trend in memory is going rather than where it has been. The computer industry has been stuck on 8GB for what seems like far too long, but a 16GB standard reality is imminent, if not inevitable.
I can speak for myself when I say Electron runs like a dream. On a typical day, I’ll have about three Atom windows open, a multi-team Slack up and running, as well as actively using and debugging my own Electron-based app Standard Notes. I’ll also have a bunch of other non-Electron apps opened or running, like Adobe Photoshop, three Terminal windows with 3–4 tabs each, Sequel Pro, Google Chrome with on average 4–5 tabs, Apple Mail, iMessage, Little Snitch, Dropbox, and iTunes/Apple Music.
So, how does it feel to run this bloat train of death every day?
Well, it feels like nothing.
I don’t notice it. My laptop doesn’t get hot. I don’t hear the fan. I experience no lags in any application. My music plays seamlessly. I can watch an HD YouTube video without problem. My screen doesn’t flicker. I get notifications. I download new apps and update old ones.
I go about my day, and Electron doesn’t get in the way.
The Business Case
But aside from how it makes end-users feel, there is an arguably more important perspective to be had: how it makes software companies feel.
For context, the project I work in is an open-source cross-platform notes app that’s available on most platforms, including web, Mac, Windows, Linux, iOS, and Android. All the desktop applications are based off the main web codebase, and are bundled using Electron, while the iOS and Android app use their own native codebases respectively, one in Swift and the other in Kotlin.
And as a new company without a lot of resources, this setup has just barely allowed us to enter the marketplace. Three codebases is two too many codebases to maintain. Every time we make a change, we have to make it in three different places, violating the most sacred tenet of computer science of keeping it DRY.
As a one-person team deploying on all these platforms, even the most minor change will take at minimum three development days, one for each codebase. This includes debugging, fixing, testing, bundling, deploying, and distributing every single codebase. This is by no means an easy task.
Sometimes, a prospective user tells me that this app is exactly what they were looking for but “Sorry, I don’t use Electron apps.”
If I were speaking candidly, perhaps I’d say “I regret to inform you that the world you imagine could not exist.”
Let us entertain this user’s wishes by simulating the parallel universe where a small software shop can develop natively on every single platform.
This would mean hiring a total of six experienced developers. Let’s ignore the madenning tediousness of having to make every minor change six times on six different platforms, and focus instead on the costs. With an average salary of $150k (probably more for the hard to find like Mac developers), and ignoring the massive cost of finding and hiring these developers, that’s a total of $900,000 in development costs every year.
For a bootstrapped, non-VC funded company, this quite literally isn’t an option.
Or actually, maybe it is. You can just pass the cost down to your customers.
Let’s assume a goal of two thousand paying subscribers after 12 months of operation. If we wanted to make a company-wide profit of only $100k, this would mean charging each user $500/year or $42/month. Do you want to pay $500 a year for a notes app?
I dare say that these conditions will constrict any new startup looking to introduce a cross-platform solution to the marketplace, and the amazing app that could have been will never be made in the first place.
Perhaps the devil’s deal is not so bad then? You get something, instead of nothing. That’s always good. Two, you get it for a decent price ($36/year for the notes app). And three, you get it on every platform you love to use, with web access in most cases as an added bonus.
My bet is that with the favorable conditions that it affords new startups, along with increasing memory availability in personal computers, Electron will continue to see increased adoption by companies and users alike.
If you’re a developer, you can learn more about Electron here.
You can also see some of the apps proudly built with Electron here.
If you liked this post and want to subscribe to similar stories in the future, you can follow along on Twitter at @bitario, or check out the project I’m working on @StandardNotes, a private open-source notes app.
Top comments (69)
Software devs who ignore the engineering principles of yesterday in favor of hogging resources because it's convenient for you are what's wrong with the world today. People like you are dragging down the software industry by adding garbage to your apps faster than hardware can expand. This needs to stop. God knows what amazing things we would have now if everyone programmed like it was the 80s instead of starting 5 processes taking 200MB of RAM and using 15% CPU for a hello world app.
Also congrats: reddit.com/r/programmingcirclejerk...
If everyone programmed like it was the 80s we'd have 1/1000th of the available software we have today because everyone would be programming in C and assembly, and having to completely rewrite their entire codebase to release it on a different platform. It's a double-edged sword. Electron is convenient, enables multi-platform releases from a single codebase, and runs flawlessly on every computer I own or use. Is their room for improvement? Hell yes there is. But trying to say that Electron apps are somehow "dragging down the software industry" (a claim I'd LOVE to see some data on, especially data that shows the software industry being dragged down by ANYTHING,) is just ridiculous.
IMHO, it's people who use phrases like "... are what's wrong with the world today" are, in large part, what's wrong with the world today. Get some perspective.
Hm. Isn't the Linux kernel written in C?
Don't blame the language, blame the coders. Today's programmers are making all of the same mistakes, and new ones, in Node and Ruby and Python.
Yeah, it is. My comment was not meant to bash C at all - C was my first programming language, and I think that some truly excellent software has been, and continues to be, written in C. My point was that "software isn't as good as it was in my day, when everything was in C or assembly!" is a rather rose-saturated view of the past, and ignores the mountains of good software that's been written with more modern languages.
In fact, I pretty much agree with your main point. VS Code, for example, is an electron app that starts up instantaneously, doesn't slow down when dozens of extensions are added to it, has a ton of functionality, and maintains a memory footprint of about 26MB when I have a 20k file project open. Atom is a bloated monstrosity compared to it, yet they're based on the same app wrapper package... so obviously the problem isn't actually electron (or, at least, not all electron).
Alexa, how to write an Operative System in jQuery
You just assume that the 80s had only primitive languages like assembly. Smalltalk came out in 1980, decades before "modern" languages like Java and JavaScript, and imo it's still a far better language than both of them.
Ah yes, and we all know of such smalltalk-based software masterworks like... uh... hmmm.
Actually, I've used smalltalk - had a class that used it at Georgia Tech - and while it's certainly an interesting language, and extremely useful for learning about OOP, you'll notice it's not actually very popular outside of research projects and other academia.
Also, I'm wondering what the point of your comment was. Yes, I know there were lots of programming languages that existed in the 80s. However, I was replying to a comment about how great software was in the 80s (HA!) because it was hand-crafted by skilled monks trained by the Dalia Lama using nothing but the finest assembly.
You're too young to remember them. Look here: wiki.c2.com/?WhatsBeenDoneInSmalltalk
In short: for example, the whole WIMP (Windows, Icons, Menu, Pointer) interface happened only because it was prototyped in XeroxParc using Smalltalk. And it wasn't resource hog crapware. It was light and snappy.
I notice on that link that the WIMP interface (which, admittedly, is a hell of a good example) is pretty much the only well-known project, and that was like 40 years ago... which kinda reinforces my point that People Don't Use Smalltalk unless they're in school.
I remember when we got our first IBM PC with 128K (yes, people really did useful stuff on 48K TRS-80s, Apple ][ various CP/M boxes).
My first reaction:
"128K! This is just going to lead to sloppy programming."
I was spot-f'ing-on then and its been repeated several times since.
No way I'd ever want to go back.
I'm not sure why anyone developing/using an electron app is shocked by its resource requirements. Modern browsers are basically a separate OS and runtime environment running in some other host environment (Win, Linux, MacOS).
How does that NOT consume vast amounts of resources?
Hi Jon, I invite you to check Nintendo64 games and architecture.
You'd say that's not related to the topic, but I think it does.
The most of N64 games are stored in 4MB, some of them finally came in 64MB.. And there was lots of textures, logic, among other things; CPU was 96Mhz and RAM just 4.5MB Rambus. Play those games were more complex than a desktop application to edit text, however, to execute Atom (for example) means lose at least 1GB of RAM..
Well programming in the current time has been forgotten, because everything is about time-to-market, but after that, companies forget to improve the logic of their apps, they continue adding more and more features without think in resources that these are consuming..
Do you want to build once and execute everywhere? Use Java.. As simple as that, it exists since 25 years ago and is one of the most mature technologies out there..
I don't hate Electron, however, it has to be improved urgently.. Frameworks are a double-edged sword..
I'm not surprised by it. I am, occasionally, surprised to find an app I'm interested in using is built on Electron. As soon as I find it is, I delete it. Because battery life matters.
According to Mozilla the most common number of RAM in the world is 4 GB and that is apparent in my country Pakistan. Most of the new laptops even come with 4 GB ram and people seldom upgrade. I was also using 4 GB ram till march when it no longer was able to carry all the web development tools in a smooth way and extended it with 12 GB. But since I have it now, doesn't mean this is getting standardized as there's just a very small proportion of programmers and gamers who will go to this extent.
Most of the people still use 4 GB in the world and RAM is a very expensive type of memory.
Also, Electron is a lot of Bloatware, on 4 GB ram it never works. Maybe you don't have to think about users all over the world but some people have to and for them performance and optimizations matter. Consider Slack, even though they have a pretty cool electron app, I don't have it installed, as it has a lot of overhead I did not need in any case and was unnecessarily playing a role in slowing down my computer. Their web app does all the things and is optimized, much smaller in size, it even has push notifications, so there's no need for me to install slack app.
Well... just because there's a trend toward 16 GB standard doesn't mean we're anywhere near that yet. And I assume you're talking about the upper segment of the US, right? In a lot of other places of the world (India, Africa, eastern Europe), even 8 GB of RAM can be a luxury.
I agree that Electron gets a lot of unnecessary hate, but the point about RAM just irked me :-P
Electron clearly has value as evidenced by Slack, Microsoft Teams, Atom, Webtorrent, and all the other inventive apps out there. However, there's a not insignificant amount of waste going on here if every electron app must have its own copy of chromium. Nobody needs a fully independent copy of Chrome just for an emoji picker.
I tried using Atom once on a computer with more than 4GB. It worked fine until I added more than one plugin, then there was visible interface lag between the time I hit a key and the letter appeared in the editor. In a world where tons of other editors get this right (Notepad++, Kate, Sublime, PHPStorm, VSCode, etc) there's clear evidence that Atom is just sub-par, and I think this can be attributed to Electron.
VSCode is also built on top of Electron, so I don't think Electron is the culprit of input lag.
Well, I wasn't trying out VSCode with any plugins, so it might still be Electron, and where I was using VSC was on a work computer with 16GB of RAM, so again, that would mask most issues.
But when I can even run a full blown IDE like PHPStorm of Netbeans and it runs faster on the same machine than Atom, I'd say that Atom has some issues...
It is a sad state of affairs when the best we can do with more ram is just run a text editor made with bad engineering. We should aim higher.
What the f*** are you talking about? Do you have any idea how much work has gone into both Atom and VSCode by hundreds, perhaps thousands of engineers? Surely some of which are more accomplished than you.
Not only that, but I would classify neither of those products as "text editors", and more along the line of extremely extensible IDEs, Atom for example has some 2000 more plugins than Sublime.
Finally here is a list of other applications that run on Electron, some of which were mentioned in this article and certainly more diverse than 'just a text editor.' If you can't contribute more than a strawman argument with no facts, why say anything at all?
electron.atom.io/apps/
Despite a richer ecosystem of plugins, Atom is fundamentally similar to Sublime. It's also significantly slower, consumes dramatically more memory, and is dramatically worse for battery life. The cases where it's noticeably slower, it's often so much slower that it is effectively incapable of performing the task at all. (Yes, opening and working with a million-plus-line file is a thing I do often enough that having to switch to vi or some other editor for it is a significant drawback.)
Further, I have yet to encounter any set of plugins in Atom that are even close to being compelling enough to justify giving up a large fraction of my on-battery time.
Definitely no arguments about power consumption, and will concede that it does fall over on really big files - I will occasionally accidentally click on a compiled JS file or something and immediately regret it because Atom slows to a crawl. Come to think of it, I might write an extension for that.
I'm happy to have a discussion about how Electron can be improved or what pain points are for developers. What I cannot stand are ad hominem attacks on the language or the developers that contribute, simply because somebody has had a bad experience on open-source software that they are using for free.
For instance, I would really love to see a shared runtime among all apps. Sure targeting your own specific runtime by bundling it in is great for compatibility because you always know what the behavior will be; but I would argue for the vast majority of use cases it is not necessary. This would potentially save on storage and a bit of memory due to all of them sharing the master process.
FWIW, VSCode is becoming very good - even with non-crashing for large files, though 1M lines is quite a lot and YMMV :) I know that they don't "render" text that is not within the viewport, but I'm curious if there could be further optimizations by just tracking a line position in memory and then streaming parts of the file in on demand. Of course that breaks search.. hmm.
Energy usage is not fixable, without fundamental changes to how Electron -- in particular the JS engine underlying it -- works.
Sharing a runtime in memory is a good way to amplify problems associated with memory fragmentation and also cause instability in one application to affect other applications.
Another thing that affects JS' suitability to some classes of problems is the fact that all numbers are IEEE 64-bit floats. No integer arithmetic at all. While FP is much faster than it used to be, it's nowhere near as fast as integer arithmetic. Thus, even if a Sufficiently Smart JIT could eliminate all other JS overhead, even calculating offsets into the text buffer in Atom would have a significant disadvantage performance-wise. (And that happens more than you might think: consider syntax highlighing, as well as layout and navigation.)
At the end of the day, JS is unsuitable for writing well-behaved desktop applications if only because of the energy impact. If it were a constant overhead then the argument could be made that it's more suitable for large desktop apps, but it's not: it scales up with the complexity of the problem. It starts out bad, which makes for a markedly worse experience for users when the app is small/special-purpose/utility-like in nature, and then gets worse when the app is complex enough to have logic that might not finish in a small fraction of a second.
Even the Atom project has had to accept reality here: 1.19 includes an experimental native-code implementation of the core text buffer!
Because JS is just the wrong tool for the job. And while the Atom project might blunt the worst of the problems by dropping down to C/C++ for the most performance critical pieces, that energy impact overhead still remains.
In contrast, Dropbox on OSX/Windows is written largely in Python (using wxPython/PyObjC to access the native UI system), and suffers no such energy impact problems while still maintaining a high degree of portability, a smaller install size.
The bottom line here is that when you use Electron you are trading your customers' resources for a reduction in development overhead. To the extent that that matters to your customers you are choosing to create an extra barrier to adoption. On mobile, this is already a sensitive enough point for people to scream bloody murder when a developer gets it wrong (see: Facebook having to gut their app). On laptops I only see it becoming more of an issue as Apple and Microsoft are putting more and more emphasis on battery life -- both in enabling well-behaved apps to be better behaved (e.g. Timer coalescing on macOS) and by identifying and calling out badly behaved apps (energy impact).
It is unreasonable for someone to come on here and whine about how unfair it is that their app is being judged by how the app actually behaves or even by a really good proxy signal for how it must behave.
This is your potential and actual customers providing you feedback. Maybe you should listen.
Also, I should note it's not just the JS engine: Chromium itself still doesn't play nice with things like timer coalescing. Until and unless that is fixed, Electron remains a significant liability in terms of user experience.
As another example: the idea of keeping a window of the file in memory is not a bad idea -- if only for the sake of search. The best way to handle it is using mmap. However that's going to be a dangerous thing to try and expose to JS if the runtime uses a copying garbage collector. So instead you're going to have some very... interesting... shenanigans you need to go through to make that possible. And you're going to need to break out of JS into native code to do it. And if you forego mmap then you're going to be fighting a losing battle, with a ton of wrong ways to achieve the goal -- but very few right ways.
Using a sliding window for actual editing is just trading increased I/O for reduced memory usage. It's not a clean win, just a different tradeoff.
Sure QT can create cross platform UIs, but with a $300 yearly price tag for one developer and no support.
How can a framework that is developed openly, for free, in which multiple companies have built successful businesses on and millions of people use products powered by it be a 'disgrace'? Because people like you judge a language that was created 20 years ago on the properties that it had back then, not today.
Also, I just checked and you can find more than one laptop with 16gb RAM and i7 processor for less than $1000 USD on Newegg. I find your claim about not being able to run those apps dubious - because I'm running about 20 tabs in Chrome, Spotify, Steam, Discord and 6 other things on 4.5gb RAM right now. Maybe you wouldn't be so salty and a bit more productive if you weren't sitting there choking on budget hardware.
The LGPL version of Qt can also be used in commercial proprietary software. You have to provide only the source code of the Qt libraries, not of your code, and you can sell your software (and only the Qt libraries, which are public anyway, can be redistributed by your users).
The licensing fee argument was valid back when the Open Source version of Qt was QPL- or GPL-licensed, but not anymore.
PS: Oh, and if you cannot use LGPL code, then you cannot use Electron either, because it contains LGPL code from WebKit that survives in Blink/Chromium. And it is actually harder to comply with the LGPL requirements for Electron than for Qt, because Electron upstream does not help you, they do not even mention the LGPL on their licensing page.
I'm not choking on budget hardware, but Slack is the second biggest energy drain on my machine -- behind Safari. I have dozens of tabs open in Safari right now, and it's only a bit ahead of just Slack in energy impact. My computer remains responsive, and useful, and gets a solid amount of time on battery precisely because I simply refuse to use Electron-based apps (unless I'm literally being paid to, as in the case of Slack).
Your entire defence of electron is that your $1800 computer runs electron programs fine, that it allows you to throw software together very quickly, and that eventually normal people will also have computers as shiny as yours, so the excessive resource consumption doesn't matter.
That's a really bad and selfish position to take, both from an engineering and an ecological standpoint, and utterly hostile to the user also.
Most people don't have $1800 computers, they have closer to $500 computers. What inevitably happens is that by the time average joe's computer catches up to your performance, you yourself have also kept moving, and the software you write has bloated to match.
That electron allows you to throw together your software in less time is no concern of the user. What concerns the user is that the software works well and provides a good experience.
So what you've done when choosing Electron is to make a very particular tradeoff: You've lowered development costs for yourself, and in exchange the user gets to "enjoy" a program that ignores the target OS's UI completely, hogs resources like mad, and comes with all the quirks you'd expect of someone trying to create serious application software entirely in Javascript - compounded by the fact that anyone doing so in the first place is doing it because they don't have the skills and experience of a non website developer. It's really quite amusing seeing "multiplatform" Electron software take years for a linux release - hello discord.
It's like trying to ice skate uphill, any initial timesaving from not putting the right shoes on is quickly eaten by the fact that the tool you're using was never intended for the job.
That's why people don't like electron. If you don't have a monster computer it runs worse, and even if you do, it behaves like a bad houseguest. Windows has it's own native UI, please use it. So does MacOS. Linux has several that run on the former two. "I optimize code by buying a new CPU" isn't something to be proud of.
+1 to exactly this.
16gb of RAM is "standard", because it came with your NZ$4000 computer? Not everyone is privileged enough to be able to drop that kinda cash on a computer, and may have to compromise.
Also, spin up a couple of VMs and you might get towards the limit faster.
100% agree with the business case, but "I have lots of RAM available therefore everyone in the world has lots of RAM available" feels like a poor leap of logic.
This. It also says a lot about how much we're ripped off in the Shaky Isles.
And therein lies the problem. When tomorrow actually rolls around, you think the application's resource needs will have been frozen in the past? This seems like a slightly disingenuous argument. If we know one thing about software applications, it is that they will continue to require more and more resources at time goes by.
Don't get me wrong: I use atom sometimes; in fact, it's my tool of choice for writing ReStructuredText (the pandoc plugin is very nice). But it is a resource hog: it takes up close to 1/2 gig on disk, uses a lot of memory, and relatively frequently spins our of control, necessitating a restart to get my CPU back.
I run on a 16 gig high-end laptop too, and it's doable, but it's bit a bloated.
Agreed. I especially appreciate you addressing the point about software resource usage increasing over time. Its target is an old hat argument, and a strawman: just because you have a machine with 16GB of RAM doesn't somehow mean that running programs that consume prodigious resources is justified.
It's more than disingenuous: it's brain-dead. It's an attitude that leads to software obesity, where a chat client (Slack) now needs 2GB of my 8GB of memory all for itself. And no, "Just upgrade your machine" is not a valid argument in defence of software bloat.
Why do you think Adobe Air failed?
Because mobile and light web apps took over.
Reason why NodeJS and Electron is taking off is simple - because anyone can bang out a Javascript function and use it in a few minutes. Compared to C++/Rust.
But should they? This reminds me of the mess that Visual Basic developers caused in the late 90s. I was one of them, and wrote pretty good code, but the amount of money I made cleaning up OPM's was at least 100x what I made writing my own code.
Making code accessible and fun is a great goal. Making it easier for armchair architects to create black holes is not helpful. And if we don't keep them from peeing in the (npm) pool, then everyone's gonna suffer.
"And if we don't keep them from peeing in the (npm) pool, then everyone's gonna suffer"
And unfortunately it's going to end up this way. Rome didn't last forever.
But it's what makes the job market interesting.
Bloated tech gives rise to something more efficient that entails more training and skills. Differentiating the job markets.
It seems interesting the first one or two times you go through it, but in my experience it ends up feeling less like progress and more like wasted time. It's like tearing down a house because there are too many layers of paint and wallpaper on the walls.
I would much rather see some kind of third-party repository that helps to curate libraries according to varying levels of quality, and offers a contracted level of service to consumers. Sort of like what RHEL does for Linux.