
In Defense of Electron - bhalp1
https://dev.to/bitario/in-defense-of-electron
======
rcarmo
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
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?

~~~
mixedCase
> 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.

~~~
stouset
And yet… they don't.

You could continue arguing against the mounting evidence that Qt apps simply
don't perform as well in the marketplace as Electron apps seem to be doing, or
you could accept that perhaps one of your assumptions is wrong.

Having used a few Electron apps on macOS, I'll offer a (mostly poorly-
informed) opinion: Electron is the first cross-platform toolkit I've seen that
has resulted in apps that don't _feel_ out-of-place like their other cross-
platform brethren, the software version of the uncanny valley. Even VS Code,
the first editor I've actually liked since the original TextMate, somehow
doesn't feel out of place (despite being themed uniquely).

There was a list posted earlier of popular cross-platform Qt apps, and most of
them (VLC, Google Earth, VirtualBox) share a common theme: they're effectively
a thin UI around mostly non-Qt content. I'd be surprised if more than 5% of
VLC's use isn't double-clicking a video, watching it, and closing the window
(perhaps with some scrubbing around the content). Most of a user's interaction
with VirtualBox is with the operating system inside of it. And Google Earth
(isn't that dead?) has little toolkit-based UI inside of it, with most of the
space reserved for flying around the planet's surface.

Don't you think it's telling that the most popular cross-platform Qt apps are
the ones with the least amount of Qt UI?

On the other hand, popular Electron apps like VS Code and Slack are _almost
entirely_ about interacting with the UI itself. In the brief window of time
Electron has been out, it's resulted in more popular cross-platform apps of
this vein than Qt has in the 25+ years of its existence.

"Are I out of touch? No, it's the other developers who are wrong!"

~~~
mixedCase
>You could continue arguing against the mounting evidence that Qt apps...

Let me stop you right there since from then on you're thinking with an
incorrect assumption. I'm not talking about Qt Widgets; I'm talking about QML.

And I've already hinted at why we aren't seeing an explosion of QML apps:
Electron is front-end development with desktop APIs. This is something JS
developers already do. On top of that, it's currently _fashionable_. QML
isn't.

It's easy to see why: QML has existed for a while, took some time to mature
and it's not as good for making native _looking_ apps as other traditional
toolkits, therefore it never enjoyed widespread popularity among desktop
developers outside of KDE and embedded development (an area where you need
performance but don't have an an established HIG to follow).

Therefore, it's normal for webdevs to not have even heard of QML or to confuse
it with regular Qt widgets.

> "Are I out of touch? No, it's the other developers who are wrong!"

So before this post you didn't even know what QML is but already took the
moral high ground to disregard me as grumpy grandpa.

> I'll offer a (mostly poorly-informed) opinion: Electron is the first cross-
> platform toolkit I've seen that has resulted in apps that don't feel out-of-
> place like their other cross-platform brethren

I hope you can see why I believe misinformation is the problem behind this
epidemic. QML offers the exact same approach to theming, giving you simple
primitives to create widgets of your own design without the need for an unholy
mess of HTML, CSS and a JavaScript framework; just a tiny bit of QML in a file
and you have your own component rendered on a 3D accelerated scene graph with
the _option_ to add JavaScript for complex logic.

And I actually happen to have an example to back my words up.

Here: [https://github.com/grigio/borderless-
camera](https://github.com/grigio/borderless-camera) is an Electron app the
author posted on a programming subreddit a while ago. Take a look at the
source code, build toolchain and so on; the usual.

I made this as a response to the criticism he got about the high resource
consumption for a seemingly trivial app: [https://gitlab.com/mixedCase/qml-
borderless-camera](https://gitlab.com/mixedCase/qml-borderless-camera) I
invite you to take a look at the app.qml file. That is the entire source code.

~~~
stouset
> QML... is not as good for making native looking apps as other traditional
> toolkits.

In disagreeing with me, somehow you've essentially re-argued my own thesis.

It's not just about looking as good (although that's certainly a component),
it's also about acting like native apps. Electron apps for whatever reason, in
my experience, don't have this problem. Slack _feels_ like a native app. VS
Code _feels_ like a native app.

> So before this post you didn't even know what QML is but already took the
> moral high ground to disregard me as grumpy grandpa.

I spoke to Qt, and QML is literally the "Qt Modeling Language". It renders
elements using Qt Quick. I'm not entirely sure how switching the mechanism for
defining your Qt interface from code to a markup language invalidates my
point.

> And I actually happen to have an example to back my words up.

It's unbelievable to me that you responded to my post about how the most
popular Qt apps are the one with the least Qt interface, with an example of a
Qt app you wrote (using QML) that literally has no interface.

Qt apps haven't taken off because, while they may be easier for developers to
build, they are _worse for users to use_ (by a metric I'm leaving poorly-
defined for the simple reason that I lack a good definition). Easier to
develop but worse for users is not a good selling proposition.

~~~
mixedCase
> it's also about acting like native apps. Slack feels like a native app. VS
> Code feels like a native app.

I'm not sure if you're arguing as if this is powered by some sort of black box
powered magic no one could understand?

Electron is just a website, the Node APIs and a couple of facilities from Gtk,
like menus. You have access to these things or equivalents in QML. You would
know this if you had bothered to learn what it actually is.

> I spoke to Qt, and QML is literally the "Qt Modeling Language". It renders
> elements using Qt Quick. I'm not entirely sure how switching the mechanism
> for defining your Qt interface from code to a markup language invalidates my
> point.

You're literally searching for a couple of terms in Google half-guessing what
some of the words mean and thinking you now understand Qt.

Qt is a big _set of libraries_.

 __Qt widgets __is a traditional widget toolkit that powers things like VLC,
Google Earth and VirtualBox. It 's software-rendered and exclusively
programmed through C++. It's a _subset_ of Qt.

 __QtQuick __is a _different_ subset, that is powered by a 3D-accelerated
scenegraph, can be programmed from QML, JavaScript and C++ and has primitives
both for native-like widgets (QtQuick Controls 1) and simpler, more performant
primitives (QtQuick Controls 2) that allow you to do everything you can do in
a website with the DOM and CSS.

You can mix and match subsets, which is part of the beauty of Qt, but each of
those have completely different purposes.

> It's unbelievable to me that you responded to my post about how the most
> popular Qt apps are the one with the least Qt interface, with an example of
> a Qt app you wrote (using QML) that literally has no interface.

Fine. Have a VS Code prototype just for you, made in under an hour:

[https://i.imgur.com/RPr6VMS.png](https://i.imgur.com/RPr6VMS.png)

Some of it is functional, like tabs and menu. Sidebar and file tree is mere
decoration waiting to be connected to logic. But there's your magical "native
feel" interface in QML.

Ah, and if you were to actually complete the prototype, you could probably rip
off the rich text editing component from the Kate text editor (written in Qt
_widgets_ ) and still be able to use it from _QtQuick_. Meaning you get syntax
coloring, auto complete and many other things for free, if you wanted to.

Here's the code: [https://gitlab.com/mixedCase/poc-qml-
vscode](https://gitlab.com/mixedCase/poc-qml-vscode)

If you have the dependencies installed, you build it with qmake -o Makefile
qml-vscode.pro && make

Enjoy.

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

~~~
hex13
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?

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

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

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

~~~
pantalaimon
It's usually easier to employ someone than to give each of your costumers a
new computer though.

~~~
ithilglin909
Sure, but my point is that if you just don't have the resources to develop
natively, Electron may allow you to "go to war" when you otherwise couldn't.

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

/s

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.

~~~
allover
> 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_Not
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.

~~~
ttoinou

       react native for desktop
    

We're all waiting for that silver bullet

~~~
k_sh
There is this: [https://github.com/ptmt/react-native-
macos](https://github.com/ptmt/react-native-macos)

~~~
nilliams
And also this (cross-plat React Native for Windows/iOS/Android):
[https://github.com/Microsoft/reactxp](https://github.com/Microsoft/reactxp)

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

------
Jtsummers

      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

~~~
mcphage
> 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.

~~~
Jtsummers
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!

~~~
mcphage
> Different platforms, not languages

The article mentions iOS development in Swift, Android development in Kotlin,
and web development in Javascript.

> 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!

As I said, not many development studios do that.

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

~~~
cmiles74
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.

~~~
rmrfrmrf
> 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.

~~~
cmiles74
Warning: this video is old, lengthy, poorly paced and rather dull so feel free
to click ahead. Still, it demonstrates a reasonably complicated Swing
application that looks somewhat like a native Mac OS X application. The video
was put together around 2003 so the look and feel is pretty dated. But the
interface is fairly complicated and it does get feedback to the customer as
soon as they get data out of range, etc.

[https://youtu.be/r_lTGoTscos](https://youtu.be/r_lTGoTscos)

------
coldtea
> _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...

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

------
ttoinou
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](http://www.chromium.org/developers/content-module)

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

~~~
rcarmo
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.

~~~
rmrfrmrf
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.

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

~~~
Jare
> 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.

------
christophilus
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/](http://www.red-lang.org/)

------
maxxxxx
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?

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

~~~
kuschku
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.

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

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

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

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

~~~
rmrfrmrf
We're declaring Electron dead now?

~~~
devrandomguy
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.

------
hzhou321
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?

~~~
matthberg
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.

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

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

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

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

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

~~~
santaclaus
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...

------
harisvs-code
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](https://github.com/harisvsulaiman/agenda-realtime)

------
jitl
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
What is your product so that I know in advance to completely avoid it?

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

------
spacelizard
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?

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

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

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

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

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

------
b123400
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"?

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

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

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

~~~
matthberg
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?

~~~
sevensor
Sway is good, and constantly improving! I'm mostly to the point where I forget
I'm not running i3. There are a couple of things that might keep you on i3,
however:

* Nvidia. I have not had the best of luck running sway on nvidia systems, even using nouveau. This situation is evolving, so things may have gotten better. I've had no problems with amd or intel graphics.

* Your display manager. I boot to the console and type "sway" if I want a graphical session. I've seen display managers get a bit confused by sway -- the display manager's cursor hangs around for the duration of the sway session, or the display manager crashes when sway exits. I haven't tried all of the options, but I've had issues with both gdm and sddm. Hard to blame sway for this, but at the same time it means you have to take your pick between sway and your display manager.

~~~
matthberg
Huh, a shame about the display manager issues, and thanks for the gdm & sddm
warning, I was about to go use them since they apparently recognized sway
([https://wiki.archlinux.org/index.php/Sway#Using_a_display_ma...](https://wiki.archlinux.org/index.php/Sway#Using_a_display_manager)),
but I'll keep looking. As for Nvidia, no worries with the little old netbook,
it's integrated Intel graphics.

~~~
sevensor
I wouldn't totally dismiss gdm and sddm -- my issues could be peculiar to my
hardware, the versions available at the time, and so on. As long as you've got
a fast internet connection, it's only 10-15 minutes to try each one. YMMV, as
they say! Just be ready to hold down the power switch if things go badly. (For
reference, I'm using sway on a netbook with one of AMD's integrated offerings,
maybe Llano? I haven't tried a DM on that machine.)

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

