
Ask HN: Why / Why Not Use Electron? - mc42
More and more apps that I&#x27;ve seen published here are heavily disliked for their usage of Electron.  What experiences have you had with Electron and why &#x2F; why isn&#x27;t it a good idea to write an application with it?
======
eivarv
_Why not:_

In my experience, Electron apps tend to be bloated, not very performant and/or
energy inefficient. This means that developers make a choice regarding users'
disk space, user experience and battery life. The extent to which users notice
any of this is of course dependent on a combination of their machine (e.g.
old/new hardware, laptop/desktop) and the application being run.

Also, since you don't use the platform's native widgets, there's poor (or
nonexistent?) accessibility features for users with special needs - not to
mention the implications (HCI-wise) of redefining/replacing standard interface
elements.

In my opinion, all this reeks of poor design, and is arguably (in some cases)
downright user-hostile and unethical.

To portray it as "native" is, frankly, ridiculous.

 _Why:_

The main thing Electron does well is lower the barrier to entry and maybe
increase development speed.

I can definitely see use cases, such as quick prototypes and internal
applications. And it is cross-platform. There's probably other good reasons to
use it as well.

------
bengineer
I personally love it. I've only written a couple of small, really simple apps,
but I've got a couple more under way. To me, the idea of writing desktop,
native apps, utilizing the web development technologies I already know, is bad
ASS. the sizes are on the high side for some things, sure, but that's not
really a HUGE deal breaker for me.

~~~
nbertram
I agree, our users don't care about a 50mb download - they love the native
feel of our app.

------
smt88
I dislike Electron apps that I use because they're incredibly bloated. I don't
know if that's always a guarantee with Electron.

I've seen people criticize Electron for being slow/unresponsive, but VS Code
is incredibly fast and responsive, so I know for a fact that Electron usage
doesn't guarantee slowness.

~~~
magefile
Performance surely depends on many factors. In my experience, VS Code for big
Unity C# projects on OS X slows down a lot soon after launching the editor,
and all the OmniSharp/IntelliSense things become unusable. Even in that case,
the editor UI itself remains very responsive, so maybe it's the omnisharp
implementation to blame, since it can take 15-20s for simple code completion
to show up. The latest VS Code updates have tried to address some of the
performance issues, but still have not solved all of them. What's more, one of
its recent issues was 'Electron Helper' process hogging nearly 100% CPU usage,
which might have given the idea that Electron is the culprit.

------
Hamcha
Bigger drawback is that it's bloaty, I have a mix of Chrome apps and Electron
apps, the Electron are big (40+ MB) and take much longer to start because they
have their own Chrome to open, while the Chrome apps just use the global
Chrome instance that's already open.

I wonder if we'll someday get something akin to the JVM for Chromium-based
stuff. We'd finally have a single install that could be updated and every app
being kilobytes instead of megabytes.

~~~
romanovcode
Well but what about those people who do not even have Chrome installed and are
not even planning to use Chrome for privacy reasons?

~~~
Hamcha
I'm not saying "just install Chrome", that wouldn't solve the problem. I'm
saying it'd be nice just have a Chromium install that's used by the other
apps. If you use anything based on Electron you're using Chromium anyway.

It's not about installing an additional browser, it's about unififying all the
Chromium installs in a single package. Imagine how nice would it be if every
Java app had its own copy of the JVM: They would be incredibly bulky and near
impossible to update (considering the sort of vulnerabilities that the JVM
gets, it would be a disaster). It's a scenario for JVM, it's a reality for
Electron.

------
david90
Pro Simple to build, cross-platform - even linux supported.

Con The default electron build is quite large, typically >50mb for a single
page app.

------
babyrainbow
Something I have always wondered.

The first version of firefox was 5 mb and chrome was 9 mb or so. Can't we
bundle such a light version of the browser, instead of always bundling the
latest and greatest? Shouldn't it be enough to render the gui's of native
apps?

