
Ask HN: Do you think Electron is good for building Desktop Apps? - david90
At Oursky, we built several apps with electron.<p>We find that it&#x27;s easy to set up, you can use npm packages. Yet the build size is quite big and it might not support all native features. What&#x27;s your thoughts?
======
pavlov
Regardless of whether the HTML+JS+CSS stack is good for desktop apps... The
one thing that bums me about Electron is that it bundles an entire web runtime
with each app, even though a suitable runtime _already exists_ as part of the
operating system.

Seriously, WebKit on Mac and Edge on Windows would be just fine for >99% of
Electron apps. Using the available web runtime would be a tremendous saving
both in build size and memory usage.

Did you know that Chromium contains 25.3 million lines of code? [1] Each
Electron app is bundling a separate copy of that enormous codebase in binary
form. It's a terrible waste of memory.

It's true that supporting the native web runtimes would be more work for the
Electron framework developers, and sometimes would also mean more work for app
developers... But most web apps have absolutely no good reason to be tied to
Chromium, so for app developers the diversity would actually be beneficial in
the long term IMO.

If someone wants to start a project that's like Electron but uses the native
runtimes, I'd actually like to contribute some work. Let's call it
"Electrino"?

[1]
[https://twitter.com/worrydream/status/857794605076500480](https://twitter.com/worrydream/status/857794605076500480)

~~~
awjr
Look at it from a product owner's perspective. I want 100% of users to have
the same experience. Electron bundling a web runtime that gives the same
experience on each platform is absolutely key to giving them the same
experience. There may also be security issues to consider.

~~~
pavlov
Look at it from the computer owner's perspective. I don't want your experience
if it comes with 100+ MB of redundant code.

~~~
hashkb
Isn't that size arbitrary? Downloading and storing a 100mb program takes the
same (or less) fraction of your available resources today as downloading and
storing a 1mb program in 1995.

Are you short on disk space? Download is too slow? Is this a real problem?

~~~
pavlov
Download size is relatively harmless; size on disk is an annoyance and a real
concern (a lot of laptop users have an SSD in the 128-256 GB range); but
memory footprint is the real killer for me. I don't want every little widget
to consume hundreds of megs of memory.

In 1995 my computer had 8 or 16 MB memory... Having a 1 MB app running in the
background would have been huge. I certainly don't want to go back to that
era.

~~~
hashkb
Wouldn't regular Chrome have the same issue? Each tab is a full instance...
your argument is against Chrome and web apps, not Electron.

~~~
pavlov
No, it's different.

Each Chrome tab is a process, but they share the same dynamic libraries in
memory. Each Electron app is both a process and a separate copy of the dynamic
libraries.

If you run half a dozen Electron apps, those redundant libraries will be
taking up roughly a gigabyte already.

------
interfixus
I am a retrograde, grumpy, obtuse old curmudgeon, so let me bite:

No, it is a terror. Applications produced with it are bloated monstrosities,
gobbling up hundreds of megabytes in both storage and RAM before getting round
to as much as putting a checkbox on screen. Bundling an entire web browser
inside your program in order to provide portable GUI functionality like what
Tk managed more than twenty years ago without breaking a sweat, and at roughly
1/100 the size, yeah, sure, it flies. So did the Spruce Goose, sort of.

But then, I never took to js, I never took to Chrome, I never took to bloat as
a way of life.

[edit: typo]

~~~
analognoise
I agree with you and take it a step further:

It is totally embarrassing that programs are 100-1000 times the size they used
to be, and slow. I think it shows an overall disinterest in our tooling and
field, and it's shameful.

~~~
codefined
Another thought, however, an application I wrote is 30MB when packaged. On an
average internet speed, this takes ~16 seconds for your average internet speed
(15mbps). Even on 1mbps, it only takes 4 minutes for the application.

When unpacked, it weighs about 100MB. This disk space costs roughly £0.004 for
an HDD or about £0.020 for an SSD.

In exchange for these extra costs, I get to use HTML, CSS and JS on both our
website and our desktop applications and they get to share the same codebase.
That alone must saves me 50% of the time. The fact people might have to spend
upto 3 more minutes to download my application and that it costs them 2p to
install it on their SSD is minimal compared to the fact that I can have twice
as many features in the same amount of time.

~~~
AstralStorm
Download is not the problem, the 10s start-up time is, as is those 100 MB RAM
usage, even worse if you hit swap.

Why use JS when you can have Lua for scripting and a less annoying programming
language for main code? Why use HTML and CSS when you can have a dynamic
portable native UI as in Qt?

I smell laziness and cutting costs in those decisions, or rather offloading
the costs onto users.

~~~
Prefinem
>Why use JS when you can have Lua for scripting

Have you tried NPM? If I want to write every single line of code for my
application, I don't expect it to ship (unless it's extremely simple). When
there is a library for almost everything, why not use one instead of trying to
reinvent the wheel?

