
Electron considered harmful - kragniz
https://drewdevault.com/2016/11/24/Electron-considered-harmful.html
======
niftich
This had me for the first half, where the author walks you through the 'case
study' applications that offer minimal functionality despite shipping with an
entire browser inside.

But then the essay turns into a rant. It's 2016, people, the ship has sailed
on pretending JS isn't a real programming language. Phrasing the argument the
way he does just betrays his smug elitism.

The fact is, for many types of applications, Electron is a really good fit:
for example, shipping a single-page webapp as a desktop app, a need that
surfaces often in today's world, despite his derision of this concept.

An Electron-wrapped SPA is safer than going to the same website in a multi-
tabbed browser and co-mingling your disparate cookies in the same jar, not to
mention more convenient for the users, because they can treat it like any
other desktop application -- with hardware access, and subject to the OS'
native task management.

For other apps, Electron allows the world's most popular layout system
(HTML+CSS) to be used with one of the world's most popular programming
languages. This is a huge boon for re-using knowledge, and perhaps does lead
to some amateurish projects. Similar criticisms were leveled towards Visual
Basic, where drag-and-drop composing and a good IDE enabled people to quickly
crank out a GUI app from an idea.

~~~
Ianvdl
> It's 2016, people, the ship has sailed on pretending JS isn't a real
> programming language. Phrasing the argument the way he does just betrays his
> smug elitism.

