
Electron 4.0.0 - gozzoo
https://electronjs.org/blog/electron-4-0
======
Djvacto
I always read about how Electron is very resource-intensive, but I'm curious
as to how the performance improves as time goes on?

Does the Electron team have a focus on improving performance? Or is the issue
with the developers using electron, should they be optimizing better?

I assume it's some of both, but curious if anyone with more experience in
electron can provide any insight as to how the performance changes over time.

~~~
accatyyc
The issue itself is that Chromium uses a lot of memory. And electron basically
just runs Chromium. Except that since each Electron-based app ships its own
very isolated copy of Chromium, the following problems occur:

\- The operating system cannot share memory between different Electron
processes. Normally if you start many processes of the same binary, the memory
is shared and only copied on write. Since each Electron app is a different
binary (even though they are 99% identical) they each eat memory.

\- The above applies to disk size as well. Electron apps are usually huge, and
99% of the binary is the same as all your other electron apps.

This is mostly why I'm against electron. If electron worked like the JVM and
each app shared a runtime, many issues would be solved, including many
electron apps running old, and vulnerable versions of Chromium. Now it's only
updated if the developers decide to ship a new version.

~~~
PaulHoule
Why is it that people seem to think using a cross-platform UI toolkit like
tkinter, kivy, WxWindows, etc. is like putting their hand in a toilet?

Lately I have been building apps with tkinter/python/asyncio and I can't get
over how fast the apps are to load and to use. There is none of this "let's
not respond to the mouse for 5 seconds" that is staggeringly common on my mac
(particularly for apps like Safari and iTunes that come from Apple) nor the
"go for a walk around the block" loading times for Java-based apps on my i7
Windows laptop.

True tk apps are ass-ugly but I find it mind-blowing to use GUI apps that are
as responsive as Windows 95 apps were back in the day.

~~~
jniedrauer
> Why is it that people seem to think using a cross-platform UI toolkit like
> tkinter, kivy, WxWindows, etc. is like putting their hand in a toilet?

tkinter specifically does not look very pretty without some effort. I would
much rather use GTK or QT. The problem is GTK support on windows is limited,
and QT has a weird license model.

~~~
blattimwind
> QT has a weird license model.

Qt is available under LGPL and GPL. What exactly is weird about that?

~~~
jniedrauer
Looks like it's changed since I last looked into it. Probably a good option
now.

~~~
blattimwind
Qt had been available under the LGPL since 2009.

Up until 2005 or so Qt had indeed a relatively complex licensing scheme where
the available (i.e. the license of Qt) and compatible (i.e. the license of the
application, due to their GPL exception allowing applications to use MIT, BSD,
...) differed by what was then Qt ports (e.g. Qt/X11, Qt/OSX, Qt/Windows).
After that they always had a uniform licensing model for Qt, were the
licensing was independent of the platform.