~~~
flukus
Have you used anything other than javascript? NPM is not unique, half the
stuff it contains is also in the standard runtime of other frameworks.

~~~
codefined
I would thoroughly disagree with you that there is any other repository of
libraries nearly the size of NPM. Take a look at ModuleCounts[0] and you'll
see that NPM is growing 4x faster than the next sized repository (Maven) with
already over double the number of modules.

[0] [http://www.modulecounts.com/](http://www.modulecounts.com/)

~~~
flukus
Module counts aren't relevant. A good chunk of them are micro libraries (left
pad) that are already covered by anything with a standard lib, half of them
are abandoned crapware. I'll take 1 good library over 10 similar shitty ones
any day.

We also had libraries long before every language needed it's own package
manager.

------
mikhailt
Electron is acceptable for seeding the development of a new idea, product,
and/or platform.

However, as the team and product grow up, it becomes less acceptable as users
expect more performance by going more native and deeper integration with the
OSes.

Sorry but Electron is not the future for me. I dislike the memory consumption
it eats up. There is nothing acceptable about a simple chat app eating up 1GB
of memory when the identical IRC client I had was using 100KB and has more
features and the same client was built back a long time ago.

As for others talking about how there's plenty of disk storage and memory,
that's lazy. We're losing a generation of native coders to people who only
know about Javascript and never taking the step to learn more about how bare
metal works, effectively losing all the knowledge of optimizations, iterations
and programming skills we've learnt in the past three decades.

I can assure you, you can stick with Electron apps only for your business but
the moment I find a native version of the same apps, I'm done with your
business too. Slack, VS Code/Atom, etc, none of them are on my recommendations
list and they will never be until they either go native or there's a native
competitor. Sublime Text destroys VS Code/Atom completely and yet, the version
they've built 5+ years ago is still better than Code/Atom today in pure
performance despite all of improvements Atom has done.

~~~
kayoone
That is the right opinion and programmers should think like this, but i also
believe that this kind of thing is hard to stop when it makes it easier for
devs to churn out software with existing skills and most non-technical users
do not really care anyway. I guess it is a reality we have to accept and wait
for web-tech based desktop app development solutions to mature. Maybe react-
native is the way ?

~~~
mikhailt
Technology moves in cycles. We went through this back in 90s and 2000s with
Flash, Dreamweaver, ActiveX, Ruby, PHP, and etc.

I suspect we'll see us going from Electron > React-Native or identical and
then realizing the benefits of native stuff and back to native code once
MS/Apple/other OS try to replicate the ease development process with their
languages like Swift, C#, Go, and etc.

------
smilesnd
When you have a hammer everything looks like a nail. I personally hate
electron for multiple reasons.

First why would you use web technology to build a desktop app? I could
understand if their wasn't a cross platform answer like python and java that
are high enough languages that even middle school kids can learn to make
desktop apps with. Yet lets default to language and markup language
specifically design for a client server relationship.

Secondly from my experience electron runs horribly on linux and windows. I can
always tell a desktop app uses electron on my desktop not just by the larger
then normal amount of resource it takes to do simple task, but because it will
randomly crash. It crashes silently and instantly reboots it self and try to
act like nothing happen but it happens so often that I catch it when it does.

Thirdly, I am not about to act like I am some type of security expert, but
this is just screaming at me security risk. Electron uses at least 4 engines,
how and when do they get updated and security patches installed? Can the
programmers stop upgrades of these engines to insure that their app will
continue running as is? You can argue all things are security risk, but when
you put so many complex engines in one app it is bound to make it difficult to
keep up with all the security concerns.

I could keep coming up with more and more reasons why electron is horrible
solution to a problem that already has solutions. The appear to webs to keep
using technology they are comfortable with is horrible reason to justify this
Frankenstein of a code base.

~~~
Can_Not
> python

Literally the only advantage of this is the lack of DOM related performance
issues. Support for mobile is probably a nightmare and you still have to make
the website anyways, so might as well write it once. Also trying to combine
cross platform, speed, and 3 sounds like it's own nightmare anyways.

> Java

Much more practical option, main cons involve large JRE download and I still
have to write my website in JS anyways, so why write it twice? React Native
really brings the mobile performance up to par that fits 95% of non-game use
cases.

This next statement is not directly related to the parent comment: I'd like to
read more about why eletron alternative​s are better (or exist) and less about
how electron is slow or some other thinly veiled hand-wavey "bad because js".

~~~
smilesnd
>python comment \- Electron doesn't support mobile so I don't understand this
comment. Their are lib for python on mobile good, bad, or evil I don't know.
It isn't just a lack of DOM related performance issues it is also V8
performance issues, chromium performance issues, and electron performance
issues. When you stack a engine on top of a engine on top of another engine
you can't expect to achieve awesome speeds. And if you are making a desktop
app why would you even care about making a website of that app?