Using the date as an argument is also poor form. JS is a terrible programming
language (I'm not denying that it is a programming language though) regardless
of how popular it is (although I think I might be going against the grain here
on HN, many people here seem to enjoy node.js).

> The fact is, for many types of applications, Electron is a really good fit:
> for example, _shipping a single-page webapp as a desktop app_ , a need that
> surfaces often in today's world, despite his derision of this concept.

I feel it's unreasonable to turn a single web page into a desktop app by
bundling an entire web browser with it.

> ...because they can treat it like any other desktop application -- with
> hardware access, and subject to the OS' native task management.

If you need direct hardware access it probably isn't well-suited to being a
web app in the first place? Why use web technologies for it then?

> For other apps, Electron allows the world's most popular layout system
> (HTML+CSS) to be used with one of the world's most popular programming
> languages. This is a huge boon for re-using knowledge, and perhaps does lead
> to some amateurish projects. Similar criticisms were leveled towards Visual
> Basic, where drag-and-drop composing and a good IDE enabled people to
> quickly crank out a GUI app from an idea.

HTML/CSS can be nice to have in such a situation, although a refusal to learn
other GUI frameworks probably makes for a poor (native) developer.

The resource bloat and (usually) extreme disparity with the native user
interface rarely makes it worthwhile for me to use an electron app. It feels
like forcing a square peg into a round hole because the developer is seemingly
unwilling to consider more appropriate technologies outside of their comfort
zone. Yes, there are well-made electron apps (like VS Code mentioned in the
article), but I, personally, would hate for it to become the norm.

~~~
FrancoDiaz
_JS is a terrible programming language_

I can never see the point of comments like these. Not one person who reads
that will have his mind changed.

 _HTML /CSS can be nice to have in such a situation, although a refusal to
learn other GUI frameworks probably makes for a poor (native) developer._

No it doesn't. Either the developer benefits or doesn't benefit from
"refusing". There's only so much time in the day. I'll refuse to to learn Qt
or gtk+, unless there is some overwhelming benefit for me to learn it.

~~~
Ianvdl
> I can never see the point of comments like these. Not one person who reads
> that will have his mind changed.

I wasn't expecting to change anyone's mind with that. There are more robust
programming languages that don't have the same inconsistencies and
idiosyncrasies and encourages better practices in general (even though it is
true than you can write terrible code in any language).

> No it doesn't. Either the developer benefits or doesn't benefit from
> "refusing". There's only so much time in the day. I'll refuse to to learn Qt
> or gtk+, unless there is some overwhelming benefit for me to learn it.

That is true, but consider that the end product is not necessarily meant to be
most convenient for the developer. Keeping the user in mind when making these
decisions may make you consider more native and less resource-intensive
alternatives. I have read in the past that Electron also posed some
difficulties for screen readers, for example (although I'm not sure if that is
still the case), which might not be something that impacts you as the
developer, but which can make it harder for someone to make use of your
software.

~~~
jeremiep
This means absolutely nothing. Otherwise everyone would be using Haskell, Coq
or Agda. I'm willing to bet your favorite language has an insane amount of
flaws as well (hint - they ALL do, otherwise we'd have converged to the "one
true language" as an industry long, long ago.)

You can make an argument to say C++ is terrible, Java is, Ruby is, Python is,
and it means absolutely nothing other than showing of your own insecurities.
You can build great and mediocre things in any language and any platform.
People do every day.

Also, if the developer is not one of the users of the software, you've already
thrown a good chunk of quality out the window right there. You're simply not
going to have the vision required to build the optimal user experience.

------
traviswingo
I can understand the author's frustration with popular tools being very simple
and somewhat overkill underneath, but I almost take it as a sense of
frustration with himself.

Electron was built to ship products as soon as possible. Most of the time, no
one gives a flying fuck if the tech stack is the "right" choice and as
efficient as it can be. I'd be willing to bet my net worth your users don't
care at all how you built it, just that it does what they want it to do.

In the end, for most companies, it's more about shipping product that sells
than spending 5x more time writing it in C# because "you're an engineer so you
should act like an engineer." That's not how the world works. And until you
figure that out, you'll constantly be left behind by others who made
compromises to capitalize on the market.

Early optimization is the root of all evil.

~~~
StavrosK
> I'd be willing to bet my net worth your users don't care at all how you
> built it, just that it does what they want it to do.

That's exactly right, except "what I want it to do" is not use up all my RAM.

~~~
traviswingo
Yeah...I could do without the RAM munchers.

------
qwertyuiop924
_sigh_

First off, JS is a perfectly usable language. In some respects, it's even
great: of the "big three" scripting languages (Python/Ruby/JS), it's the only
one that got Lambdas right, and also got closures right (unlike, say, Python).
It has sometimes-quirky syntax, and some odd semantics, but they don't bite as
often as you'd think.

Second off, I would say that this article is right about the bulk of Electron:
It's a pretty massive thing to lug around with your app, and not ideal in any
sense. However, if you want to build a UI very fast, there is _nothing_ better
than HTML/CSS for it. Except maybe TK.

Speaking of TK, I would actually advocate TK over Electron: it's easy to use,
has bindings to pretty much every language out there, and with TTK, it doesn't
look like crap.

Finally, "considered harmful" essays rarely do any good, and frequently do
harm.

So yes, while I usually like Drew's writing (at least a little: he's good, but
far from the best), I wish he had spent the time he spent writing this doing
more work on SCAS.

Seriously. If SCAS was actually done, and documented, and usable, that would
be great. There is a freaking vacuum of good assemblers for the platform:
another one would be nice.

~~~
Roboprog
Hello again, qwerty'. Thanks for stepping up on the JS issue :-)

There are many good languages out there, "when used as directed". Alas, out
here in the flyover country of Sacramento, there is really only demand for 3
kinds of jobs: Java, C#.NET (falling off), and some Javascript, ignoring the
long tail of one-of-a-kind shops. Given those choices, I'll take the
Javascript. Java 8 lambdas are clumsy to use to assemble much in the way of
higher order functions.

I mean, cuz, who doesn't want to put _this_ as a parameter into a
function/method header:

(..., BiFunction<Map<String,Object>,Map<String,Object>,Map<String,Object>>,
...)

E.g. - for the sake of argument, say I needed a callback to merge two
associative arrays. Oh, you needed a third input argument? Write your own
interface type, so you can use it to declare the callback parameter.

No, I'll take the JS, thank you very much.

(as we discussed a month or two ago, Java is a [somewhat] new Business
Oriented Language, and it's pretty Common)

~~~
SlySherZ
I couldn't agree more with this. Just the fact that functions are a first
class type in JS already makes it better than many other languages.

Another thing that JS is great at is the flexibility it provides: objects are
very general and you can do almost anything with them.

Anyone would care to explain why does JS take so much hate?

~~~
quicknir
[http://softwareengineering.stackexchange.com/questions/22161...](http://softwareengineering.stackexchange.com/questions/221615/why-
do-dynamic-languages-make-it-more-difficult-to-maintain-large-codebases)

The answer doesn't really end up being static vs dynamic, but rather how
dynamic languages often lack the other facilities that make programming in the
large easier, and Eric Lippert uses js as an example.

Companies with a lot of money at stake have spent a lot of money and effort on
things that transpile to js. The people making these decisions are almost
always quite smart and very practical. They don't care if first class
functions are sexy. They just want to write high quality code quickly. If
they've spent so much time wrapping it up, you know it's because they had
serious issues being productive at scale with js. They, and people on their
team, probably got extremely frustrated along the way. Hence the hate.

~~~
qwertyuiop924
Sooo... people don't like JS because 1) it's dynamically typed, and 2) they
don't like JS?

>They don't care if first class functions are sexy.

It's not about being sexy (and believe me: first class functions aren't): it's
about getting a very useful feature right, something many languages seem to
have trouble with, despite the fact that Lisp (and ALGOL, IIRC) got it right
in the 50s.

~~~
quicknir
Sorry but this reply is just kind of vacuous given the link I posted. Eric
Lippert gives a pretty detailed, neutral, blow by blow summary of the issues
working with js at scale. And he quite specifically says that dynamic typing
is not intrinsically the problem, just that dynamic typing tends to be
correlated with other things that are a problem. He specifically mentions
things like error handling. Did you even read the link?

