In Defense of Electron

https://dev.to/bitario/in-defense-of-electron

by bhalp1 • 9 years ago

64 153 9 years ago

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?

While it's great to imagine this future world where everyone is running supercomputers, you ignore the overwhelming majority of potential users who aren't running "a 2016 MacBook with 16GB ram". For those not at the cutting edge, many Electron apps are painful to use.

To put it differently, not everyone replaces their computer every year. It may take a long time before everyone "catches up"

simplify• 9 years ago

Yes, and they might be running "a 2011 MacBook with 4GM ram", like me :) I haven't had a compelling reason to upgrade, but apps like slack and atom are really trying to force it. Fortunately there are still apps that care about memory and performance (thank you, Sublime).

akkartik• 9 years ago

Not to mention the gravity-like tendency for apps to grow in memory requirements as machines grow in memory. It's disingenuous to pretend Slack will be snappy on a 16GB machine by the time everyone has it. Microsoft has run out the clock on that particular fallacy.

j454• 9 years ago

8 GB seems to be the minimum norm, and I think the main reason I have 16 is to keep an unreasonable amount of tabs open, because it's 2017.

corndoge• 9 years ago

I have a 2016 16gb mbp and I cannot run two Ubuntu vms, chrome and Slack in 4 teams all at the same time. It is slow and even opens the OOM killer from time to time. And you can forget linking a large project when Slack is open, even with gold.

gatlinnewhouse• 9 years ago

Ahhhhh yes. When people post claims about it's terrible performance they're concerned about how the computer feels.

No. When it comes down to it. Electron hogs and drains a user's laptop battery, which in turn affects their user experience. How hard is that to understand?

Not everyone has a Macbook with decent battery life. Some people don't like Macs, don't like Apple, or simply can't afford one.

If you program with a concern for perform and battery life, it'll run well on a Mac as well as an old computer.

If you code lazily with Electron, some people will notice: a drop in battery life, and a slowing down of their computer's responsiveness.

It's pretty simple really. Code for the lowest common denominator of your target audience.

wlesieutre• 9 years ago

Not everyone has a Macbook with decent battery life.

I have a MacBook with a decent battery life until I run electron apps, then I have a MacBook with crappy battery life.

allover2• 9 years ago

If you code lazily with Electron [...] It's pretty simple really.

It has nothing to do with 'laziness'. You ignored the entire 'The Business Case' section of the article.

Can_Not2• 9 years ago

I think OP was implying that you could code in a non-lazy way while using electron. For example, a lazily coded app would use too many frameworks (e.g. jQuery + jQuery UI + angular 1, 3 http clients, 3 underscore forks) and bad coding practices (many memory leaks and unnecessary duplication, no optimization attempts, team never learned the language, shipping dev builds with extra debug tools to production). Maybe electron isn't as bad as the bad apples draw it down to be. Personally, I'm still interested in something like react native for desktop.

api• 9 years ago

I saw a post called "Electron is flash for the desktop" a while back. I think that's basically true but the rationale is different.

Flash was a way to get true high performance dynamic content on the web before high performance JS, HTML5, and stuff like React. It was a way to be ahead of your time on the web.

Electron on the other hand is more of a fuck you revolt against the desktop.

It's 2017. Desktop computing paradigms are over 30 years old. Yet if I want to write a desktop app I still have to write the f'ing UI at least three times: Windows, Mac, and Linux/BSD. It's not just different APIs either. It's totally alien paradigms: different languages, different ways of specifying a UI, and different API paradigms. This would be defensible if these desktop UIs were substantially different, but they are not. The difference does not justify the divergence under the hood at all.

Qt is the other big cross platform competitor to Electron, but it's also a complete re-implementation of the UI, is almost as heavy, and is in some ways less modern and feature rich. The web has such a huge user base that it's always up to date and always has the latest stuff, while Qt languishes with its own weird way of doing things.

WxWidgets was my favorite past attempt in some ways. Its APIs are ugly and horribly outdated but at least it tried to use native widgets everywhere and look and feel native.

React Native is a neat idea but you still have to drag in a complete JavaScript runtime so you are nearing Electron levels of bloat there.

Someone should do a modern WxWidgets type library using modern APIs and that works with modern C++ (C++11 at least), Go, and Rust.

pfooti• 9 years ago

This is absolutely correct. It may be better in quantifiable end-user metrics to have different native desktop apps for every user. However, it is far worse in developer cost to write those apps in native frameworks. The trade-off being made is not native vs electron, it's electron vs nothing at all.

zargon• 9 years ago

No, it's not electron vs. nothing. It's one good single-platform application vs. one terrible cross-platform application. If you don't have resources for developing on multiple platforms, it is OK to choose one.

Asooka• 9 years ago

