loading...

In Defense of Electron

bitario profile image Mo Bitar Updated on ・5 min read

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.

Posted on by:

bitario profile

Mo Bitar

@bitario

Passionate about product and software. Working on Standard Notes, a simple and private notes app.

Discussion

markdown guide
 

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.

smalltalk-based software masterworks like... uh... hmmm

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.

 

The computer industry has been stuck on 8GB for what seems like far too long, but 16GB standard is finally looking to be a reality.

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.

 

I have nothing particularly against Electron, and I do occasionally use VSCode.

However, we had an extremely extensible text editor/IDE in the form of Emacs for a very long time. That includes autocompletion, minimaps, Emmet, rendering Markdown previews, interacting with git, Chrome remote debugging, git-timemachine etc, which are some of the most heralded features/downloaded plugins for Atom/VSCode. As far as I'm concerned both of the latter are essentially just re-implementing Emacs for a new generation of developers that are more familiar with JS than Lisp and who have little to no memory of resource constrained environments.

 

But advanced development machines of today are the entry level computers of tomorrow.

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.

 

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.

 

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.

 
 

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).

 

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.

 

Right now, Slack is the second biggest hog on my machine, after Safari -- in terms of the metric that matters most to me: Energy impact.

I compute on the road. A lot. Battery life matters.

I have 31 Safari windows open, with about 4 tabs each. And the energy impact is only a little above Slack.

Yeah, no. I use Slack because I have to -- but on my machine: Atom is no danger of replacing SublimeText, and StandardNotes is in no danger of replacing EverNote.

It simply does not matter to me that you don't have the resources to build an app that meets my needs. That, as they say, is not my problem.

 

Moore's law is not an excuse to design crappy software. Not everyone who criticizes Electron's resource usage is a Unix fetishist that thinks all programs should be small C utilities. It's important to balance performance and productivity, but Electron completely blows this ratio out of proportion. It wouldn't need so much testing and debugging if its design wasn't so convoluted to begin with.

Web technology is for the web. Leave it there.

 

I will agree with others in saying : this post has zero scientific or engineering value. Its' basic argument is "if it runs well on my machine" and "it's easier for us to save money in development". Well those are two very light (to be polite) arguments.
Unfortunately this is the usual level of articles in this page.

 

I have a five year old mac book pro. Quad core & 16 GB. 8 GB is a (bad) choice and has been for some time. Like the author, I have atom open around the clock, slack running. In addition I run stuff like intellij, spotify (which is also a web based UI), chrome, and several docker containers. When my laptop runs hot, the usual suspects are spotify and rogue jvm processes, not atom or slack. Yes atom and slack probably use a bit more CPU and memory than it should but it's fine as long as you have enough RAM.

On the balance of things, optimizing for five year old hardware when writing software for the next five years is not a winning strategy. I can tell you from experience that running a small company targeting more than one UI platform is a royal pain in the ass and a very unrewarding and expensive strategy. It will suck the life out of your company just managing the complexity of that many platforms and getting anything done takes ages. Throw mobile in the mix and you are sure to fail. Most people that actually know what electron is ought to be running decent hardware and are in all likelihood a tiny percentage of your user base. So ignore those people and focus on your real users that actually bring in revenue. As it is, Spotify and Slack are market leading productw, Atom is shaping up to be pretty popular, and I know absolutely nobody in my wide network of developer friends who has done any native desktop UI work in recent years. It's all web based these days. Native UIs on the desktop are dying out rapidly.

The reason that atom is so popular these days is that it actually is pretty damn good. A lot of that has to do with them using electron and using javascript to implement a lot of the features. When it comes to shipping javascript based desktop apps, there are not a lot of options and electron is one of the better ones. Forget about atom being ever reimplemented in something else.

 

"But advanced development machines of today are the entry level computers of tomorrow."

This statement seems to be less true every year. The RAM that I purchased in 2014 is now more expensive than it was then. CPU Advancements seem to be incremental.

 

I'm on a late 2017 Macbook Pro (16GB). I have the following open all day, every day:

  • Slack (3 teams)
  • Discord (+-3 servers)
  • Visual Studio code (at least 5-6 projects open)
  • Hyper.app (2 instances)
  • Caprine - FB Messenger client
  • Gitkraken
  • Wavebox - Email client (2 accounts)

They're all Electron based.

They all work perfectly.

I do not have a problem, even thought I'm probably running Photoshop, Lightroom, Zeplin, Whatsapp, Spotify, multiple windows of Chrome, Firefox, the odd note taking app and at least 20 background utilities.

And goodness me, the people slating Electron because it promotes Javascript, a "buggy" programming language: are you kidding? Disliking Javscript because it is less rigid than C++ (a fantastic language if used appropriately and for the right thing) is a symptom of lack of understanding of the technology as well as a severely parasitic mindset in the world of science.

 

Please share some specific examples of what makes JavaScript buggy, because I use it extensively every day at work and the only bugs I ever see are the ones caused by not thinking of some needed logic when I wrote the code. And don't use any examples from any versions of the language prior to ES2015, because it makes no sense to judge a language today on its problems from years ago.

 

Electron is pretty wasteful, and still not portable to mobile. It is a wonderful solution to create applications fast when resources are only an unimportant issue.

Still, I believe it is bound to be replaced by something else in the near future, and that's progressive Web Apps that are augmented with some extra capabilities (requiring the user's permissions).

This way, the browser engine that runs them is already on the system and you can have graceful degradation by running those parts that doesn't work in the client on your server until it is supported.

 