I think your attitude is more that nothing is really bad with js relative to
other languages, more so than actually trying to understand why it draws a lot
of criticism, which is what you claimed and what I tried to link to.

~~~
Roboprog
I read it. It assumes mutable OOP. Yes, "those people" need a safe place to
play so they don't hurt themselves :-)

(I'm ignoring the error handling thing, as I have not done enough server side
JS to have a good feel for how the Node API handles things like I/O failures)

IDEs are starting to have better support for Javascript (or similar
dynamic/functional languages). In the near future, the IDEs should effectively
have type inference. Once you relegate (mutable) OOP to a tool of last resort,
and embrace immutable value objects plus (higher order) functions as your
primary methodology, you get the automated error checking _and_ much less
drivel to read through during maintenance.

OTOH, I suppose this means the dynamic/FP languages will remain a productivity
lever for motivated "experts" only, sadly. At least until there is enough
butt-kicking in the market that Java (and its ilk) will be displaced as was
COBOL before it. COBOL was "safe" and fast, but we finally reached a tipping
point were it was too painfully obvious that it simply wasted too much time
writing and reading it.

------
mherrmann
I recently had to decide on a GUI technology for a file manager I'm developing
[1]. Electron is sexy, but unfortunately takes way too long to start for my
purposes. I ended up with PyQt:

Pros:

\+ Fast startup speed

\+ I can use Python (and its vast ecosystem)

\+ Qt has good ready-made components for eg. displaying a list of files (which
is exactly what I need)

Cons:

\- Compiling Qt (which I have to do for various reasons) takes time and is a
pain

\- Bundling and deploying a Qt-based app (times 3 - OS X, Windows, Linux) is a
pain

\- I have to deal with auto-updating myself (which I believe Electron supports
out of the box) - times 3.

\- I would prefer to lay out the UI in well-understood HTML/CSS. Qt's
components and its CSS-equivalent behave in very weird ways sometimes.

I still sometimes wish I could use Electron but as OP says, we're supposed to
pick the right tools.

I explain my reasoning for picking PyQt over Electron (and other alternatives)
in a blog post [2].

1: [https://fman.io](https://fman.io)

2: [https://fman.io/blog/picking-technologies-for-a-desktop-
app-...](https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/)

~~~
jeremiep
A file manager would not be a good use-case for Electron. Especially if you
don't intend to run it in the browser (which really would make no sense.)

For the very reason you outlined - startup times. The average use-cases of
file managers are being opened and closed very often. Electron is rather aimed
at long-running applications you don't usually restart, like Atom and VSCode.

Microsoft could've ported VS to other platforms, yet they chose Electron. I'm
sure they spend quite a while analyzing the requirements and looking at
alternatives as well before settling down.

The end result is very lightweight compared to VS and does almost everything
users require. VS still starts a lot slower than VSCode for one.

~~~
mherrmann
Maybe I'm an outlier, but I open/close my editors just as often as my file
manager.

The main benefit of Electron is the community. Everybody knows
HTML/CSS/JavaScript, so can write extensions / customisations. If I were
Microsoft, that's how I would have justified Electron.

Still, I personally much prefer Sublime Text :-D

~~~
jeremiep
My Spacemacs session often grows weeks old :)

Emacs also has a client/server architecture so I can spawn the emacs daemon
and then connect to it from anywhere.

We have a few people in VSCode at work, a few in Sublime and yet more in Atom.
They're all very happy with their setup :)

------
seanwilson
> For the love of God, learn something else. Learn how to use GTK or Qt. Maybe
> Xwt is more up your alley. How about GNOME’s Vala thing? Learn another
> programming language. Learn Python or C/C++ or C#.

All of this takes time. If you want to launch an app on multiple platforms,
Electron is a very time efficient way to do this. Obviously native apps for
every platform would be ideal but not everyone has the resources for that.

> Let me be clear about this: JavaScript sucks. It’s not the worst, but it’s
> also not by any means good. ES6 is a really great step forward and I’m
> thrilled about how much easier it’s going to be to write JavaScript, but
> it’s still JavaScript underneath the syntactic sugar.

Use something like Typescript or Flow then. The above is like saying C++ sucks
because assembly is a bad language to code in.

------
bmpafa
This article, like many similar to it, makes the (imo flawed) assumption that
a dev tool ought to be evaluated on only a few variables--e.g., code quality,
performance, package size.

If writing software is about making users' lives easier, happier, or better,
though, I think we ought to optimize for that and that alone.

I say let the market and communities of users decide which software they want
to use. I use Nylas b/c I like the UX better than Ubuntu's Evolution, despite
its flaws. I use Caret (electron markdown editor) because I wanted a cross-
platform tool and I have > 4 gigs of ram. Hell, millions still use the
Facebook Android app, despite the fact that it sucks down battery juice like
your crazy uncle sucks down Miller Genuine Drafts before lecturing you on how
terrible millennials are (happy Thanksgiving, btw).