------
aeharding
[https://youmightnotneedelectron.com/](https://youmightnotneedelectron.com/)

------
supernintendo
Pros:

\- Productivity: The browser renderer and Node (as well as the open source
ecosystems that accompany those environments) offer you a lot. HTML, CSS and
JS are relatively easy and because there are a lot of web programmers out
there, your access to developers, developer resources and libraries is vast.

\- One portable target: Develop your app for multiple operating systems
without worrying about many of the problems inherent in web programming (ES6
support, CSS inconsistencies between browsers, etc.) or cross platform
development (compilation, dynamic linking, header / include guards, etc.)

\- Decent OS integration: Interacting with filesystem, native OS menu bars,
notifications, etc. is fairly simple.

\- Multiple language support: Electron uses JavaScript for application logic
but you could alternatively use CoffeeScript, TypeScript, ClojureScript, Elm
or any language that can compile to JS.

\- Performance when you need it: Use something like node-ffi [1] or SWIG [2]
if you need C or C++.

Cons:

\- Memory usage: An Electron app is essentially a fully-featured Chromium
browser and a Node process that communicate via IPC. This might be a bit
bloated for some applications, particularly if you're targeting systems where
memory is limited.

\- Large builds: Packaged Electron apps contain everything they need to run so
they're typically quite large. Don't be surprised if your "hello world" app
ends up being over 30MB.

\- Not truly native: Sure, you can make your app look great but the only way
you can make it look 100% "native" is to use the widget toolkits of whatever
operating systems you're targeting. Electron does not give you access to this.

\- The DOM can be your worst enemy: This is where the performance issues of
many Electron apps (Atom comes to mind) arise. Depending on the complexity of
your app, you'll want to either limit how many elements you render to the page
at any given moment or look into using something like HTML5 canvas to render.

\- Single threaded: Node is single threaded. If true concurrency is important
to you, you might consider another platform.

Overall, I love Electron. It's not the right choice for all applications but
if you have experience developing for the web and want a desktop application
platform that is easy to get into, I'd give it a shot.

[1] [https://github.com/node-ffi/node-ffi](https://github.com/node-ffi/node-
ffi)

[2] [http://www.swig.org/](http://www.swig.org/)

------
nameless912
Being totally honest, I have _very_ little experience when it comes to
designing desktop apps. Most of my experience in UI development has been in
either Swing (ew) or Qt/C++ (slightly less ew, but still ew).

I kind of hate the idea of Electron, and this is for a variety of reasons:

* I think Javascript is a terrible language. * I think HTML/CSS is a terrible language. * I think the web is too bloated as it is, and extending that paradigm to the desktop only encourages more lazy, bloated development.

That being said, I get the appeal Electron has for a lot of people. If you
already know web development, then writing a desktop app becomes a no brainer.
If you're already a destkop UI guy, you can learn Electron and be a web front
end guy too. All good things.

But the idea of using a fucking _gigantic_ framework (I mean think about it,
just Electron by itself is _all of Chromium_ basically, or at least the big
complicated exciting bits) is a massive code smell to me. It's like using an
ORM or a heavyweight web framework: whenever you're leaning on that much code
just for your baseline of functionality, you're making a lot of assumptions
that should, as a developer, at least give you pause. One of the things I love
about Swing is that I can spin up a basic prototype in a couple hours with
just a couple hundred lines of <insert non-java JVM language here>. And
besides the built-in language UI framework, I own every piece of that code and
can tell you what it all does. I feel like web development (an by extension,
Electron) doesn't have any of those desirable attributes.

Web development often involves hundreds of lines of boilerplate, the import of
a several-thousand line Javascript API, a heavy CSS framework like bootstrap
(for prototyping, at least), and the assumption that the magic will all just
work. I know that fundamentally there isn't that much difference between
writing an app in Swing versus Electron if we're talking about complexity, nor
is there that much difference in performance for simple cases. But it just
_feels_ better for me if all I'm doing is a few API calls (even if the
underlying code is similarly complex).

Now, there is one exception to all of this: one of the apps someone on my team
supports at work is our monitoring dashboard/customer service portal. Because
of some bizzar-o rule from up top, we aren't allowed installing anything
except for absolutely essential apps on the support machines. Electron proved
to be a lifesaver here because we could wrap our web-based portals in
"desktop-y" apps and get rid of the web browser entirely. For cases like that
(or like a friend of mine, who is currently working on medical instrument
displays and uses JS/Electron in a couple of experimental projects because
it's easier than Qt and the machines run Linux or Windows 7 anyway) where
really what you need is a website, wrapped in a clean sandboxed container, I
can kind of understand its niche.

~~~
niftich
> we could wrap our web-based portals in "desktop-y" apps and get rid of the
> web browser entirely

This is by far the most powerful 'feature' of Electron, to take a largely
already written webapp and insta-package it into a cross-platform desktop
application.

~~~
nameless912
I totally agree! Hence why I gave it special exception.

------
maxharris
Why not use React native? Putting a browser inside your mobile or desktop app
is always going to be bloated and slow compared to using JavaScript to drive
native views.

(Users might not notice that bloat and slowness if they're on a desktop system
with a fast CPU and lots of RAM, which is one reason why Electron seems okay
in certain cases.)

~~~
smt88
React Native is for mobile, whereas Electron is for desktop. They're not
substitutes for one another.

~~~
spdustin
Well, there _is_ react-native-desktop for macOS...

[https://github.com/ptmt/react-native-desktop](https://github.com/ptmt/react-
native-desktop)

But that's me being pedantic.

~~~
maxharris
react-native-desktop is what I was thinking of when I wrote my original post.
I think it's a matter of time before there's a Windows version.

~~~
freestockoption
Also available from Microsoft: [https://github.com/ReactWindows/react-native-
windows](https://github.com/ReactWindows/react-native-windows)

Seems to be only Windows 10 and xbox though.