>Java Again if you are making a desktop app why would you also need a website
performing the same task? React Native is for mobile apps electron is for
desktop apps so I don't understand why you are bring this up as well.

Electron exist same reason nodejs exist webbies to scare to learn another
language. JS isn't bad, but how people use it makes it bad. I should actually
say programmers are to scare or lazy to learn alternative solutions to a
problem. It is simpler to use what you already know then to try something
else. What does electron bring to the table? A way for someone that know JS,
css, and html to produce a cross platform desktop app that is it. You don't
gain performance, security, and it isn't the only cross platform solution like
Java once was. People use to use Java only because it was the only cross
platform solution. It had horrible memory leaks and all sorts of issues that
still plague it to today. Yet it was the only cross platform desktop solution
of its time. That is why electron is seen as useless to me I know how to
program in c, c++, c#, JS, and elixir. I would probably learn python stack if
I wanted a cross platform solution to a desktop app.

~~~
Can_Not
> V8 performance issues

Python certainly isn't faster than V8. Maybe in the same class of speed, but
certainly faster is not one of it's advertisable advantages.

> webbies to scare to learn another language.

> why would you also need a website

> to scare or lazy to learn alternative solutions

This is exactly the useless, vacuous discussion points I'm taking about.
You're literally complaining about electron itself and JavaScript (mostly
points that are invalid, misleading, or ad hominems, too) and putting zero
emphasis on what alternatives are actually good and why they are great on
their own merit.