That modern WxWidgets library would be just Electron in everything but name (because you want people to use it, so you'll have to support what people already know, which is html+js) and people would abuse the abundance of resources on modern desktops just the same. Electron itself is not the problem. Awful usage of Electron is the problem. I would say Electron is the desktop equivalent of PHP. It lets people who don't know why signed left shift can invoke undefined behaviour and don't care if their code is indented with a mix of spaces and tabs, i.e. people who aren't the minutiae perfectionists that native APIs require them to be, to write dumb GUI apps in something that isn't tied to Microsoft's whims and has a learning curve reminiscent of a kiddie pool.

What we need is some better linters, profilers, &c integrated in development environments used to write Electron apps, to help and inform the authors of how to write the most performant GUI possible. People won't write GUI using VisualC 6 + MFC ever again, I see it as best to just meet them halfway.

ttoinou3• 9 years ago

   Someone should do a modern WxWidgets type library using modern APIs and that works with modern C++ (C++11 at least), Go, and Rust.

The most minimal effort to do that would be to improve wxWidgets rather than begin a new library from scratch (PS : I use wxWidgets and it's great !)

rectang• 9 years ago

Yet if I want to write a desktop app I still have to write the f'ing UI at least three times: Windows, Mac, and Linux/BSD.

Vendors and developers do not have the same interests. Developers want to maximize the market for their skills. Vendors want to lock you in, and are perfectly happy to waste your time and harm your career to do it.

ahartmetz• 9 years ago

Qt is absolutely not "almost as heavy" in memory or CPU time. Maybe in disk space. It also allows customization at several abstraction levels, which is what makes it more flexible than most of the competition.

merrvk• 9 years ago

Our react native apps are around 10 - 15 mb in size once bundled, which is hardly bloated.

santaclaus2• 9 years ago

I feel like there is an economics PhD thesis on Electron apps and the tragedy of the commons (battery life and ram) waiting to be written.

daenney• 9 years ago

I think we too easily conflate Electron and apps based on Electron. If you take the Electron demo app, you won't notice it. It has no impact on your machine whatsoever. Plenty of Electron based apps though have abysmal performance and a negative impact on battery life etc. I've also come across a few that behave like proper citizens. A lot of what makes people frustrated with Electron based apps isn't actually caused by Electron, but what people have layered on top of it.

I think it was with Slack recently that someone noticed they actually ship the dev build of their JS code. Which would explain a thing or two about its performance and resource usage.

andrewfong• 9 years ago

This. Atom kills my CPU fan, but VSCode is pretty quiet.

I also noticed that Slack was significantly more performant when I went from being on 5 different Slack teams to just one. Which suggests that there might be something related to how Slack handles background chat updates.

hex132• 9 years ago

I never understood why to run Slack as desktop app if Slack can be run in a browser with the same GUI and features. Am I missing something?

j454• 9 years ago

Agreed. Developers make the mess in their architectural decisions, not so much the tooling.

laythea• 9 years ago

If a motorcycle owner install's an ashtray on his/her motorcycle, is it the ashtray's fault?

mamcx3• 9 years ago

Is the fault of the developer that use it, the developers that build it, the ones that proclaim is a good tool, electron, node, html, css, javascript and the rest of the industry.

randomsofr• 9 years ago

But, Atom hangs up like crazy when opening big projects or big files, that doesn't happen on Sublime for example.

santaclaus2• 9 years ago

This is usually an issue with syntax highlighting. Turn off syntax highlighting and VS Code, for instance, can load pretty large files. Why most Electron based editors don't implement better syntax highlighting engines is beyond me...

cmiles743• 9 years ago

The casual dismissal of the complaints from their customers really rubs me the wrong way. For sure, technical people know what Electron is and many have a bias against it. But the bias isn't irrational, it's driven by very real needs.

The author is right in that a non-technical person won't know what Electron is and when their computer becomes slow and hot or runs out of battery more quickly, they will not know where to lay the blame. They might think, as many members of my family love to tell me, that their computer battery is just "way too old" and "never lasts long", or that Windows "is so slow, is Linux any faster?"

I can run a couple of Electron applications and I do often. My office uses Slack, so I run that all the time. There are a couple others I need here and there and when they are all running at the same time, my laptop gets warm, the fan switches into high gear and soon I'm reaching for a power adapter. If I'm at an airport or traveling I can decide that I'm not running these applications and lengthen my battery life.

Electron is a compromise and I understand that. What I wouldn't be keen on is a situation where everything I do is an Electron app. Someone had a nice resource monitor that looked really neat, but it was an Electron application. I liked the look but I can't afford to add that application to my power/memory/CPU budget just 'cause it looks cool.

My point is this: I don't think it's a good idea to simply sweep away a segment of customer complaints because those customers happen to know what Electron is and notice the effects on their machines. As more Electron apps come to market, literally fewer will be able to share a customer's laptop or workstation. Atom and VS Code have already staked out some critical ground, their customers simply will not give them up. That leaves that much less room for other Electron apps and given the speed with which these apps are appearing, that space is going to be crowded and contentious.

_ar7• 9 years ago

My question would be what's the alternative? Cross platform native apps rarely look as good, and would require entirely new code bases and different sets of developers. Sure electron sucks for users, but what's the business incentive to ship native apps other than to satisfy the minority of users who are even aware electron saps so many resources?

I think that for whomever is developing using electron in most cases the desktop versions of the apps wouldn't even exist if electron wasn't a thing. Also, just as a side note, electron apps are so _easy_ to develop. I don't know if any other platforms that target desktop are as simple, but I might just be out of the loop.

cmiles743• 9 years ago

I'm a dreamer, I know it, but I still would like some kind of easy-to-use, developer friendly cross-platform UI toolkit. I used to do Swing development and, eventually, I learned to appreciate it. I understand why more people aren't jumping on the Swing train at this point but I have to say, the UI provided by Swing was less restrictive than the one provided by Electron.

Something in between would gain traction, I think, as Electron developer's run up against the hard edge of the kinds of UI Electron apps will allow.

rmrfrmrf5• 9 years ago

the UI provided by Swing was less restrictive than the one provided by Electron.

I really want to know the use cases you're talking about, because, to me, nothing could be further from the opposite.

kuschku4• 9 years ago

Have you tried JavaFX? It is awesome to work with.

owebmaster• 9 years ago

If the critics of Electron keep rising, like JS, I'm also planning to invest more on it. JavaScript has been paying great dividends to me despite all the bashing.

maxxxxx2• 9 years ago

In my view Electron is a total innovation killer. You can only use web controls, no custom controls. It's a nice way to start an app but you soon hit a wall because you can't do much performance tuning because you don't own most of the code.

I know there are no good multi platform UI kits but there but Electron seems a really bad direction from a technology point of view to me. Maybe we should give Java another go?

Jare2• 9 years ago

If I have a Java GUI app running on my system, Electron apps become the least of my bloat concerns.

maxxxxx2• 9 years ago

IS that true? Java is not great but Electron seems really bad.

kuschku4• 9 years ago

Why?

Let’s compare the electron-based Minecraft launcher with Minecraft itself.

The download is 400MB vs 11MB (+the 60MB JVM runtime)

The RAM usage is 300-600MB vs. 256MB

I mean, I don’t see how electron comes out ahead in this (and it only runs the damn launcher, not the actual game).

Java definitely is the least of your worries. And with JavaFX you can even use the web APIs for UI.

ionised• 9 years ago

My experience of using both is that Electron apps are far worse.

Yhippa• 9 years ago

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

I've been waiting for years for a cheap laptop with 4-8 GB RAM that's got a quad-core processor for development and light gaming. It seems those machines are always north of $600. If anybody has suggestions of what to do without going used I'd love to hear them.

SwellJoe• 9 years ago

I got a refurb Dell gaming laptop from Dell Outlet with 16GB of RAM, an i7 CPU, a 4k 15.6" touchscreen display, and an nVidia GT960M GPU for about $695; that was with a 20% or 25% off coupon, but those come up pretty regularly. It's a beast and plays games well. Surely, you can find something reasonable for under $600, with spec requirements as modest as the ones you've listed.

My Dell isn't a nice machine, by any means...it's a standard plastic job, but when I've bought higher end models in the past, they haven't lasted significantly longer than cheapo consumer models, so I just accept the cheap feel of the thing and save the $500+ that better builds cost.

It runs Linux very well today, though it didn't when I bought it, but that was due to video drivers, which would have been true of any device with a 4k display and the GT960M GPU.

And, on the subject of Electron, I started using Atom at the same time I got this new machine. It runs fine, alongside Firefox with a gazillion open tabs, Thunderbird with a hundred thousand emails in the inbox, and a Gnome terminal with a dozen or so tabs.

joe5150• 9 years ago

There are quite a few laptops meeting those specs on Amazon right now, and some of them don't look bad [1].

1: https://smile.amazon.com/s/ref=sr_nr_p_n_size_browse-bin_2?f...

rcarmo5• 9 years ago

I read the business case section and... I got the rationale right up to the point where it says "You can just pass the cost down to your customers" and compared it to my feelings regarding delivering quality solutions.

Electron is a crutch. A crutch that people resort to because it's effectively impossible to write quick and dirty cross-platform desktop apps in anything else, but, worse still, a _debilitating_ crutch that, unless you know what you are doing (and I daresay that is something people should be looking into) delivers overly bloated, resource-guzzling apps that wreck usability, battery life and (most visibly) RAM in _any_ OS.

I don't have 16GB of RAM everywhere. Statistically, NOBODY does, in the sense that the average user (who is not, usually, a developer or a power user) is probably using a Windows PC with 4GB of RAM where a _single_ Electron app can take up over half of system resources.

And I find the initial premises laughable. Whenever I ran Slack on my 16GB MacBook Pro, battery life took a nosedive - visibly so. JavaFX apps like Nightcode are far more efficient (but I digress and am probably summoning a few trolls).

So no, I don't think Electron is defensible. It is _marginally_ defensible if you want to get an MVP out, or if your real desktop app is still in the works. Excusing it by saying it will cost you more to hire someone who knows how to do cross-platform development in something like Qt or Xamarin and deliver a more efficient, higher quality product is not an excuse, it's a cop-out.

vvanders• 9 years ago

So what's your answer to Visual Studio Code then?

I see Electron as opening up desktop development to developers who previously wouldn't have the been able to do it. Should we gatekeep just because developers don't have the resources to do a proper native app?

Jtsummers5• 9 years ago

How does Electron open up desktop development to developers? If they were already developers, how were they unable to use any of the many free (or inexpensive) development environments out there?

For macOS, XCode has been free for as long as I've been using Macs (2006). For Linux, it's essentially all free. For Windows, yeah, it used to be expensive but setting aside full-fledged Visual Studio, there were lots of options that were either free or cheap.

Just because we have a huge influx of developers who only know or want to use JavaScript doesn't mean my laptop battery, memory, and CPU need to cry every time I open up a note taking app.

j454• 9 years ago

What about desktop developers who know better to spend months developing something that can be built in weeks to solve a problem, and then determine if further action is needed?

Its understandable if native developers will lean towards advocating for native apps, and non-native app developers don't.

There's lots of folks however, who can comfortably do both and may believe value is just not in performance up front, but solving problems that add and create value.

rcarmo5• 9 years ago

The answer might surprise you: I work for Microsoft and use Code daily.

I like it and appreciate the relentless tweaking the team has been doing to wrestle down the Electron bloat (hence one of the parentheses above), but it's not immune to it -- on my desktop Mac (a 7-year-old mid-2010 Mac mini with 8GB of RAM) I routinely have to kill it and fire up TextMate or vim instead.

On a 4GB Surface Pro 4 (which is closer to the average I mentioned) I can usually only run Edge, Code, Chrome and the native mail app before things start slowing down -- and by that I mean that every individual app is fast a few seconds after I switch to it, but swapping has begun in earnest and moving to and fro between docs, code and testing lags enough for me to start getting frustrated -- at which point I usually fire up vim inside the Linux subsystem.

As an aside, I don't have Slack (or any other Electron app but Code) installed anywhere -- I just use the most lightweight browser on any platform to get at that kind of thing.

coldtea5• 9 years ago

Visual Studio Code is not written by "developers who previously wouldn't have the been able to do it" but by highly expert developers at Microsoft, paid full time for that.

Amateurs can and do write plugins for it of course, mainly because JS is easy and popular and with huge already existing npm libs to leverage.

But take something like Sublime Text, coded by a single person, multiplatform, with tons of plugins too (though less, since it depends on Python), and with very fast performance.

An ST that had a few more hands, and a few more exposed UI controls for plugins would absolutely trump VSCode in all aspects -- especially if it embedded V8 for JS plugins to work there too (not Chrome/Blink/Electron: just the JS engine like it does with Python).

mixedCase4• 9 years ago

So what's your answer to Visual Studio Code then?

Sublime Text, Kate, Notepad++ if you're looking for the same low learning curve or Vim/Emacs if you have experience or are willing to learn either.

Two days ago I finally snapped when I was refactoring a codebase that required me to have 4 VS Code windows open.

Together with my regular browser I was eating 12 GB of RAM and I had no VMs open as I often do. The system ran slow as dirt despite having an FX-8320 (not a new chip, but it's no slouch and it's still an 8-core), an SSD and 4 more GB of RAM to spare.

That's just downright unacceptable.

I see Electron as opening up desktop development to developers who previously wouldn't have the been able to do it. Should we gatekeep just because developers don't have the resources to do a proper native app?

Excuse my french, but come the fuck on. I was 11 years old when I grabbed a copy of Visual Basic 6 because "I wanted to be a 1337 haxxor" and was able to drag and drop buttons and text inputs into an empty dotted window, bang them together a bit, copy paste some code from forums and have them working to some extent with no programming knowledge.

You're treating JavaScript programmers as if they're mentally deficient just because many of them are new to the industry and don't know tools that aren't fashionable. If they grabbed Qt Creator and QML docs they would be producing lightweight apps in no time.

KirinDave5• 9 years ago

Electron is a crutch. A crutch that people resort to because it's effectively impossible to write quick and dirty cross-platform desktop apps in anything else, but, worse still, a _debilitating_ crutch that, unless you know what you are doing (and I daresay that is something people should be looking into) delivers overly bloated, resource-guzzling apps that wreck usability, battery life and (most visibly) RAM in _any_ OS.

See, the other word for crutch is " force multiplier". And in one sense, the crutch is for the almost comically broken state of cross platform UI toolkits. GTK+ is inadequate and hard to use. KDE not only mandates language choices and tooling but also offers only marginal improvement.

Every "good" and widely praised xplat GUI toolkit is either custom built for a browser or IN a browser. Apple's toolkit gets praise, but is hardly crossplatform. Microsoft is starting to ship an option, but it's not well cooked yet.

It's one thing to note the problems with electron. It's another entirely too imply it has genuine competition. As far as I can tell, it does not.

rcarmo5• 9 years ago

It does if you are willing to step out of the "let's do everything in HTML and JS" echo chamber - hence my mentioning there is no alternative for quick and dirty apps.

pdog• 9 years ago

Sorry, but the alternative to using Electron isn't JavaFX or Qt or Xamarin. It's nothing. People weren't writing cross-platform desktop apps before Electron. For that reason alone, Electron is great.

coldtea5• 9 years ago

People weren't writing cross-platform desktop apps before Electron.

Perhaps you weren't there, but they did. By the tons.

Heck, take something like Sublime Text, that pisses on Atom on all performance metrics, and is coded by a SINGLE person for 3 platforms.

zzalpha7• 9 years ago

People weren't writing cross-platform desktop apps before Electron.

Oh. Wow.

Are we really at the point where people are rewriting history that profoundly in order to justify Electron?

Let's see... on my computer, right now, I have installed the following cross-platform desktop applications, none of which are built with Electron:

1. Chrome itself

2. Firefox

3. IntelliJ

4. Vim

5. LibreOffice

6. LyX

7. Gimp

8. VLC

9. Steam

10. VirtualBox

11. Ardour

And that's just off the top of my head.

gaius2• 9 years ago

it's effectively impossible to write quick and dirty cross-platform desktop apps in anything else,

A Tcl/Tk app packaged with StarKit would be better and consume literally one-tenth of the resource, and quite possibly one-hundredth.

rcarmo5• 9 years ago

Actually, I've been teaching my kids to write simple Tkinter apps. :)

mamcx3• 9 years ago

To make a good case with TK is necessary to have something alike Bootstrap or anything that look good.

I will love to have a good Widget for multiplatform (and hopefully including iOS) but most toolkits have terrible looks. That alone is a turn-off.

amedvednikov• 9 years ago

Agreed. That's why I developed a lightweight native client for Slack, Skype and others:

https://eul.im

It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag.

rmrfrmrf5• 9 years ago

Yes, Chrome is a memory hog, but that's nothing new. The thing is, Chrome still runs just fine on the laptops-of-old with 4 gigs of memory. I've always just assumed that Chrome likes to use whatever memory it can find (which, for people with a lot of memory who only browse the web, is probably what they want). Acting like these Electron apps are un-useable without supercomputers is silly.

rcarmo5• 9 years ago

Actually, each Electron app ships with its own version of Chromium, and if you have multiple apps running you will have multiple instances of _approximately_ the same runtime, but zero shared resources across apps - no shared executable segments, no shared RAM, nothing.

So the bloat is actually bigger than running multiple instances of Chrome.

Jtsummers5• 9 years ago

Electron apps need to take the route that Eclipse used and uses. Eclipse is a resource intensive Java application (though it feels much better these days than when I first used it 12 or so years ago). One runtime, with a mechanism for installing new "views" and such. Some applications were delivered as complete Eclipse runtime downloads plus the custom additions, but usually you could just download those custom parts directly into your Eclipse runtime.

That was a reasonably effective use of a common runtime and resource.

rmrfrmrf5• 9 years ago

Sounds like these apps are built with security and portability in mind ;). Seriously, though, this seems like an implementation issue that can/will improve over time. I can see the case where, yeah, if your users care about what your stack looks like and they refuse to use Electron apps, then sure, use something else (same goes if your users are laptop-heavy users with concerns about battery life). Some devs don't have those constraints and that's where Electron can fit in.

ttoinou3• 9 years ago

I don't mind writing the core of my software in platform specific C / C++ but I really like the idea of using web technologies for the UI + manipulating data in JSON for software IO (thus having a minimal JS engine). Does anyone know of a good middle ground ? I need CSS, VueJS and SVG. From what I read on the internet all I found is to link myself to the libchromiumcontent library

http://www.chromium.org/developers/content-module

sullichin• 9 years ago

Crazy that the people posting here would have a computer from 2010 with 4GB of RAM.

rmrfrmrf5• 9 years ago

MacBook Air (I think it's 2013) with 4GB is still chugging! Runs Electron apps fine.

sevensor3• 9 years ago

I have such a machine. It's a netbook. It does a great job running Arch Linux. It dual-boots Windows 7, but Windows 7 long since became unbearably slow and I've stopped using it. Sway and urxvt are very snappy, however. Kakoune never lags -- I see my keystrokes right away, even with syntax highlighting turned on. It also starts instantly. Even emacs runs pretty fast, although it feels a little heavier. But Atom? Forget it. It starts five electron processes and pegs the CPU. pacman -Rsc atom.

The thinking espoused by the article is rooted firmly in the last decade: "Moore's law will allow us to invest no effort in writing efficient software."

matthberg4• 9 years ago

It's off topic, but how is sway? I have an old netbook with an Intel i3 processor, which I'm setting up with arch (because it's the only thing that the computer can support, thanks to the blatant neglect of efficiency from the ideas of this article). Think it's worth a shot?

gaius2• 9 years ago

My laptop is a 2008 MacBook Pro with a 2.4Ghz Core 2 Duo and 4G RAM. It's perfectly fine for running R Studio, Emacs, Python, Excel, Safari and VirtualBox with 1 or 2 VMs. Yet a trivial Electron app will make it crawl with the fan spinning like a jet about to take off.

dullgiulio• 9 years ago

Thanks to the very absence of Javascript from this site, people can post here even if they have 4MB of RAM. And that is a very good thing.

j454• 9 years ago

One question that seems to go unacknlowedged around rapid development tools like Electron is: Does it trivialize work that others think are much harder?

A lot of devs have studied native app development before doing some amount of web development, or in this case mobile html app development.

By learning the technical natures of native app development perhaps a little too soon, devs can miss out on the incredibly deep lessons you can learn from rapidly iterating and solving customer problems, because most customers do not care what something is built in.

There's no question Electron (like anything) could be better in some ways, however, for it's strengths in ease and ability to test a solution with the market (and discover it's more than good enough), are toolsets like Electron really that bad?

There is a path to justify native apps in my mind, a path that when possible to go through tools like react, react-native, electron to build working solutions, is valid, and fine. The need to optimize the speed and performance, say in a native application.

Jtsummers5• 9 years ago

  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.

Focusing on the first part: Why would you be making the same changes 6 times? Is your code so tightly coupled between logic and display that you haven't reduced the common features to, essentially, libraries at this point? Separation of concerns is not a novel concept.

And Mac developers hard to find? From what I keep reading here, MacBook Pros are the development machine to have. I can't imagine that it's so hard to find a Mac developer as this post suggests.

  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.

If you're one, solitary, person, you aren't a team. Just like there's no army of one, despite the pervasive recruiting posters and videos years ago.

I'm glad Electron is letting you produce yet another note taking app. We need more of those. I hope it goes well. But please, please, please: I'm tired of my battery dying before I finish one cup of coffee at the coffee shop because of these inefficient apps.

Will someone, please, make Positron, the anti-Electron. It needs to be as portable as Electron (ideally), but based on a better runtime and language. Hell, Elixir is popular, let's go with that. You'll get great concurrency from the start, and hot code loading, and a decent language

agentultra3• 9 years ago

Maybe https://github.com/Widdershin/positron

A real contender to Electron is going to have to ship a runtime or libraries that support the DOM and all of the APIs a browser like Chrome already ships along with a Javascript engine.

Maybe if we could break those all up into cross-platform shared libraries it could be done.

Jtsummers5• 9 years ago

It only has to support the DOM and web technologies if we decide it needs to be compatible with web technologies. That's not actually needed for a cross-platform toolkit like this.

Regarding your link, it's for JavaScript -> Android Native.

I found another project that was an Electron-compatible effort on top of Gecko. I haven't done much other searching for things based on the name, honestly Positron just popped into my head while reading the original article so I used it here.

mcphage2• 9 years ago

Is your code so tightly coupled between logic and display that you haven't reduced the common features to, essentially, libraries at this point? Separation of concerns is not a novel concept.

No, I don't think many development companies have reduced the common features of codebases in 3 different languages to libraries yet.

Jtsummers5• 9 years ago

Different platforms, not languages, per the posted article.

Of course it's hard to combine multiple languages into a single library set, but if you're dealing with multiple languages you're often already dealing with multiple applications anyways and not combining them into one singular application. Or you've figured out FFI and can deal with the multiple language issue that way, in which case, wait, you have libraries in other languages!

Matthias2472• 9 years ago

Hell, Elixir is popular, let's go with that. You'll get great concurrency from the start, and hot code loading, and a decent language

Just a comment on that: Different use-cases have different solutions. While the Erlang/Elixir model might work great for servers we gained the knowledge that a singlethreaded event-driven model seems to work best for user interfaces, because they are very stateful things. Multithreaded user-interface technologies (which is what Erlang would be - even though you have actors instead of threads) have afaik never worked out. Javascript however embraces the singlethreaded event-driven model up to the point where no shared-memory parallelism is possible - which works well for user interfaces. You don't even can't have the error anymore that some callbacks runs from another thread than expected (which is a typical error in GUI implementations in Java and C#).

And another remark: If the main goal of the change is to improve performance and resource usage, I also don't think Elixir would bring us forward. The erlang VM isn't a super-high performance environment, most likely electron/node/V8 is faster.

harisvs-code• 9 years ago

I have been experimenting with a hybrid desktop app building technique for past few days.

Doesn't hog memory and you can build business logic in javascript.

this is a shameless self-plug! :-)

https://github.com/harisvsulaiman/agenda-realtime

devrandomguy2• 9 years ago

Having specialized in the web stack, it really pains me to see this fail. However, it is unreasonable and counterproductive to expect end user devices to continually increase in computing power and memory.

The future, for most users, is in smaller, cheaper, more deeply integrated devices, not in faster stronger devices. Just look at the smart watches of today, the AR kits of tomorrow, the joule-thief powered IoT devices that don't require a power connection. This is where we are headed, not towards epic gaming rigs for everyone.

I can only hope that in time, we will develop more efficient native implementations of the DOM, even if that means a major breaking change. IMO, the web layer is well suited to bridging the divide between vastly dissimilar hardware platforms, especially as the number of unique platforms explodes into a lush jungle of diversity and ubiquity.

rmrfrmrf5• 9 years ago

We're declaring Electron dead now?

devrandomguy2• 9 years ago

Failing is not dying, it is just a painful phase of growth and change. At least, that's how I choose to view my own failures.

agentultra3• 9 years ago

What I find interesting is that in AAA game development performance is treated as a budget. You can write in a cross-platform engine but the tradeoff... is performance. It's always performance.

And yet we can port games to almost every platform conceivable when the code is appropriately architected.

Somehow this reality of programming eludes desktop and enterprise developers.

Jare2• 9 years ago

when the code is appropriately architected

This has a substantial cost. Many games today make this tradeoff as soon as they can. Loading times is often the first victim, but in mobile you see it everywhere, even simple 2D puzzlers that can't hit 60 fps and still burn battery like crazy.

scarface74• 9 years ago

Even if computers are getting better, faster, and coming with more memory, battery technology isn't improving by leaps and bounds.

Apps that are a battery hog aren't an option.

spacelizard• 9 years ago

Why is Electron still such a memory hog? Wasn't the Chromium Content module supposed to dramatically reduce footprint by only providing the bare minimum to render a web page?

hzhou3212• 9 years ago

I don't use atom, but I don't understand why it needs to be defended or why people would attack it in the first place. If you don't like atom, like me, then don't use it. Is it deep down that you are really envying people using atom as their daily driver while you can't (do the same comfortably)?

After all, it is just a text editor, not like a hot technology that your boss will force down your throat, right?

pyre• 9 years ago

I think that Slack is the top-offender in the "people love to complain about it" camp (for Electron apps), not necessarily Atom.

matthberg4• 9 years ago

I think atom is just a prevalent example of an election app. I for one dislike it and use sublime text instead, but not all electron based apps are as replaceable. Slack, another electron based app, is an example. It is something that bosses force down everyone's throats.

The issue is not with atom, it is with the inefficiency that electron based apps bring.

hzhou3212• 9 years ago

That makes sense. It was not obvious from reading the article and comments. Thanks.

aeorgnoieang• 9 years ago

Why would anyone that needs to use Slack not be able to use the web version? I don't even need to use Slack, but I use the web version, and its because I didn't like the desktop one. But I still think using Electron is a reasonable tradeoff for developing a cross-platform desktop app.

mahyarm• 9 years ago

How practical is react native for writing desktop / mobile apps from the same javascript codebase? I know the mainline has android / ios ux outputs and there are forks that have osx & windows outputs.

How does it compare to electron? From what I understand, react native is just a javascript vm + native UX libs.

I've also heard that react native isn't as much of a priority anymore at facebook.

jaas• 9 years ago

The entire defense/post boils down to this line:

"... I ought to be more concerned with where the trend in memory is going rather than where it has been."

The problem with this line of argument is that it never ends. Developers who accept this line of argument are always aiming five years down the road, and thus always delivering a poor or substandard experience to their current users.

Your future users are not real, and if you're always targeting future users you're never targeting real people.

theandrewbailey• 9 years ago

It's kind of like "You go to war with the army you have"- I mean, your code runs on computers people have, not the ones you wish they had.

ithilglin9092• 9 years ago

But "the army you have" could also be the dev team you have..

b123400• 9 years ago

I think it absolutely makes sense in business, making low quality product is fine especially when users are nontechnical, they just don't know which app is slow. Though as a developer, I cannot be proud of myself for making low quality electron apps, there is no craftsmanship to be proud of.

Moreover, if the argument of "it is slower but it costs less to make so it's ok" makes sense, then will people start mining bitcoin with client's computation power because it's "cheaper"?

ocdtrekkie• 9 years ago

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

Uh... 4 GB is the prevailing standard for the average user PC.

christophilus• 9 years ago

I really hope red-lang[1] or something like it takes off. We really need a quick (to develop), performant, aesthetically pleasing cross-platform GUI story. I hope Red accomplishes that.

[1] http://www.red-lang.org/

iffycan• 9 years ago

As someone who produces an Electron-based app, I was curious what my energy use was as reported by Activity Monitor.

Avg Energy Impact:

- 14.08 Google Chrome

- 3.01 Docker (for Mac)

- 2.55 Sublime Text

- 2.04 Slack

- 2.03 Terminal

- 0.28 Mail

- 0.20 My Electron app (which hasn't been open all day, so this number is definitely wrong)

Some of those surprise me.

Those who complain about Electron being a hog are right. But it's not like there's nothing that can be done about it. I'm sure there are optimizations that could be made to reduce resource usage. Firefox recently improved memory usage. With enough demand, I'm sure Chrome could, too.

coldtea5• 9 years ago

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.

Yeah, all those pesky actual metrics...

coldtea5• 9 years ago

Imagine if Mitch Kapor haven't siphoned tons of money into a BS open source calendaring app that was doomed from the start, but into a useful open source cross platform UI toolkit (and that's not Qt).

matthberg4• 9 years ago

The main issue I have with the article is that it invalidates all attempts at efficiency because the author's computer can run the apps, and future computers can run the apps. That excludes a vast percentage of the consumer market, while excusing bad developer behavior that barely keeps up with the pace of technological development.

Glyptodon• 9 years ago

Running Atom on my machine seems to use maybe 600MB with a project open, am I missing something?

zmix• 9 years ago

With xulrunner we had something very similare to Electron, albeit much smaller, less hoggish. Too bad, Mozilla never ever took XUL further, despite many people (many in Intranets) asking for an IDE.

jitl• 9 years ago

TL;DR: One man’s “this is fine” is another’s raging house fire.

I use the same spec’d computer as the author, but I regularly quit Slack when I notice my fans spin up or my other apps swapping. Usually the culprit is a GIF in Slack burning 100% of a core or my entire organization’s thousands of channels bloating my working set. Either way, a restart is in order.

I think the fixed-size 100mb RAM cost of a typical Electon app is lamentable, but a non-issue with 16gb RAM + virtual memory + SSD.

If I ever need to write a desktop app, I’ll still use Electron — I’m not going to learn QT or Tk, or force my team to do the same.

MaymayMaster• 9 years ago

What is your product so that I know in advance to completely avoid it?

camgunz• 9 years ago

We should start treating this like a cultural issue. The PC existed for a generation before there was a real Internet, and at that point all apps were desktop apps -- CLI, GUI or otherwise. Then the web came along and it sucked. Then Gmail came along and showed it didn't have to suck, and further that you could build real applications on the web using JavaScript. Then a truly insane number of people learned JavaScript and JavaScript only, and since JavaScript only ran on the web they only built web apps with it.

The vast, vast majority of new, young programmers only know JavaScript, or maybe they know JavaScript and a "backend" language like Ruby, Python, or PHP, but that's less likely now post-node.

The vast, vast majority of cool, new tech needs to be built by programmers, and because of cultural reasons (young people are cool!) and business reasons (young people are cheap and otherwise exploitable!), those programmers are new, young programmers.

And so if your app now needs to be a desktop app, and you have a bunch of new, young programmers who are only really conversant with JavaScript, which UI framework will you use:

- Qt. Sure you can use Qt Quick, but it doesn't really run on the web and your engineers have almost certainly never used it.

- Electron. Sure it's objectively bad, but it runs everywhere you care about and your engineers can start today.

Or, if it's easier, look at it from the perspective of a young JS dev. They know JS; they're good at building SPAs; they have an app idea; .......they're probably building it in JS.

The arguments against Electron all boil down to "the web is a shitty application platform and JS is a shit language". You can't expect JS devs to cop to that, especially with the web as successful as it is.

I'm -- if you can't tell by my vaguely grouchy tone -- not an Electron fan. But my side fucked up. We let a gross blob of inefficient, JavaScript-running C++ code (that we charitably refer to as "the browser") become the platform of the future. We designed it in the worst ways, either in 10 days or by committee, and we didn't take it seriously ever. And it's only now that our jobs force us to use web apps that we suddenly give a shit, and for some reason we feel like none of this is our fault.

All I can really say is grousing about it just feels like deflection. Let's just try and not mess the next one of these up.

nkkollaw• 9 years ago

How can the author think that it's normal for regular people to have 16GB of RAM?

The case of not being important to use GBs of RAM can be made if the app is Atom and it's a tool for developers, but regular people still have 2GB of RAM, not 16 or even 8.

In Defense of Electron

Related Stories