I cannot stand electron.js apps, they absolutely DEVASTATE battery life on anything mobile I own. I can stream Steam fine, I can play Minecraft without any issues, I can even make calls with Skype, the second I start up a Discord call my laptop/ surface starts screaming at me and dies within a few hours, heck the Surface can't even charge fast enough to keep up with this horrible garbage.
DEATH TO ALL ELECTRON APPS!

 

I will use electron based apps , If you are willing to give me your laptop :P

In My country Computer Hardware is so expensive that I can afford one year living expenses with the money for an Apple Mac Book Pro latest model .

Electron will grow over time .

The problem with electron is every single electron take up its own space and performance.

My Browser is Chrome . If my editor is VSCode and I'm running other other electron apps like whatsapp for desktop.

Wordpress

GitKraken

GitHub Desktop ...

If i run every thing as an electron app My computer will never recover from the hangover I gave .

So Instead of complaining Give me your laptop , I'll use electron apps!!!

 

Here in Brazil the reality about the amount of memory is quite different, and at this point I agree with the other comments.

On the other hand in recent days I have tested the vscode, and unlike Atom, it has behaved much better compared to the use of memory and cpu. In part, I think, for the better quality of the code.

In the long run I believe that the average amount of memory should increase, just as Electron should gain many improvements. As a tool developer for other devs I'm betting on.

 

Am i reading that wrong? $100k divided by 2,000 users is 500? According to my calculations that would be $1m of profit, not 100k.... And i'm supposed to trust you with the crypto protecting all my sensitive notes?

 

As a user and a developer, I love Electron and the concept of it. I hate what it does to my system though. It's February 2018 and I have a (still relatively) beefy laptop - Dell XPS 9530 (16 GB RAM, quad proc Core i7, SSD) and it introduces very substantial lag to almost everything I do. I just had to close out all my apps and chrome windows and went looking for when this resource allocation issue was going to get fixed and found this post.

As more apps are built on Electron, it eats up more resources. I suspect graphics RAM usage is the main culprit here (Intel embeded 460 graphics, probably 4 year old tech now but still very functional) and this needs to be fixed in order to keep everyone happy.

As for the apps I know are built on Electron that I use: 3x Slack teams, VS code, Atom, Postman, and Azure Storage Explorer.

 

This is the same argument made by [pick a vendor] since [pick a year].

Seriously - Sun, Oracle, Microsoft, IBM have all been in this situation over the past twenty-five years, for both server apps and developer tools. Heck, even for some versions of MS Office and Oracle Forms.

If it's been that way since 4MB of RAM was a lot, what makes you think that getting to 16GB is somehow going to fix things? The platform tools will continue to expand, slightly overflowing whatever size container you provide, until we learn how to stop wasting so much CPU and RAM.

How? Now that is a blog post I'd like to read.

 

I experience no lags

You don't? Even when using Atom? pavelfatin.com/typing-with-pleasur...

(I realize you are on a Mac but I suspect the performance is about as optimized on mac as it is on Windows).

 

I think electron works in really specific things, and even then, it won't be for everyone. Like someone already said, a lot of applications that have good electron apps, have an already amazing web app that already works like a standard app, with even push notifications. In my case, with my 16gb I tend to use the slack app as a way to have it separated from the browser. But in my Macbook with 4gb. My good.

I've been working a lot of time lately with my macbook and I started with Atom. It was a really bad experience in the long run. I liked it at the beginning but it got worst. At some point, even using VS Code that felt a little bit better than Atom, and having chrome with some tabs and some other thing... It felt like I was typing in a virtual machine with 1gb of ram to a ssh pc connected in china... really bad.

And in response of some comments saying that electron makes web developers don't get stuck with just the web... couldn't disagree more. Electron separates you completely from the desktop part. You won't have control and at the end you won't be caring about your user experience that most likely won't have the performance it could have even in simpler cases.

 

I am using an i5 with 16GB RAM and a want more cores and at least 32 GB - but why? - my computer is lagging more than it does in 2002. Do I use my computer harder? No! Do I use more applications at the same time? - Not really! So why is using a computer still a pain? Because of stupid lazy programmers loading the whole internet as libraries to do - what? - some chat oder canban boards.

 

2016 Macbook with 16 GB of RAM? What a big boy you are! /sarcasm

Electron went from a crossplatform dream to a mainly Mac-Only product. Very few apps are truly crossplatform.

 

I completely understand the sentiment: you're right that platforms like Electron are the ONLY way for many small and mid-sized dev shops to build cross-platform apps. I love Electron and want to use it myself. But bloaty software development approaches like this are contributing to major global problems. They're the reason why perfectly reasonable machines become outdated after a couple of years even though the user's needs haven't changed much. They waste resources, both in terms of energy usage and obsolete hardware. Also, betting that everyone's machine will have 16 GB and the horsepower to run an Electron app could be more risky than it seems.

So, nah. But wouldn't platforms like React Native for Desktop - where JavaScript and React's JSX are used to compile into a native binary - be the ideal solution here? (Sadly, RN for MacOS/Windows seem very far away from maturity at this point.)

Would this approach not work much better, while providing the same benefits?

 

wxPython. Xamarin. If I were feeling a little experimental, maybe Kivy.

Electron is not the only way for small/mid-sized dev shops to build cross-platform apps. It's merely the one that's caught the zeitgeist.

 

I have a genuine questions for those who oppose using Electron. What solutions do you propose to the problems that it addresses?

 

Learn a compiled programming language. Write software instead of web pages.