------
patleeman
I built Collate ([https://collatenotes.com](https://collatenotes.com)) with
Electron and I'm a huge fan. Electron does has its downsides but I think that
it's eclipsed by the upsides. For collate, those upsides are:

1\. Ease of building and distributing packages with Electron-Builder. I'm able
to build for all three operating systems on my Mac, took a few hours to set
up.

2\. Access to the vast NPM library for all sorts of functionality.

3\. Ability to use CSS libraries for styling. I'm no designer so it saves me
some time. Collate uses Bulma for styling.

From what I've seen, users are more than happy to have an application that
solves their need no matter what it's created in. Most people don't really
think about file sizes, or the fact that Chromium is packaged with Node, they
just want their problem solved without visual or performance hiccups.

If it wasn't for Electron, Collate would be a very different application or
non-existant. I think people need to look at Electron as opening the door to
more possibilities.

~~~
nirvdrum
FWIW, I didn't mind the overhead of Electron when I only used a couple apps
built with it. Now that that number is increasing, I find myself having to
monitor resources & battery life and selectively killing apps. I have concerns
that this approach isn't going to scale.

~~~
toddmorey
This is a really good point. Could two electron apps share a chrome runtime?
Has to be a way to make this more efficient.

~~~
AstralStorm
They could but cannot as electron versions are different between every app.

------
lioeters
I'd say Electron is "good enough" for many purposes, meaning its advantages
overweigh the disadvantages. Lower barrier to entry compared to native
solutions, developer productivity, cross-platform sharing of code.. Plenty of
large companies use it to build (even flagship) products.

The disadvantage that is most talked about is its final bundle size, and I'm
not aware of any developments that are trying to solve it. I'm in a project
with a number of Electron apps built and in the pipeline, and we're searching
for a potential in-house solution, of a central app that
hosts/downloads/embeds "mini-apps" that run on the same foundation, to share
the same Chromium run-time. Really hoping for a community solution to this
though.

~~~
KeitIG
There is an issue on Github with the idea of creating a runtime for Electron:
you would only need to package your apps and a shared Electron runtime would
execute the different app you have installed on your OS, a la Adobe Air.

[https://github.com/electron/electron/issues/673](https://github.com/electron/electron/issues/673)

~~~
foepys
After seeing what disasters Adobe Air, desktop Java, and Flash have been, why
do people think that they suddenly can do better?

~~~
wishinghand
Because progress comes after many dead ends.

------
ohstopitu
I used to use linux desktop since 2012(ish) and I remember the time when most
of my apps were Windows and Mac only! As a broke university student, I could
not afford to upgrade to a Mac just to use some tools!

Electron has made me forget those days! Today, most of the tools I use are
available on all platforms and while they do take up a lot more ram and disk
space - both are generally things I can buy and fit on my computer and will be
supported out of the box but not having those apps won't.

I know it's great to hate Electron because of how much ram and disk space it
takes, but for those few on Linux, it's truly made life easy!

~~~
interfixus
I am the retrograde, grumpy, obtuse old curmudgeon of a comment somewhere
above. Running everything on Linux for all of this century and a bit of the
last one as well.

As you may surmise, I do not entirely agree with you: I have tried the odd
Electron application, but I don't think any of them lasted a week on my
desktop. It's not just the bloat in itself. Software built on what I consider
iffy technologies - somehow I never really manage to trust them or just feel
reasonably comfortable with them.

~~~
ohstopitu
oh I totally agree, almost all those apps don't fit in with Gnome or even
Unity (almost all electron apps feel out of place). But imo, it helps make
life slightly easy!

~~~
interfixus
To each his own. I'm most certainly not out to stop anyone. And I realise I'm
too much of a purist for some :)

------
untog
I'd be wary of taking HN's opinion as gospel unless your target market is HN
users.

I don't like Electron apps particularly, but I understand why people make
them. I think that if your desktop app is "the thing" you're making then you
should avoid Electron if possible, as it does provide an experience that's
subpar. But if your desktop app is just a convenience offering for your
product that lives mostly on the web, I think it's fine to use it.

(there are exceptions like VS code, but they're very finely tuned compared to
the average Electron app)

------
romanovcode
It's a complete garbage. Take a look at applications like Slack - they are
super heavy in size, memory and CPU consumption.

Even the arguably fastest applications that are built with Electron (VS Code)
are very slow if you compare them with native applications.

~~~
harryf
VS Code is a great example... resource hungry it may be but as an app, it's a
huge success (based on the Github extension for example that has over 6
million installs -
[https://marketplace.visualstudio.com/items?itemName=GitHub.G...](https://marketplace.visualstudio.com/items?itemName=GitHub.GitHubExtensionforVisualStudio)).

It would seem like building desktop apps with Electron is a big boost
productivity wise (shorter learning curves, quicker time to working app) than
older alternatives (Java, .NET etc, MFC etc.). If that assumption is correct,
then it's trade-off against resource is worth it: get working but resource
hungry app quickly in the hands of real users vs. take more time building
something resource efficient but with user-validation still to do.

------
mmccaff
Define "good" :)

If you need to have a desktop app quickly (for multiple platforms, even) and
it's the difference between launching something or not, then yes it is good.

If memory footprint and performance is a critical part of what you're doing
(it's not always), then maybe you should look at a different technology.

I think Electron has allowed a lot of cool things to come into existence that
wouldn't have if not for Electron.

------
rmccue
Electron definitely isn't the greatest: it's inefficient, duplicative, and
makes your app way larger than it needs to be.

With that said, IMO Electron is great purely for the reason that it opens
desktop development up massively.

I've written native apps before and it has been a world of pain. Electron lets
me use tools and skills I already know to spin up desktop apps. I know I'm not
the only one who this applies to, and there are a bunch of apps that probably
wouldn't exist if Electron didn't. It's usually a false equivalence to compare
Electron apps to full native apps.

If the choice is between an inefficient Electron app, or no app at all, I'll
take the Electron app any day.

------
iamNumber4
Electron is the new flash.

While the things built with Electron may be really great apps, we don't need a
full browser running for each application instance eating CPU cycles when the
applications are not doing anything except sitting idle.

Just write desktop applications if you want a desktop app. If you want a
website in HTML/CSS/Javascript then write a website.

Can we please stop trying to jam square pegs in round holes???????

~~~
allover
> Just write desktop applications if you want a desktop app.

Yeah ... you 'just' need 3 teams, or you 'just' need to use Qt, which doesn't
exactly seem to have 'caught on', and has a piddly community compared to the
web & Node communities.

> Just write desktop applications if you want a desktop app. If you want a
> website in HTML/CSS/Javascript then write a website.

Not sure if you're being intentionally obtuse, it's clearly not that simple.

~~~
AstralStorm
Electron itself hasn't really caught on either and is the newer technology.
Comparing it to web communities is disingenuous. Heck, Node.js deployments
have their share of horrors.

Especially if your goal is to have a native app experience and not a website
in an app. Electron does not really deliver that.

~~~
allover
Slack, Hipchat, Spotify, Whatsapp, Gitkraken, VS Code, Nylas, ...

I'd say it's caught on. Only Qt app I'm aware I ever use is VirtualBox?

> Comparing it to web communities is disingenuous.

How? You use web technologies to built Electron apps. The strength of those
communities is a big win.

> Heck, Node.js deployments have their share of horrors.

It also has its share of successes, just like any lang/community. Not a useful
generalisation.

> Especially if your goal is to have a native app experience and not a website
> in an app.

FUD. People overstate the 'native experience' argument. Real users don't give
a crap, there are tons of apps, even built with 'native' tech that feel unlike
any other app. If I ask an average user the difference between
Whatsapp/Spotify vs some native apps, are they really going to say
'Whatsapp/Spotify don't feel native'?

None of the apps I listed feel like 'a website in an app'. That's a huge
exaggeration.

~~~
bwat49
> I'd say it's caught on. Only Qt app I'm aware I ever use is VirtualBox?

VLC, Origin, Battle.net, Google Earth, TeamViewer, TeamSpeak, Telegram,
Malwarebytes?

------
luord
Just like the latest discussion about electron, I say: our primary concern is
the users. Tron said so.

We should be concerned for their privacy, for their security and for their
computers in general. Giving them applications that will eat up their
resources as the only option is downright unethical if we remember that our
primary concern is "fighting for the users."

I love javascript, I like working the web frontend, but porting the web to
desktop by... not doing it, only hiding the browser, is just not the way to do
things.

And, by the way, it saddens me that a lot of arguments in favor come down to
"we already wrote the website, why do it twice?" That's just _lazy_ and shows
a remarkable lack of intellectual curiosity for a field in which being on top
of things and updating constantly is key.

------
rsynnott
Produces slow (I've yet to see one that wasn't pretty clunky), resource-
hungry, non-native-feeling apps. Not a fan.

Also, bundling lots of different Chromes in apps which may or may not ever be
updated feels like a security issue.

------
jensnockert
It makes it easier to get started, and you can often kinda-ish reuse some
effort from your webpage at the cost of bad performance and non-native
look/feel.

It's a trade-off for me, I use it when the trade-off feels right.

------
macco
My personal take on using electron if the following: If you are creating a big
app that gets a lot of attention from the user electron is fine. If you are
creating a little tool running in the background, electron doesn't work so
well because it often uses a lot of memory. So, building a chat application
with electron is bad and your main text editor for your dev work in electron
is totally fine. Ultimately, the deciding factor should be your users, is it
best for them that you use electron or are they better of, if you are using a
different solution.

Something else to consider are your development skills. If you never worked
with something else than web technologies, electron is hard to beat in terms
of dev experience.

------
joeblau
For developer convenience: Yes

For product performance: No

It's really a question of what you value more. Personally, I value product
performance over developer convenience. I've recently removed all Chromium
based applications from main computing use and my computer has been performing
a lot better.

The only thing I can't get rid of right now is Slack due to work. I wish it
was native, but I understand why it's not.

------
psyc
The only one I use is VSCode. It's a great IDE-lite, but after a day or so it
pretty reliably gets into a state where it's permanently and unusably slow,
and needs a restart. I can't prove this is Electron's fault, but I'm inclined
to give the VSCode team the benefit of the doubt. I certainly do not need to
restart Sublime Text every day in order to use it.

And as an Old, I do believe there's a serious cultural problem, caused by the
Web Rush, where the industry as a whole does not care enough about zero/low-
cost abstractions.

------
zabana
Python Devs: What would you recommend as an alternative to Electron ? I've
heard of PyQT, Tkinter or even PyGTK but not sure what to choose ... Cheers

~~~
cpburns2009
Tkinter:

\- Bindings to Tk (Tcl; cross-platform GUI toolkit).

\- Bundled with Python.

\- Easiest to use but has the least features.

\- Ugly on Linux and is difficult to theme.

\- Good choice for small applications if you only care about utility.

PyQt (or PySide):

\- Bindings to Qt (C++; cross-platform GUI framework).

\- PyQt is GPL licensed and supports Qt 4 and 5.

\- PySide is LGPL licensed and supports Qt 4 (support for 5 is in
development).

\- The pixel perfect purists dislike it on Windows and Mac.

\- Good choice for large applications where an almost native look is
sufficient.

PyGTK:

\- Bindings to GTK+ 2 which is obsolete.

PyGObject:

\- Bindings to GTK+ 3 (C/GObject; cross-platform GUI toolkit).

\- Comparable to Qt.

\- I've heard Windows support isn't the greatest (this may be obsolete now).

\- I'm biased and perfer Qt over GTK on Linux.

\- Good choice for large applications where an almost native look is
sufficient.

wxPython:

\- Bindings to wxWidgets (C++; cross-platform GUI toolkit).

\- Comparable to Qt.

\- Uses native widgets on Windows and Max, uses GTK+ on Linux.

\- Good choice for large applications where a native look is required.

Kivy:

\- GPU accelerated GUI framework.

\- Does not look native.

\- Good choice for graphically intense applications that do not need a native
look.

My recommendation is:

\- Small, utility program: Tkinter.

\- Large application: Qt (if an almost native look is sufficient).

\- Large application: wxPython (if a native look is required).

\- Graphically intense application: Kivy.

------
toddmorey
Lots of commentary here, including "why not just stay in the browser"?
Certainly you can run Slack in a browser tab, but I don't think they'd be
enjoying the same success as they have now without having the presence of a
full app.

So I'd spin the question around: why NOT offer a desktop app
option—considering that electron makes it a pretty light investment for any
team already building a web application?

If you already need your product to work in the browser, you're a small-ish
team, and your feature set is in motion, I think it's a good strategy to do an
electron app because it further incorporates your product into the day-to-day
experience of your users. There will certainly be a point where offering a
native desktop app becomes worth the investment, but that may not be day zero.

Meanwhile, would love to see google work more closely with the electron
project to help (1) use the chrome runtime if it's already present and (2) at
least allow two electron apps to share a runtime footprint.

~~~
toddmorey
All of this said, Slack, I feel you've proven your model out, so it may be
time for you to go native with your product. Do it as part of your commitment
to the environment—you could prevent the emissions required to power so, so
many spinning fans.

------
wishinghand
Is there something coming our way like React Native but for desktop? It
doesn't have to be tied to React (or even JavaScript), just a similar project.

I really like the ease of cross platform publishing. Even as a JavaScript
developer, I loathe the memory footprint. 100-200mb per app doesn't bother me,
though linking to already installed Chromium sounds like a good idea.

------
evolighting
No, and Never,Since the Electron uses Chromium and Node.js so why not browser?
Yes there are something browser could not do , and what I want to say is maybe
there is stereotype. I have been using desktop software using web-gui in
browser and they work just fine. there need something maybe a protocols that
make browser more desktop, but this would never happen since it would give
user too many power.

For now all the google-about things would always end up to benefit google
instead bring convenient to user. Yes I just hate google, And what they bring
to the web(For recent years only)

I think something like Electron should have been made but all I could find now
is web browser or game engine.

There are already too many silly Apps on mobile platform, and Electron is just
another that silly things in my eyes, since I'm just a stupid and arrogant
user

------
drakonka
Having seen the multiple-process-resource-hogs that tend to come out of
Electron it is easy to dislike it, but I have always wondered about one thing:
how does Visual Studio Code avoid these pitfalls? I have never once seen VS
Code spin up more than one process or hog memory. It is built using Electron,
is it not? Is it some fancy hacked-to-death version of Electron that fixes
these issues to the point of not being considered "Electron" at all? Or are
they just _better_ at utilizing the tool in a way that works?

If the former, I am on the "Electron sucks" bandwagon. But if it is the
latter, the fact that there is even just one app that manages to use Electron
to produce a product that does not suffer from these commonly cited issues
would make me hesitate to discount it as a whole.

------
eddd
MVP: Yes. Production, complete products: No.

------
raquo
Wow, lots of unbalanced Electron hate in this thread. Sure it's ugly, but it's
also an extremely productive and empowering platfotm, that's why it's so
popular.

Building a web app and a cross platform desktop app is a common business
requirement nowadays. Electron is the fastest way to achieve that with a small
team or if going solo.

In many cases your only other feasible alternative would be to use Chromium
Embedded Framework or system web views. Those two let you reuse your web app
UI but are progressively more work than Electron. Those options don't require
packaging a node server though.

PS. I don't think Slack is slow because of Electron. Other Electron apps like
VS Code are fast.

------
CyberFonic
I agree, Electron apps are way too big. They include so much cruft whether you
use them or not.

I prefer to write apps with separate server and client parts and the client
JS/HTML is generated by in-house tools and thus is a fraction of the size of
anything that would uses any of the popular frameworks.

In any case, I'm finding that WebApps are easier to deploy and update than
writing for native deployment. In the rare cases that I do need native
features, I can deploy a local server which can then access whatever I need.
The clean separation of concerns between client and server does simplify
architectural design.

~~~
MrBra
Is anyone aware of a unificate resource from where to learn about all the
limitations of a local webpage versus a served webpage?

------
MrBra
Not trolling, genuine question: would Mono be a terrible alternative to
Electron for a cross-platform desktop app?

~~~
zzbzq
Using CEF in Mono to serve HTML/js based UI over a mono-C# back-end is very
feasible, and results in a superior program which answers most of the Electron
complaints in this post. But to answer your question, yes, it's a terrible
alternative, because it's not javascript, and unfortunately the mode of the
entire global software ecosystem right now is for all non-application
engineers to provide tooling to application developers that cater to the easy-
to-use tools they already know (mainly javascript, with some python lingering
around.)

That said, if you work in a .NET shop already, you're certainly better off
using a mono/CEF hybrid app. Just don't expect it to catch on, even if it
generates superior software.

~~~
MrBra
I was talking about a cross-platform Mono GTK# app, not CEF + Mono.

------
nxrabl
I've been on both sides of this issue. A few months back, I needed to put
together a frontend for a rest app on the local network, that my boss could
use without needing to touch the command line. I'm a fairly novice programmer,
but I was able to go from never having written a desktop GUI program, to
having a functioning (if not particularly functional) product, in less than a
business day, which I doubt would've been possible with even something like
Qt. It's incredibly easy to build an app with Electron, and I'd encourage
curmudgeons to give it a shot one weekend, if only to appreciate how seductive
your opposition is.

On the other hand, my laptop is an aging, refurbished Windows rig with a tiny
SSD and all the energy efficiency of a stately Victorian mansion. I really
can't afford to run anything Chromium-based when I'm on battery, which keeps
me from using any of this generation of slick notes apps (e.g. Collate, whose
dev is elsewhere in the thread.) What's more, there are almost no Electron
apps where you can choose the installation location (VS Code is once again the
exception, proving that it _is_ possible), and the cavalier attitude of some
devs when asked about this ([0]) drives me up the wall. So VS Code (and my own
toy app) are the only Electron programs on my computer, and I don't see that
changing in the near future.

[0]
[https://github.com/atom/atom/issues/7504](https://github.com/atom/atom/issues/7504)
\- One example of this attitude

------
rogual
The only real issue I have with Electron, that I don't see brought up when
it's discussed here, is the process model.

Last time I checked, each window in your Electron app had to run in a
different process. This is a design that makes sense for a web browser like
Chrome, but not for the majority of desktop apps.

If your app is simple enough to only need one window, this won't be an issue,
but otherwise, I found it a major pain.

------
sova
To all the naysayers on code duplication (of chromium in this case): Perhaps
if OS vendors were to provide common universal API access to graphics
interfaces and hardware then we would not need a buffer package such as
chromium-as-electron! Not to bust ya bawls, but I hardly think that an
innovation as sleek as Electron deserves the blame for other structural
inefficiencies in the world of software.

------
kayoone
While Electron has it's ups and downs, if the question is wether an app would
exist at all on a certain platform by using Electron vs something else, then i
think it's a valuable tradeoff. And let's be honest, most people (for example
Slack user) that are not HN users don't really care, also there is a lot of
inefficient software done in other languages.

------
lazyjones
Bad idea. We didn't learn from the mess that was bundled vs. installed JREs
and if Electron apps become more popular, users will have dozens of different
Chrome installations running on their systems, taking up disk space and memory
and potentially interfering with each other (that's speculation on my behalf).

------
alimbada
Microsoft have a very interesting approach with their Office suite when it
comes to cross-platform development. They go through it in some detail in this
talk:
[https://www.youtube.com/watch?v=MGMoRu5yrVc](https://www.youtube.com/watch?v=MGMoRu5yrVc)

------
wirddin
If you're delivering what you promised to your customer or end user (without
compromising on speed) then great!

As a developer, I avoid Electron apps because of the battery consumption. But
that's just me. Your end user might not even know the stack or have no idea
about it and only cares about the work being done. So yeah, I guess it's great
for something which needs to be there as a desktop app.

From a dev's point of view: It's like how React Native is growing as an easy
native app development tool. If a team can focus on one codebase instead of
multiple, that's a great thing.

------
ezekg
I think Electron is great for getting something out the door quickly. I also
think that we need to have an Electron "app store" that uses a shared Electron
runtime a'la Steam. I think the Electron developers have previously discussed
that, but I can't seem to find the relevant ticket to link to. An app store
would be a great way to monetize Electron (though I'm not a _huge_ fan of this
idea) and also help promote some great apps, and of course, reduce the overall
file size and resource consumption of Electron apps.

------
yoodenvranx
The only Electron App which I use regularly is Gitkraken and I am quite happy
with it. In my opinion it is not as snappy as a native UI but it is still fast
enough that it does not matter to me.

------
NHern031
I am a Windows developer, primarily C#, WPF, and Win-forms. I must say I have
had my fair share of interaction with desktop applications. Electron is great
for prototyping and bringing an idea to life quickly. Like many have mentioned
the performance is pretty terrible. There has to be a balance between
performance and development time/ease. Personally I can work quickly on WPF
(due to exposure) and tend to stay away from Electron because of its
performance issues.

------
p0nce
(Building desktop apps in native languages since a lot of time.)

While I haven't use Electron, it looks very enticing. In particular the
HTML/CSS combination allows to build UIs very fast. WebGL abstracts away the
graphics drivers problems (at least in theory?). 2D Canvas is optimized and
looking nice. And being non-native shorten the iteration times. Particularly
for games it looks very adequate.

Users surely care about download size but not as much as functionality.

~~~
AstralStorm
Users also care about integration with their platform and matching look and
feel. Neither of those are delivered by Electron.

Also that a tiny app does not start for 10s on a strong laptop with a SSD.

~~~
p0nce
Native look and feel is the first thing to go with friendly consumer products
such as games. Native UI means "generic" and doesn't convey the idea of value.

------
eps
Can one serve a store-bought frozen lasagna in a good restaurant? Certainly.

Would that be a good lasagna? Probably not.

Will it reflect poorly on the restaurant? Most likely.

Why? Because they are OK with serving crap.

~~~
woah
I only use locally-sourced, artisanally curated softwares.

------
BrunoWinck
Much better than many native libraries. I added some extra node modules for
some specific calls I needed and it went smooth. I'm now converting a second
desktop app because it went so well. What disturbs me the most is the numerous
process launched. Neither of them really big. I learned that it's also a
benefit. not having total scope of a desktop app when you embed
HTML+Javascript from uncontrolled sources.

------
eberkund
I see many people writing that it's okay for apps to use hundreds of megabytes
of RAM because there are 16GB computers available now. The problem with that
is what if I want to use a $250 laptop with 4GB and an Atom or ARM processor
instead? Now I can't run your application. This is coming from someone who has
written a couple of Electron apps and has deployed them in production.

------
sova
Totally! Electron is Slack! I think it's huge and unnecessary and would never
choose it in my own design decisions, but if you're able to use it for your
needs go for it. What an amazing package. It's as close as we have to a
universal framework imo. Here's to crossing my fingers and toes that
WebAssembly has immutable data.

------
sktrdie
Considering there are companies such as GitHub and Microsoft (VSCode) behind
Electron, I'm thinking they will eventually fix the memory/CPU footprint
problem.

In terms of programming and development I think it's great. Not to mention
that with JS there's tons of languages one can choose from -- think of Elm,
PureScript, TypeScript etc.

------
anilgulecha
The big complaint against electron is multiple copies of the runtime.

It's unfortunate that google has stopped supporting chrome apps as a platform
-- this was pretty much the solution. Single runtime + many apps.

It should be up to the community to pick up the slack, and launch a single
(updating) runtime, and allow apps to run off it.

------
kurinj
I think Electron is better suited for prototyping. I have a hardware/firmware
background so those sorts of applications are outside of my wheelhouse, but
using a web browser as the runtime for something that's not a web-app seems
very strange to me. Why not just use something like QT?

------
bikamonki
Go one step back: why desktop app?

~~~
antaviana
There are use cases where a web app is not suitable. For example:

\- Sensitive data that you do not want to be known by thid parties

\- Very interactive applications where consistent subsecond response times are
needed

\- Applications that rely on data located in the computer (for example from
other desktop applications)

~~~
AstralStorm
Funny thing, Electron is currently unsuitable for first 2 and has serious
trouble with 3rd.

------
k__
VSCode is the only product I regularly use AND like.

Tried Atom and and Hyper and they felt really sluggish.

------
skdotdan
Ease of development vs software quality for the user is supposed to be a
trade-off but I'm quite convinced it actually isn't, and it may be one of the
biggest lies of the software development history.

------
problems
Ugly, bloated, poorly integrated and weird UI bugs, like scaling randomly
failing on high DPI displays.

Only useful for web-only teams who have no desktop experience whatsoever. If
you can afford to hire a desktop team, do it.

~~~
mbrock
I don't know if Spotify is Electron but it's some kind of embedded Chrome and
I'm really happy that it scales so well on my Linux HiDPI setup. The regular
zoom shortcuts for Chrome just work. I also love that about Slack. Arbitrary
user zooming in native apps is usually not implemented at all.

~~~
problems
Try to use VSCode or Atom on Windows on a 4k display - blurry text, text that
random switches between blurry and not blurry. Seriously, I had it so every
even scroll was crisp and clear but every odd scroll was blurry and awful on
VSCode for some reason, I confirmed this looking at it on a 100dpi screen.

The relevant bugs are upstreamed to Electron.

~~~
mbrock
I wonder if HiDPI is handled better by the other cross-platform UI toolkits
that people recommend over Electron...

------
falcolas
I think Electron is good for putting webapps on the desktop. The disadvantages
of not being native shows up all over the place, unfortunately. Slow, memory
hogs, CPU hogs... they're a mess.

------
MrBra
What do you guys think about "8th"?

[http://8th-dev.com/index.html](http://8th-dev.com/index.html)

~~~
MrBra
Answering myself: $$$.

------
skibz
I think it's a great fit, provided the resource-usage (which is likely to be
high) of the app is justified.

------
pyed
I can't say that I'm not a fan, I'm a hater who rolls his eyes off anything
built with Electron.

------
tuananh
Electron makes Java looks good!

------
swiley
You're way better off not writing a GUI than using electron for it.

------
jackmott
good in that it the easiest option for moderm developers to get something
done? yes. but it is horribly inefficient and we the industry should provide a
better tool than this nonsense

~~~
dom0
> easiest option for moderm developers

for modern [web] developers.

Contrary to what one might think by reading tech blogs and HN, developers come
in more varieties than just "web" and "wizard".

------
jlebrech
Kotlin?

~~~
VladimirGolovin
No. The current iteration of Kotlin Native doesn't target Windows due to some
peculiarities in it's exception handling mechanism. And Windows is the #1
platform for desktop apps. As much as I wish I could reuse our mobile Kotlin
code in our desktop app, that isn't very practical at the moment.