Of course, it's important we know the trade-offs of the decisions we make, so
we need critical pieces like this. But to be as prescriptive as this article
is to miss the forest for the trees. Love it or not, JS is a point of entry
for a hell of a lot more ppl than C++ is, so expanding its reach into new
arenas is not only net-good, but I'd argue also inevitable.

That said, the article does skirt an issue I've thought about a little, and
I'm interested to hear others' takes. If software collectively moves more
towards higher-end systems, e.g., with SPAs and electron apps and all their
cpu-intensive renders, are we further limiting a great web UX to those with
the money to afford the latest laptops? We spend a lot of time thinking about
accessibility standards for our products (A11Y, etc.), but when should we
begin to think about accessibility from a socioeconomic perspective? Or are
performant computers now so accessible that we needn't worry?

~~~
rootlocus
> If writing software is about making users' lives easier, happier, or better,
> though, I think we ought to optimize for that and that alone.

That's (imo) your flawed assumption. And no, just choosing electron won't make
your users happier.

> Love it or not, JS is a point of entry for a hell of a lot more ppl than C++
> is

C++ is not the only alternative. And considering the staggering amount of
frameworks and tools one must learn to get started with JS other alternatives
are actually easier. Unfortunately, not as cool.

> That said, the article does skirt an issue I've thought about a little, and
> I'm interested to hear others' takes.

Is this a joke? I had to google what skirt means: "attempt to ignore; avoid
dealing with." That's the exact opposite of what the article does. Let me
quote it for you:

About electron: "One of the slowest, least memory efficient [...]"

About terminal: "They’ve taken one of the most lightweight and essential tools
on your computer and bloated it by orders of magnitude. "

About lossless-cut: "For the price of 200 extra MiB of disk space and an
entire Chromium process in RAM and on your CPU [..]"

The conclusion that "people will require more money to buy more hardware to
run bloated software" is not something only you thought about, it's only one
step away from what the article says. And it's actually hilarious (read:
infuriating) that you don't see the problem with that way of thinking. NASA
put people on the moon with computers less powerful than a mobile phone.

The article criticizes people who write bloated software, but you argue it's
fine, because users are happy. Then you go on wondering if it's a problem that
users won't afford the latest laptops to run bloated software. WAT?

~~~
bmpafa
> just choosing electron won't make your users happier.

Ah thanks, I lost some clarity in a post-write edit. My point wasn't that
choosing electron would do that, it was that we should look more at end-user
satisfaction and less at often pedantic technical analyses of solutions.

Re: C++: You may be right, but we can't deny that popularity and cool factor
has a significant effect on hard metrics--eg, more frameworks, more libs, more
components == faster dev speed & iterations, which I think is a good thing.
ex: Mac hasn't been "better for graphics" in over a decade, but the 'cool
factor' has made it the de facto choice for designers, which has resulted in a
bulk of the latest designer tools being Mac only (a problem which,
coincidentally, electron & its ilk aim to solve).

Last: no, it wasn't a joke. I know what the article said. My point was that
the point of socioeconomic accessibility was mentioned, as you note, in the
last line, but for the most part, the supporting data were more asserted as
intrinsically bad. If it was a key argument of the author's, I think the data
would've been tied coherently to the conclusion instead of requiring a
diligent reader such as yourself to farm & cobble them together into a
patchwork argument.

So, if you'll forgive me for borrowing a little of your snark: next time you
google a word, for instance, 'skirt', you should probably prefer the first
definition ("go around, past the edge of") instead of the fourth definition,
as you've done here.

To be clear, my thesis is, in tl;dr form: "Anything that makes reaching users
in the environments they prefer easier is probably good, but the extent to
which this trades off with accessibility is unclear to me."