------
burtonator
I've been heads down into the Electron internals for 2-4 months now and
working on a document manager for PDF and web content:
[https://getpolarized.io/](https://getpolarized.io/) (self plug)

The inevitable thing that always gets brought up is memory usage.

It's really not insanely bad if the app is important. I wouldn't use it for a
calculator but if it's an important app allocating 150MB of RAM seems worth
it.

The biggest change here seems to be the build system and the upgrade to
Chrome.

The Chrome updates are what's important here. Since Chrome is evergreen if
your behind a few versions the standard libraries in NPM just stop working.

I got bit a while back when when they were a bit behind in releases.

~~~
diminoten
Who doesn't have 150MB to spare?

This laptop has 16GB, why are people hemming and hawing over 150MB???

~~~
agildehaus
> This laptop has 16GB

Okay? Having a lot of memory does not mean a program should be wasteful, nor
does it mean everyone has that.

~~~
diminoten
Yes, it actually does, because it redefines wasteful, and the availability of
many-GB computers means a lot of people _do_ have access.

This isn't 2008, we don't need to care about 150MB like we used to.

~~~
vmchale
> because it redefines wasteful

how do people write shit like this and not realize how blatantly user-hostile
they are??

~~~
diminoten
Because it's not user hostile at all?

------
sidcool
I have heard a lot of complaints about Electron on various aspects, but one
thing it has done well is to open the niche of cross platform Desktop apps to
an average regular developer like me.

It can be also used to quickly test an idea before dedicating platform
specific resources.

I hope the team adds more features keeps Electron alive.

~~~
criddell
Microsoft adopting Chromium is a big hint that they are going to make some big
investments in Electron. I think Electron's future is bright.

My big complaint isn't the resource usage, it's how the applications never
feel right on any platform.

~~~
chr1
It's a feature, they feel like a part of the web, which is the more important
platform, for the majority of people who spend most of their time using web
apps.

~~~
na85
Ugh, I can't wait til this era of "everything must be a web app" is over.

Web apps are universally worse in their UX than native.

~~~
pjmlp
For a while I though native mobile web apps had it, but now with PWAs,
WebAssembly and the return of mainframe, sorry cloud, I guess they are here to
stay.

------
fabiospampinato
There are always many negative comments regarding Electron apps, so as a
developer who has made a couple Electron apps let me briefly illustrate to you
what the advantages are:

\- I can use the same UI components that I use for making websites and easily
share code between all platforms. Maybe this will change in the future with
the advent of WebAssembly, but right now no other stack gives you this.

\- Bundling a cross-platform auto-updating app is wonderful. I just have to
configure electron-webpack [1] and everything is taken care of. In the past
I've made a password manager with GTK3 + Python, bundling it was a real
nightmare and I don't think the situation improved much in the last few years.

\- Sometimes, like when you're going to need a HTML renderer anyway, using
basically a browser for rendering the UI can actually be an advantage, a
couple of examples:

Example 1. Evernote needs to render their notes, basically arbitrary HTML, and
the macOS app uses Safari's engine for this. Now they have to check across all
platforms if their notes are always rendered the same, even for rendering a
simple note they show you a spinner, and the native UI is arguably ugly
anyway. In comparison my soon-to-be-released Electron note-taking app [2]
looks more native to me, it's faster, requires less resources, and I get
cross-platform support basically for free.

Example 2. I was using Ship [3], an app for managing GitHub issues. The native
parts of the UI were written in Objective-C, the issue/comments part were
written using web technologies, and their server was written in C#. What you
get is an app that doesn't work across platforms and sharing code between all
the parts of your application is basically impossible.

\- Lastly I'm by no means an expert on other cross-platform UI toolkits, but
some of them try to mimic the native widgets and do an awful job at that, as a
result I don't have any Java GUI app installed because they all looked like
crap to me, how many do you have installed on your desktop?

[1] [https://github.com/electron-userland/electron-
webpack](https://github.com/electron-userland/electron-webpack)

[2] [https://imgur.com/a/ZQd8Vad](https://imgur.com/a/ZQd8Vad)

[3]
[https://www.realartists.com/blog/ship-20.html](https://www.realartists.com/blog/ship-20.html)

~~~
LeoPanthera
> I can use the same UI components that I use for making websites and easily
> share code between all platforms.

I propose that using web components for desktop/mobile applications is _not a
good thing_.

~~~
stiGGG
>I propose that using web components for desktop/mobile applications is not a
good thing.

Agree, every platform has it's distinctive look & feel and as a user I expect
that my apps follow this for 100%. Recently I checked out Flutter, with the
1.0 release i thought it's worth to play around with it. The first thing i
did, was installing their demo app on my iPhone they showed on the release
event. Within seconds I noticed that there was something wrong. They tried
hard to reimplement the bounce effect during scrolling on iOS, but it just
didn't feel 100% right.

I totally understand, that not every user out there has this sharp eye for
things like that and that there is definitely a business value going cross
platform, but this is not something I would be proud as a developer. It's the
cheap root for the developer ending up in a cheap experience for their users.
Share your business logic between platforms if appropriate, theme it for your
CI if needed, but do the UI as expected.

~~~
WorldMaker
I disagree. I think cumulative hours across the average spectrum of users,
they spend far more time on the web / in a web browser / in web tech-based
apps than they ever spend (or at least notice they spend) in a "native" app.
The web platform has won. It is native toolkits that have to follow web
conventions now (hyperlinks, routing, deep linking, system back buttons, etc),
and there are users starting to complain when they don't. The platform
distinctions are starting to be meaningless to users so long as basic "web"
usability is met. (I've met people that switch between Android and iOS
regularly based upon whatever was a cheaper device or had a better plan with
their carrier. Those sorts of people absolutely don't care about "native"
widgets and see the differences in platforms as a silly barrier to the web.)

(Arguably that's a problem with Flutter too because it isn't "native" nor
"web", it doesn't entirely meet the expectations of web users currently
either.)

For better and worse, the web is a ubiquitous platform, and I think getting to
be just about the only platform that matters today, regardless of the
remaining fan wars between the "native" platforms.

~~~
monocularvision
While they are arguably old, these two quick sources I found seem to indicate
quite the opposite:

[https://amp.businessinsider.com/time-spent-mobile-
browsing-v...](https://amp.businessinsider.com/time-spent-mobile-browsing-vs-
apps-2015-9)

[https://amp.theguardian.com/technology/appsblog/2014/apr/02/...](https://amp.theguardian.com/technology/appsblog/2014/apr/02/apps-
more-popular-than-the-mobile-web-data-shows)

Even though they are old, the trend at the time was clear: people are spending
more time in apps (most of which are probably native) than on the web. The
idea that the web is universal and what most people spend their time on isn’t
a fact you have established.

Web technologies are loved by developers for their speed and ubiquity. But as
a user, I strongly prefer the feel of mobile apps for my day to day
interactions. I find the web, particularly on mobile, to be a mess. The
interaction models are all unique and confusing and typically not well
implemented, while native UI widgets work well and are understood.

~~~
WorldMaker
But your mobile device is also only one device you interact with in a day.
Very few people have the same OS across all their devices, even if you allow
for the "close cousins" scenarios like people that only use iOS and macOS.
Everyone uses the web everywhere, though, it's the one thing guaranteed to tie
all of a user's devices/accounts/actions/"digital life" together today.

I don't have numbers to back it up, I have a lot of anecdotal evidence I've
seen, but it does look like there seem to be at least as many people that
don't care what widgets an app uses, so long as the app works, as there are
people such as yourself that even notice native UI widgets and care about them
(deeply and vocally, as often the case may be).

~~~
monocularvision
Perhaps, but I surmise that most people spend a large amount of their personal
time and life on their mobile devices while people who are using full
computers are generally doing so for work. I have seen it personally in my
work that native mobile app usage has surpassed both desktop and mobile web
usage.

------
Artemis2
⌘+F “performance” or “memory” does not show anything :-/

~~~
drb91
At this point, especially after seeing how snappy vscode can be, I’ve written
off slack’s performance issues to their codebase.

~~~
EpicBlackCrayon
Yup, another good example of this is Hyper vs. Terminus. Both Electron apps,
but Terminus is way more performant and less memory hungry. I've taken that
(along with Slack vs. pretty much every other Electron app) to mean that yes
you're going to get some sort of inherent performance hit going Electron over
native, but a huge performance hit can arise from a crappy
architecture/implementation. For instance, doesn't Slack use a different
webview for each channel?

------
bluetidepro
Say what you will about Electron, but congrats to the team on getting 4.0.0
launched!

------
amelius
I'd love to see a version that is based on Firefox / SpiderMonkey.

~~~
pjmlp
It was called XUL, long before the Electron craziness.

~~~
maxxxxx
That's an area where Mozilla could have distinguished itself by being very
developer friendly. A few years ago I was looking into embedding a browser and
XUL would have been a good fit but it was pretty obvious that it wasn't
supported well.

Same for their Javascript engine. Node could be running on Mozilla code
instead of V8 if Mozilla had been more developer friendly.

------
moron4hire
I like Electron's features, but I don't like how it runs its own Chromium. I'd
really like a small, local server launcher that just runs whatever default
browser the user has selected, with a borderless window. No attempt at auto-
integrations between client-view and server code, just let me do it like a
regular SPA. Bonus points for letting me specify my own server executable, so
I can do it in whatever language I want.

EDIT: seriously, it could run its own local server for privileged OS
integrations, giving you an IPC API over REST.

~~~
ravedave5
There was a rumour that with Edge going to chromium MS wants to make the
engine available on windows so that electron on windows wouldn't need to ship
with a copy of chromium.

~~~
topspin
Given that Microsoft recently acquired the primary Electron developer, GitHub,
that concept seems plausible. And I have a difficult time finding fault with
it.

You see endless 'concerns' about Electron resource usage. What you don't find
are complaints that it's unstable, or that it only works on some desktops, or
that it's hard to understand or use. It's solid, it works on all desktops and
it's about as easy to use as such a thing can be for contemporary full stack
developers.

For better or worse I think the whinging about resource usage isn't going to
hinder Electron much.

------
hs86
For Chrome users that leave the browser open all the time, is there a reason
to choose an Electron based chat-app, that usually sits in the background,
over just installing its PWA on the desktop?

Chrome now supports native notifications on Windows/macOS and even apps
without full PWA support seem to work fine by just creating a shortcut and
setting it to open as a new window without the browser's UI.

~~~
saint-loup
For me the reason would be first-class status in the taskbar/dock. I like
having some apps only a click away and in its own window, not lost among many
open tabs.

For some time you could do that with any web page in Chrome, with "the create
a shortcut" option. But now Chrome opens them in a new tab, not in a dedicated
window.

~~~
hs86
After adding the new shortcut you can go to chrome://apps and right-click on
any app to select "Open as window". This should bring back the desired
behavior and these app shortcuts now have their own entry in my taskbar/dock.

~~~
saint-loup
Ho nice, thank you. The option used to be in the creation dialog.

------
rewgs
One major issue with Electron that I don't see talked about much is backwards
compatibility. This release states that because Chrome no longer supports Mac
OS 10.9, Electron doesn't either.

Resource usage aside, there's far too much control of a given app being given
to the Chrome team.

~~~
jlokier
Ouch. Thanks for mentioning the issue. I'm still happily using 10.9 on my main
laptop and in no rush to change, and I was hoping to look into using Electron
for a project, so that's going to be awkward.

~~~
sroussey
Does Apple make security updates for 10.9 anymore? Seems like a security risk.

~~~
godDLL
Having used all of the subsequent iterations of OS X, now I will be reverting
to my Time Machine copy of 10.9 because really, the usability of it has gone
downhill from that point on. Or even 10.8, I'm not yet sure.

Who cares if it's secure but sucks so much that I'm not using it anymore?

------
azhenley
I really want to use Electron for a project I have coming up since it checks
all the boxes, but all I ever see are complaints about the performance :(

Is the performance really that bad? Plenty of successful applications are
using it. Is there a fix in the horizon?

~~~
jf-
The performance really isn’t that bad at all in my experience. The complaints
you see are _developer complaints_ , where they’re talking about resource
usage that ordinary users would never notice or question, or UI lag that most
users wouldn’t care about (I only add this because someone else in this thread
claims to have encountered it, but I never have, or have never noticed). If
you find web apps running in chrome to be acceptably performant, then electron
is fine for your use case. But naturally, a native solution will be faster if
you’re doing something that really is resource intensive.

VS Code is electron, I use VS Code every day without noticing any issues. I
think the complaints about electron are moot.

~~~
weiming
> where they’re talking about resource usage that ordinary users would never
> notice or question, or UI lag that most users wouldn’t care about

But this is such poor logic. We can notice these things, while regular users
just suffer not knowing why their battery drains so quickly, unable to
pinpoint the problem.

~~~
jf-
> But this is such poor logic.

No, it’s not. It’s at most a trade-off. Some developers will doubtless make
this their hill to die on, but I suspect it really has nothing to do with
performance or battery life, and it’s likely motivated by resistance to web
technologies being used on desktop vs what they’re used to.

Also I’d like to see some actual battery life benchmarks for electron, because
I don’t imagine that it’s a huge deal, but benchmarks would prove the matter.
It also ignores actual desktop users or users who just use mains power all the
time.

~~~
spiralganglion
If you’re on a Mac, open up activity monitor and watch which apps use the most
energy. For me, the energy used by Atom, Slack, and Chrome is vastly higher
than the energy used by other apps (inc. Safari loaded with tabs). It’s
possible to make an energy efficient Electron app — you just need to
aggressively shut off event loops when there’s nothing to update, which is
hard so most app (and site) devs don’t bother. (I make complex animations on
the web, so I’m hyper attuned to perf and energy use)

~~~
ryacko
I’m curious, do you compile anything to asm.js?

~~~
spiralganglion
Not yet, though I'm keeping my eye on WASM and will pursue it if the need
arises. The sort of work I do has relatively little overhead from the JS, and
is mostly bottlenecked by rendering (SVG, mostly). WASM wouldn't help my
load/parse times since I rarely ship more than a few Kb of JS, and it wouldn't
help my per-frame times or latency because I'm usually done the JS part of the
frame in around 1ms.

------
casper345
I use Electron as a quick MVP for basic apps. If the apps become more complex,
then we will talk about moving to a native platform if we need to focus on
native libraries or performance. Pick the tool for the job at hand.

------
dtougas
I have high hopes for Electron. In some regards, it feels like the new Java. I
remember in the early days, using Eclipse and thinking how bad the performance
was, but appreciated all the functionality it brought, despite being written
in Java. Now days, I am in love with the JetBrains IDEs, and don't think twice
about the fact they are Java. The performance is great, and they look good
(IMHO). I suspect that in the future we will feel the same way about Electron
apps.

------
patagonia
So someone should clearly fork it to Firefox. Not me. Not if you want it done
right. There has been a lot of talk on HN about Chrome having to big a slice
of the pie. Whelp.

------
tommoor
I've worked with Electron and previously NW.js for over 6 years. Here's what
you need to know – if an apps performance is bad 99.9% of the time it's the
developers code, not Electron that's the issue.

Sure, the bundle size is large and the memory footprint is ~200Mb but those
should not be limiting factors if you have a computer from this decade.

------
PascalW
A lot of people express concerns about Electrons resource usage. I wonder if
people are aware of projects like zserge/webview [1]? It provides a cross
platform API on top of the built in platform browsers and thus is very
lightweight.

Of course, it means you have to deal with cross-browser issues, but I guess
webdevelopers are used to this anyway. I'm also aware that these projects
don't provide all the APIs that Electron provides, but many apps that are
really just a wrapper around a webapp this is totally fine IMO.

[1] [https://github.com/zserge/webview](https://github.com/zserge/webview)

~~~
skymt
That doesn't seem like it would solve anything, unless I'm missing something
substantial. Which specific browser engine it uses isn't as important for
resource consumption as the fact that it's spinning up an entire browser
engine per process.

~~~
PascalW
At least the binaries are substantially smaller because they don't actually
include the browser.

I can also imagine there's some potential for sharing the same engine across
multiple apps, though I'm not sure if they actually do this.

------
johnwyles
Isn't it funny the Palm Pre was in some sense what Electron apps have become?
Just an anecdote - I understand all the differences between them but I didn't
even think at the time the Pre came out that it was "ahead of it's time" but I
suppose it was - then again there was also the iPhone that killed it as well.

------
faitswulff
Discord seems to buck the trend of both Electron and React Native being
bloated and slow. How do they do it?

~~~
Klonoar
The thing about Electron (that is often drowned out in these threads) is that
it's a web browser, which means... like any website, there's a litany of weird
performance tricks you need to know and be aware of to make a good performant
UI that doesn't have performance degrade over time.

Like many websites in tabs in a browser, sometimes... it's easier to just kill
the tab or window, and re-open it. Usually a sign you've done something wrong
in your UI handling code.

------
dolguldur
One of the less obvious reasons why Electron has become so widely used is that
Apple hasn’t invested anything meaningful into improving AppKit in the last
5-10 years. If Cocoa was a joy to use I’m sure there would be more native
apps.

------
legostormtroopr
I can't wait to hear about all the new features at ElectronConf... oh...
nevermind.

~~~
bluetidepro
I don't get the joke? Is/WAS "ElectronConf" a real thing?

~~~
dx87
It was going to be, but they didn't have enough minorities and woman giving
talks, so they cancelled it. Looks like they deleted the announcment, but here
is an old reddit post where people are talking about it.

[https://www.reddit.com/r/javascript/comments/6f8u2s/githubs_...](https://www.reddit.com/r/javascript/comments/6f8u2s/githubs_electronconf_postponed_because_all_the/)

~~~
sifoobar
Surreal.

I guess the good news is that this level of dysfunction should take care of
the other Electron issues all by itself if we just wait a little while.

------
mezzode
I still think that the majority of Electron apps can and should just be PWAs.
Most like Discord pretty much just wrap their webapp anyway.

------
rafaelvasco
I stay away from Electron and JS desktop apps in general because:

\- Huge distribution size. Your code is 1% at most. 99% is redundant. I want
10 meg at worst hello world dist size. \- This is more a problem in JS
ecosystem in general: No good enough standardized or not way to do the
frontend part of the app. Angular is not good enough, neither is React or
anything else. Though it is gradually getting better.

------
solarkraft
> Electron v4.0.0 includes Chromium 69.0.3497.106

Isn't this already outdated by months?

------
duarteoc
Congrats team, looking great!

------
ronlobo
Nice!

Has anyone played around with flutter.io? Is it similar to electron?

~~~
forgot-my-pw
Flutter for desktop is still pretty new, but it sounds promising.

[https://medium.com/flutter-community/flutter-on-desktop-a-
re...](https://medium.com/flutter-community/flutter-on-desktop-a-real-
competitor-to-electron-4f049ea6b061)

------
lousken
if only electron vanished from the earth...

~~~
exitcode00
Think this is bad? Just wait until everyone adopts asm.js. So we can compile
C++ code to "fast web apps" which will run in the asm virtual machine, in the
javascript DOM sandbox, in the thin webbrowser client, and finally in the OS.

You can laugh, but that day is coming and I fear getting armies of college
grad hipster-coders creating unreliable slow layered software until we have
nothing but "Material" UI flat buttons and cursor lag when typing simple
messages in a simple application. AHHHH

~~~
AnIdiotOnTheNet
You forgot the new OS wars, which happen on top of this "platform". Remember
guys, one more layer of abstraction is all we need, then there will be no more
problems forever!

~~~
exitcode00
ROFL, at some point there will be a javascript CPU
([https://twitter.com/steipete/status/1047415826083729408](https://twitter.com/steipete/status/1047415826083729408))
- and the entire OS will be asm.js. Then the cycle will begin anew with web
browsers being built for the OS. God help us all D:

~~~
AnIdiotOnTheNet
Buried deep down in the microcode of that CPU will still be an implementation
of 8086 real mode, which will still be the default boot state.