~~~
rootlocus
> you should probably prefer the first definition ("go around, past the edge
> of") instead of the fourth definition, as you've done here.

That was the third definition. The first definition was "a woman's outer
garment fastened around the waist and hanging down around the legs." /snark

> we should look more at end-user satisfaction and less at often pedantic
> technical analyses of solutions.

They aren't orthogonal. User satisfaction comes from a smooth experience.
Regardless of how shiny something is, if it slows down the rest of the system
(or is itself laggy) users will notice. I choose to run foobar instead of
other music players because it's small and fast.

> are we further limiting a great web UX to those with the money to afford the
> latest laptops?

This is what infuriates me. People have been talking about how the "free
lunch" is over [1] since 2009. About how CPUs have stopped getting faster, and
how we should make the best out of the current hardware by learning to
paralelize. Yet javascript is the most popular language and it's fundamentally
single threaded. High quality software is not about having "a great web UX".
VLC doesn't have it (great web UX). Blender doesn't have it. Intellij IDEA
doesn't have it. And they're not only extremely complex and efficient
softwares, they also have great UIs. Our computers are extremly powerful. The
fact that someone would wonder if they're not enough to run pretty clipboard
managers and fancy text editors is making me cringe.

[1] [http://www.gotw.ca/publications/concurrency-
ddj.htm](http://www.gotw.ca/publications/concurrency-ddj.htm)

------
vvanders
As some of who's had to support Qt, wxWidgets and other crazy x-platform UIs I
find electron refreshing.

Heck, I've got Rust talking to node.js in it. Elm for the front-end and Rust
for the processing, it's a surprisingly pleasant development experience.

~~~
nmca
Hey, is this open source? Sounds very cool. If not, can you point me towards
any open source apps that are using a similar approach?

~~~
vvanders
Not yet but it will be once it's a little further along.

Rust -> Node -> Rust is pretty simple, just expose a c api and wrap it with
node-ffi. Then I have the main thread piping messages over to the relevant
windows straight into Elm ports.

Nice bit is you can pass callbacks into Rust that calls js via c function
pointers. Saves a ton of time marshaling data and is more efficient.

------
lopatin
This guy is doing his best to make sure we can't have nice things.

> We use [JS] because we have no choice (people who know more than just
> JavaScript know this). The object model is whack and the loose typing is
> whack and the DOM is super whack.

Moot point. I use React + TypeScript. Good types and barely ever work with the
DOM. If you don't like TypeScript, your favorite programming language probably
compiles to JS anyways.

> The reason people choose Electron is because they are too lazy to learn the
> right tools for the job. This is the worst quality a developer can have.

I agree that bundling a copy of chromium for a todo list app or clipboard
manager seems wasteful. But that's an edge case, most people build actual
applications. If I'm building a non trivial cross platform app, I'll be orders
of magnitude faster on the web stack. I'm not lazy, I just don't want to waste
months of my time learning arcane APIs because anything else wouldn't line up
with the author's point of view about what the "right" tool is.

------
stevebmark
"If you want to make a quick little app, instead of using something convenient
that you know, you should learn a REAL language like C"

Why is this garbage on the front page? Stop giving condescending people like
this a platform.

------
nailer
> For the price of 200 extra MiB of disk space and an entire Chromium process
> in RAM and on your CPU, you get a less capable GUI that saves you from
> having to type the -ss and -t flags yourself.

Cool. I remember when Handbrake first came out, and 'make video go on iPod'
went from some long winder research into ffmpeg flags to clicking a button
that says 'output for iPod' [1]. This sounds similarly timesaving.

[1]. yes, iPod. Showing my age.

~~~
q3k
>[1]. yes, iPod. Showing my age.

That was, what, 9 years ago? I realize it's an eternity in the average JS
framework lifecycle timeframe, but come on.

------
K0nserv
I think the points raised are solid, but at this point it seems like Electron
is the best worst solution for cross platform UI. Having worked with Qt I
never wanna do that again. There's also a much more significant portion of
developers who can work on Electron based apps. Part of picking the best tool
for the job involves considering maintainability and ease of development after
all.

~~~
witty_username
What are your problems with Qt?

I was using PyQt, and I found it nice (Qt's integration is good).

~~~
freeone3000
C++ Qt, I've found, is an entire separate beast.

It goes out of its way to not rely on the STL, so that std::string and QString
are separate, non-convertible classes. QList and std::list<> are the same,
same for QMap and so on and so forth. So data communication is already a pain.

We then have further issues with function invocation. Slots and sockets are
simple with python, because functions are first-class in python. In C++, they
are very much not, so slot-socket binding looks like: connect(sender, SIGNAL
(valueChanged(QString,QString)), receiver, SLOT (updateValue(QString)) );

This is less than ideal.

~~~
pjmlp
When having to deal with compilers that barely support a mix of C++98 and
C++03, Qt is quite good.

STL wasn't always here and still isn't in some embedded platforms.

------
jules
This article makes a good point, but what's the alternative? There is no good
cross-platform GUI solution. Qt, GTK, JavaFx, wxWidgets, none of them are very
good. Electron at least has the advantage of being fully cross-platform and
not having to learn a whole new universe if you're already familiar with the
web.

~~~
lambda
For cross-platform apps, Qt is the best I've used. But it does have its warts,
and it is big, it will probably bloat your app by about as much as Electron
does.

But yeah, there's no one clear winner, which means that Electron is not a
uniquely bad choice. Sure, it might be a little heavyweight for a really small
simple app, and if you're not aiming for something cross platform your native
widget toolkit might be a better idea.

------
sergiotapia
I look at Electron apps the same way I used to look at Adobe Air apps. Any
League of Legends player knows how bad the launcher is - 80% the fault of
Adobe Air.

Sure it was easier to build, but your users suffer for it. Electron apps are
pretty terrible performance wise, and you can immediately tell it's an
Electron app.

\- Atom

\- Slack

\- GitKraken

All of these apps have 'tells'.

~~~
oldsj
Yea but look at VSCode, definitely an exception to this. The feel of code vs
atom is night and day to me.

~~~
sergiotapia
Props where it's due! VSCode definitely feels native.

~~~
DonHopkins
VSCode certainly proves that Electron is capable of going the distance to
making an app that feels like native. And it's a great example to read the
source and learn how to do that for your own app. It's just a simple matter of
programming. ;)

------
evilnode
I've been fighting with this for a while now. I think the only good reason to
use something like Electron is if you need to get a cross-platform POC up and
running quickly.

I am currently trying to make a GUI to compose and render Terraform assets in
a similar manner to AWS CloudFormation's visual designer, and I've spent an
eternity trying to devise the best way to do this (this is mainly driven out
of boredom more than anything else...Terraform works just fine as is). As much
as I don't want to use Javascript and the cancer that is it's dependency
management, the web stack is proving to be the path of least resistance thus
far. Although I still don't understand why you need to download half of the
known internet to install gulp and babel locally.

I'm a GUI novice. Is there any cross-platform software that generates a true
native UI on target platforms?

~~~
rootlocus
> I'm a GUI novice. Is there any cross-platform software that generates a true
> native UI on target platforms?

wxWidgets does

------
burai
Well, that was a waste of time, the article is more a rant than anything else.
I can understand that some piece of technology will not like everybody, but
not spending any time giving proper alternatives. Not to mention that the
header seems click bait since it's an opinion article, not an actual security
risk.

------
theSoenke
The problem is there is no really alternative. Or what alternatives exist to
write good looking, cross platform desktop applications with reasonable
effort? I don't think there really is one. Another think is the huge amount of
dependencies typical electron apps have (or in general node applications).
500-1000 packages is not unusual. Thats ridiculous for a simple desktop
application

------
mixedbit
The argument that the only advantage of Electron is cross platform portability
is not true. Electron tries to duplicate what is already a main stream
approach for deploying backend services. The only reliable and sane way do
have a stable backend is to explicitly control and isolate all dependencies of
the backend services by using virtual environments, Docker or virtual
machines. Most people no longer think that it is a good idea to run multiple
services on the same server, globally 'pip|npm|bundle install' packages that
one of these services needs and hope for the best.

Electron tries to do just that on the desktop. It packages all the
dependencies that the application needs together with the application and
installs them in an isolated app folder (not affecting any other app). It
enables easy automatic updates of the whole environment without worrying that
the update will break other apps or will not work because some user happens
not to have some system library.

Sure, this is much earlier stage than with backend services. Ideally Electron
could ensure that identical dependencies that are shared between different
apps are not installed multiple times, the way Docker does it. Even without
such sharing I think that benefits of the Electron approach justify additional
MBs on disk.

~~~
mwcampbell
We've been doing self-contained app distributions, with all third-party
dependencies bundled, for well over a decade, especially on Windows. But
Electron does make it quite easy to package an app that way.

------
cdnsteve
If electron apps had a smarter way to manage chrome core as a dependency, the
file size would be peanuts. Every apps is download on the same bundled core.
Once this happens you won't have 100mb sizes. An intelligent installer could
check core, if not installed download and install otherwise use what's on the
system.

~~~
Longhanks
What if there was a centralized way of accessing HTML + CSS + JS applications?
Instead of installing apps, you could just... "download" the necessary files
to execute them? Perhaps even on demand from centralized.. "servers"?

~~~
detaro
I really don't want APIs to freely access the filesystem, other processes etc
in my browser. And my applications to work offline.

I haven't seen many examples of people using Electron to make applications
that really should be web apps instead, but more for packaging web apps with
native enhancements. Often I'd prefer a "proper" native app, pushing even more
features in the browser IHMO is not the answer.

~~~
tscs37
>I really don't want APIs to freely access the filesystem, other processes etc
in my browser. And my applications to work offline.

Ctrl+S -> Save whole webpage

alternatively get the Webpages source code.

------
NelsonMinar
Stupid essay is stupid, but I'm glad it pointed me to lossless-cut because
that tool is great! The author completely misses the point of Chromium in
berating lossless-cut for being "a graphical UI for two ffmpeg flags". Yes,
exactly, it's a GUI that lets you cut video to the precise frame you want to.
That exactly solves a problem I've had for a long time; I've been using a
horrible ffmpeg command line alias (along with preview in VLC) for a year now.
He's a little right about "It doesn’t even use ffmpeg to decode the video
preview in the app"; that would be useful for supporting weird formats that
Chromium doesn't. But for common formats lossless-cut is great. It's at
[https://github.com/mifi/lossless-cut](https://github.com/mifi/lossless-cut)

------
striking
See, I totally agree with this essay.

But what are the alternatives? Getting started with Qt/GTK isn't nearly as
easy, for example.

Maybe someone should write an intro to native GUI programming for JS devs.

~~~
ld00d
What's wrong with JavaFX? I don't ever see it recommended, but a lot of us can
do Java, and from my experience, it's way better than swing or awt.

~~~
antihero
Purely out of interest, because I might have used one without even realising
it, but could you link some desktop applications written in Java that haven't
been sluggish as hell or a bit broken feeling?

~~~
pkd
JEdit? Any IDE by IntelliJ? These are not JavaFX (its fairly new), but you
asked for Java.

~~~
antihero
IntelliJ is a good IDE, but it's UI is far from not-sluggish.

------
jmlucjav
I have been wondering...does Slack freeze for like a couple of minutes a
couple of days a day for someone else?

I am on win10, on pretty hefty machines. No idea if it's because Electron or
something else, but it's really annoying. I could not find any trace of issues
in the event viewer etc.

------
jasonthevillain
Calling people lazy should also be considered harmful. Please stop doing this.

Time is finite, and not all of it should be spent programming.

------
dexwiz
Electron, and to a great extent the cross platform fetish, is a perversion of
DRY. They don't want to write the same code for two platforms. But its usually
not the same code. Its the same logic implemented on two different platforms.
Developers are so into code sharing, write once run everywhere, that they
don't stop and ask if they should. In every case you are paying a price for
abstraction, like running Electron or using a WebGL canvas instead of a native
graphics API. The article highlights cases where they price was paid, but the
app was still platform specific.

~~~
TeMPOraL
Well, it's the same logic - so almost _by definition_ it should be platform-
independent. People are too lazy to introduce proper abstraction between what
the application does and what it shows on screen, and suddenly porting is
hell.

Either way, Electron sucks because it ships a whole goddamn browser to give
you _just_ portability; you have to still pile on a ton of JS and CSS hacks to
get a decent-looking SPA UI out of it, which you'd get for free with any
proper GUI runtime. All that waste because people want to write JavaScript
(which I understand - I have my favourite language I'd love to write more too)
and this was _the most brute-force way to allow it_.

Embed a system webview if you must, don't ship the goddamn browser!

------
heisenbit
The fact that electron is easy enough to write trivial apps while at the same
time powerful enough to give us VS Code is in my book SPLENDID.

If the trival app is too big for a trival app - who cares. The fact is there
is now a serious contender in the cross-platform space that so far has been
mainly occupied by Java. Java cross-platform is neither easy nor lightweight.
And from what I have seen so far getting started with Electron looks a lot
easier.

------
bhouston
There are a lot of shitty half working apps, and there always will be.

------
jeremiep
I can't help but feel as if the author can't make the distinction between a
platform and the software written for it. People have been misusing platforms
ever since they existed. Its not because someone used Electron to build a
console that Electron is bad in and of itself, it just means someone used the
wrong tool for that specific job - or maybe that fitted all their requirements
in which cause the author is just dismissing the work with no clue about its
context.

I also can't help but feel as if the author is a beginner developer lacking a
huge amount of context and experience. Saying "Electron enables lazy
developers to write garbage" displays a huge misconception about software
development in the very first place - garbage will be written no matter the
language or platform.

Alls the article did was remind me that those who can, do, and those who
can't, blog.

~~~
nycatelos
And those who really can't post snarky comments on HN.

------
api
The only viable alternative is Qt, and it is almost as big and offers a less
familiar programming model.

Native is only an option if you want to rebuild your app UI from scratch a
minimum of twice and never support Linux or other less common desktops.

UI development has always been in fragmentation hell.

------
baby
Yeah no. Electron is fine to write desktop apps.

I've seen native app with more ugly UIs and being laggy, etc... For many apps
Electron is fine and will perform as well, or even better than native apps
(just because, developers you know).

------
IshKebab
Honestly I think this is a symptom of the lack of really good GUI toolkits
that let you define the UI in an easy-to-use and powerful language. There's Qt
& QML, but that's about it, and to be honest QML is still pretty immature (try
doing a custom control with text, or any kind of text editor in QML).

I really hope Rust or Go get great native GUI toolkits soon with nice
declarative layout languages, but until that happens it is hard to get too
angry at people using the wrong tool for the job because the right tools just
aren't that great.

------
roryisok
I have a windows store js/html app which I plan to re-release on electron. It
features a rich text editor and a few other features. I want to release on
Linux and mac os. Should I go away and learn qt/gtk/wx? Restart the whole
project in Java?

The idea that I might choose electron for ease/speed of development rather
than use a leaner platform is being shit all over as a "business" decision.
Not a "I don't have enough free time to learn two new languages and ui systems
code three new apps" decision.

------
adamnemecek
I dislike JS just as much as the next guy but the only real contender on the
list is Qt. Which you need to license for commercial development. Furthermore,
even though I like to think that I'm ok in C++, I would really think twice
before using it on my next project these days.

The JS performance issues should go away for the most part when wasm is
standard. Also a lot of people write some compile to JS language, not JS, so I
think that most of the points of this blog will be rendered moot in the near
future.

~~~
falcolas
If you're doing commercial development, why is a license (and the attendant
support) a big deal? Its cost in relation to that of your developers is
neglegable.

Or is the cost of the license really that prohibitive for a well supported and
performant piece of software?

[EDIT]: I found the pricing after a bit of creative googling: Startups is
about $1,000 a year, non-startups are about $3,500 a year. Even without the
discount, that's roughly equivalent to a month of one developer's time. IMO,
not a terrible deal, for something you can freely license and use for cross
platform development.

------
agounaris
We need to stop reading such posts. "Everything sucks because I say so".
Technology is really fair. At the end we WILL use what matters the most and
has the overall best tradeoffs. I don't like it when people use the expression
"best tool for the job". Like you used every other available tool out there
and you found the best one...no you haven't.

------
vorotato
Considered Harmful essays considered harmful.

[https://news.ycombinator.com/item?id=9744916](https://news.ycombinator.com/item?id=9744916)

------
danblick
For me the title evokes "Considered harmful essays considered harmful", which
suggests that perhaps "benefits and disadvantages of Electron" would have been
a better essay.

[http://meyerweb.com/eric/comment/chech.html](http://meyerweb.com/eric/comment/chech.html)

------
calebm
Just because a particular technology is not the "right" tool for every job
doesn't make it harmful...

------
rpeden
I'm a bit late to the party, but there are active React Native ports for both
OSX and Windows.

Using them could be a good solution for targeting OSX and Windows and reusing
logic from your web React app without having to deal with the overhead of
Electron.

------
mikewhy
Another example of "'____ considered harmful' considered harmful".

~~~
pluma
Eric Meyer put it best, I think. Time for a repost:
[https://news.ycombinator.com/item?id=13031883](https://news.ycombinator.com/item?id=13031883)

------
butz
Web browsers should have integrated functionality to run some websites as
standalone apps (anyone remember Prism?). That way we wouldn't need to install
yet another copy of browser with each app.

------
k__
OT: what's the difference between Electron and Electrode?

~~~
Shengbo
Electron is a cross-platform desktop framework based on a web stack.

[http://electron.atom.io/](http://electron.atom.io/)

~~~
k__
How does it compare to [https://github.com/electrode-
io](https://github.com/electrode-io)

~~~
detaro
Electrode seems to be for "normal" web sites/web apps, Electron is for
packaging HTML+JS as desktop apps.

~~~
k__
Okay, thanks.

------
yoavm
While I agree with his general idea that Electron is usually not the best tool
for the job, I think he's overestimating JS as the reason that people choose
Electron. It's not because of JS, it's because of HTML and CSS, which aren't
that bad comparing to other tools we have (especially since Flexbox). I think
most people would love to write desktop apps using HTML and CSS, while using
anything other than JS to do the logic. We're just... not there yet.

------
always_good
SirCmpwn, you'll understand more about trade-offs when you finally have
commercial success with one of your projects.

It's too easy to lambast Electron and "lazy developers" when you've never had
business concerns trump technical ones because none of your work ever tried to
run that gauntlet.

I had to chuckle to myself when I saw that your GitHub bio is:

    
    
        > I make unoriginal projects with better code than 
        > the thing they rip off. I'm available for hire.

------
baybal2
what is electron?

~~~
witty_username
Downvoted; this question can easily be answered via a search engine.

~~~
FullMtlAlcoholc
Downvoted. It's generally considered rude to expend more effort being snarky
than answering a simple question.

To the parent: Electron is a framework for building cross-platform desktop
apps with HTML CSS and JavaScript in an embedded chrome browsers/node.js
environment.

More info here: [http://electron.atom.io](http://electron.atom.io)

~~~
witty_username
How would I say my message without being snarky?

~~~
FullMtlAlcoholc
If all I can add to a discussion is "Just google it", I just won't respond.
For better or for worse, people aren't going to respond by saying 'By golly,
you're right! I'm so lazy, but from now on, I will google stuff first instead
of asking questions." They're just going to say basically "What an asshole,
fuck this guy.

Maybe he wants an answer that is curated and summarized by a human, not a
litany of links where you don't know what to focus on. For example, when I
asked what dependency injection is, some kind stranger responded "It's a
million dollar term for a 5 cent concept. Pass objects as arguments to
functions instead of instantiating them inside." Of course, this is a limited
definition, but it was put into layman's terms and it answered my question.
From that answer, I was able to really learn what it was instead of being
stuck on phase 1 of understanding.

When you're online, it's much easier to come off as a dick than it is in
person so what I try to do is imagine someone coming up to me earnestly and
genuinely asking the same question and respond thusly. Accordingly, when I
know I'm asking a simple question, I add self-deprecation to the beginning.
Example: "I have the technical and programming acumen of a bag of rocks, so
excuse my elementary question, but..."

