
Electron 7.0 - ausjke
https://electronjs.org/blog/electron-7-0
======
scrollaway
I'm bullish on Electron. I think it's just a couple of technical advancements
away from being the ultimate desktop toolkit.

For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as
a user. But Electron has brought true cross-platform development to _all_
platforms (Including Linux!). If it weren't for Electron, I wouldn't even have
a bunch of the apps I use today. Hell, I wouldn't have a good IDE, and I don't
think I'd be as good in Typescript had I not been a day-1 VS Code user.

I think the main thing preventing it from "feeling" good to most users is the
most common complaint on HN about how each individual app is its own version
of Chrome. This sucks; it's heavy, it's laggy, and users feel it even
instinctively.

OSes and frameworks have tried to solve this a bazillion ways. Edge WebView,
Android WebView, Qt WebView, QtWebkit, whatever the iexplore stuff was in XP,
…. Electron might have the opportunity to actually solve this.

If it does, honestly, to hell with anything else. I'm sure over time the web
world will gravitate towards a fairly common set of widgets that will, at one
point or another be standardized. We'll reinvent UI frameworks under a
different name, except this time they'll be running under the ultimate cross-
platform framework.

~~~
rolleiflex
I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a
low defect rate. That’s 6 different binaries. I’m a solo founder.

I know people like to rag on Electron, but without it, I wouldn’t be using
something else, my apps just _wouldn’t exist_. It allows more people to try
building more thing and that is a net positive.

The speed problems and bloat issues of Electron is just shoddy programming on
the maker’s part - Electron itself isn’t slow. I use it largely as a shell
talking to a Go binary that ships within the app package, which makes it only
tasked with UI. If you’re having issues with speed, it’s a good approach.

A real world example of this approach is the thing I work on at
[https://aether.app](https://aether.app). (An async collaboration tool for
engineers)

~~~
dewey
For me, and probably others, the main issue with Electron isn't the speed or
even resource usage. It's that it ignores common UX/UI conventions you expect
from a native app which still makes me prefer native macOS apps.

~~~
m_fayer
I think this peaked some time around 2015. Back then, I remember many
developers getting up in arms about following Apple's guidelines to a T, or
insisting that Android apps look like a hyperactive stack of colorful paper
cutouts under a direct light.

Since then, I think many of us have gotten tired of looking at overdesigned
sameness that by now we all know will age quickly. Programmers no longer see
the sense in chasing a perpetually changing visual standard for no reason
other than "BigCo said so". Most importantly though, BigCos in question have
fallen out of our good graces, and the "Design Systems" they keep pushing are
now regarded as nothing but cynical branding exercises that come at the cost
of UX.

~~~
pookeh
You are right but at the same time I am willing to bet you 5 years later
someone else will make the opposite argument and be upvoted the same.

It's a pendulum.

~~~
nicoburns
I'd bet on the next UI standard being a cross-platform library. Electron-like,
but with much more efficient stack, and with binding to multiple languages.

~~~
m_fayer
I'd bet on "if you can't beat em', join em". Reactive component-based
architectures a la React/Vue have won. The DOM has won for the view layer too.
And with wasm, you get your bindings to multiple languages. See: Blazor (it's
just the first, more are coming). As for desktop apps that could benefit from
proper concurrency, lack of a browser sandbox, full system access, etc. -
server side Blazor is quietly pioneering a weird new paradigm - essentially
running a headless browser in a regular process with full privileges, and then
only doing vdom diffing inside the browser.

~~~
nicoburns
> The DOM has won for the view layer too

As a front-end dev, I'm not entirely sure I agree with that. The DOM has some
annoying performance limitations, and I'd love to be able to use something
better for rendering. I think what the DOM has shown, is that cross-platform
and the ability to easily do custom look and feel are crucial.

------
headcanon
Every time Electron is mentioned I bust out the popcorn for the inevitable
hate spewed towards it:

"Javascript is a terrible language and no one should use it"

"Separate instances of chrome for every app is dumb and consumes too much
memory"

"Qt is amazing and elegant and desktop-native. Why isn't everyone just using
Qt?"

~~~
Hendrikto
> "Separate instances of chrome for every app is dumb and consumes too much
> memory"

That one is true though. Different Electron apps could at least share the
runtime.

~~~
paulryanrogers
Except they cannot, Chromium (or is it Blink?) changes too frequently to
reliably code for one version and expect backward compatibility of future
releases. Electron versions could be shared libraries... except again BC
breaking releases proliferate.

~~~
hanniabu
Why can't it be based of Chrome's version number? If you know the version
number at the time of release then you can say only use the same runtime if
there's only a revision version difference, else you can use it's own run
time. That packaged with auto-updates for the app to that developers can push
updated builds every month or so should be fine.

------
Razengan
Since this is inevitably going to generate some discussion over native apps
vs. Electron (ah there's already a fellow comment about it), I'd like to point
out an example that is important to me of why Electron is an inferior
experience for users:

In the GitHub Desktop client, which is an Electron app, I can't spell check my
commit messages, something that every text field in every native macOS app
gets for free.

~~~
_bxg1
Web text fields should also support that functionality, so it may be a
question of GitHub breaking/disabling it in some way.

~~~
Razengan
You're right; I just tested it in Discord, which does have a spell checker,
and it _seems_ to use the system dictionary (but it seems one way when
teaching it new words), but it's still missing other global text field
functionality:
[https://i.imgur.com/qpOU9dz.png](https://i.imgur.com/qpOU9dz.png)

The point remains: Electron apps generally lose many of the features that the
host OS gives native apps for free.

~~~
_bxg1
But the native web, used properly, includes many of them itself. Things like
accessibility, metadata, etc. You only really lose features if you're
circumventing native web functionality.

~~~
johnisgood
The problem is that the developers of Electron apps explicitly disable those
features. Why?

~~~
_bxg1
Sometimes web developers will circumvent core HTML features because they don't
do everything they want and aren't extensible enough, although this is
generally considered bad practice if it's at all avoidable. Sometimes they
just don't bother to write semantic HTML even when they could. But the
platform itself has the infrastructure; it's possible to write bad software on
any platform.

------
choeger
Hey, another electron thread. Wait a second, did someone already mention how
horrible Javascript is? The memory consumption? The minimal integration into
the OS/desktop (think accessibility)? Hmm ok, I need something new...

Here it comes: chrome is inherently instable. The Google developers give a
shit about their dependency management and have trillions of open source
projects just literally copied into their trunk. They also don't provide any
API to speak of, chromium as a library does not exist, and don't get me
started about the arcane build process of chrome.

~~~
marshallofsound
Disclaimer: Electron dev

So few quick things, the projects that are copied are done so to guarantee
deterministic builds in an isolated build environment (no dependencies on
third party systems).

The API you say they don't provide is literally the API that Electron uses.
-->
[https://chromium.googlesource.com/chromium/src/+/HEAD/conten...](https://chromium.googlesource.com/chromium/src/+/HEAD/content/public/README.md)

And as for the build process, eh, it's kinda slow but it's hardly arcane. On
linux you can run like 4 commands and it'll build Chromeium.

~~~
choeger
Yeah. Four commands. The first one downloads binaries from the internet. If I
was inclined to do so, I would not need to build in the first place ;).

Give it a try with the current HEAD of their home-grown and undocumented build
tool and see how far you get.

And regarding the deterministic builds: I call bullshit. They just don't want
to follow the different packaging guidelines from the different operating
systems, so they repackage everything. Now I have to trust them to keep all
these dependencies up-to-date _and_ I have to accept the unecessary bloat? No
way.

~~~
snek
> [build process]

I agree, the chromium build tooling is unfriendly af.

> I call bullshit

Lot of works goes into deterministic builds, have fun going down this rabbit
hole:
[https://bugs.chromium.org/p/chromium/issues/detail?id=314403](https://bugs.chromium.org/p/chromium/issues/detail?id=314403)

> Now I have to trust them to keep all these dependencies up-to-date

Looks like it rolls on average every 10-20 minutes:
[https://chromium.googlesource.com/chromium/src/+log/HEAD/DEP...](https://chromium.googlesource.com/chromium/src/+log/HEAD/DEPS)

> and I have to accept the unecessary bloat?

Ah yes, because all operating systems ship with a pristine installation of the
latest pdfium.

~~~
choeger
> Lot of works goes into deterministic builds

That has _nothing_ to do with their dependency management. In fact, if you
link against system libraries, it should be simpler to get deterministic
builds, as you have to build less.

------
ethanpil
A lot of the bloat complaints about Electron are addressed well in Sciter
([https://sciter.com/](https://sciter.com/)) although, Sciter has its own set
of limitations. I have found Sciter a great option for many use cases. (I'm
not affiliated with Sciter in any way).

~~~
adev_
Sciter and Ultralight are the way to go on paper. They address many of the
issues of Electron and it does it in a very portable way. Instead of embedding
the world in a giant toolkit, they give to you what you want as a library,
easy to interface with native code.

However they are proprietary, and this is a no go for me and many. There is no
way I bind my software stack to an arbitrary unstable compiler ABI and its
platforms. Nor I will bet on a toolkit that can disappear tomorrow if its only
maintainer disappears or get hit by a bus.

We need something like these projects, but OSS and still I would be happy to
pay for that.

~~~
ethanpil
Ohh, never heard of Ultralight. Will check it out, thanks! I agree that
licensing makes these products an issue for some, but they both seem to offer
a very flexible free use option...

------
millstone
There's hate directed at performance, but Electron apps are just _profoundly
buggy_.

For example in Slack:

1\. Non-functional items are routinely offered in the main menu and context
menu.

2\. The Undo and Redo menu items often just don't work. These do different
things than the command key equivalents which should never happen.

3\. It is easy to get into a state with multiple blinking insertion points.

4\. The inactive appearance is identical to the active appearance.

etc etc.

~~~
scrollaway
None of these are innate to Electron. It's kinda like saying "Windows apps are
just profoundly buggy", or "Telephone calls are just profoundly boring".

------
mangosherbet
Is there a good introduction to starting development with Electron as someone
who is a C++ developer? I find web development quite difficult to grok in
general; lots of frameworks and technologies.

~~~
crispinb
Quelle horreur - clearly web tech is the future of UI, and electron is a
reasonable choice until a better solution comes along, but the ecosystem is a
foul mess for developers. `npm [anything]` fills your hard drive with an
astronomical tangle of hideous code. And there's webpack. You will end up
wanting to strangle yourself. Avoid unless you really need it.

~~~
alyandon
I'm normally a backend developer but I was fooling around with using vue.js +
jquery to build a simple SPA without the typical process of npm install
<entire world>.

When it came time to finally bundle my app into a single html + js file I
settled on (well was forced to really) npm install rollup. After installing
rollup, I had a package-lock.json file that was 1880 lines long with
approximately 150 or so dependencies and a node_modules directory so huge that
vscode choked trying to parse everything in it. To its credit, vscode asked me
if I wanted to exclude node_modules from future consideration.

All that from installing a single tool via npm. I just don't get modern web
development.

------
eicossa
Wait ... let me see if I can anticipate the top comment

"Electron consumes so many resources ... Why so resource hungry ... My
workstation already runs Chrome, can't have electron apps bogging it down ...
Slack runs on Electron ... VSCode is the only good Electron app ... Why are we
doing this ... Dennis Ritchie would be turning in his grave"

This topic could honestly trigger the "parse regex with html" kind of reply.

~~~
windsurfer
Well, Slack _is_ currently taking almost 3 GB of memory on my machine. Not
entirely sure if that's due to Electron or Slack, but I have never found an
Electron app that didn't consume vast swathes of memory.

[https://imgur.com/GscRFD7.png](https://imgur.com/GscRFD7.png)

~~~
maxbrunsfeld
It is not because of Electron.

An empty Atom window containing 5 source code files consumes about 120MB of
RAM. For comparison with native apps, an empty iTerm2 window uses 100MB, and
so does an empty Notes.app window. The base memory footprint imposed by
Chromium is not that significant.

~~~
windsurfer
On my machine, an empty Atom instance is using about 400 MB:
[https://imgur.com/S1POSPz.jpg](https://imgur.com/S1POSPz.jpg)

~~~
maxbrunsfeld
Do you have some packages installed? If so, can you re-run with `atom --safe`?

Granted, it is totally normal to have packages when using Atom, but their
memory cost shouldn't be considered a penalty that you pay due to Electron.
Rather, it's a penalty that you pay if you want an extensible application in
which extensions are allowed to use JavaScript.

~~~
windsurfer
I have no custom packages installed - I use atom just to take notes and do
small text editing.

When I run `atom --safe` it starts at around the same amount of memory usage:
[https://imgur.com/j4Co4n6.png](https://imgur.com/j4Co4n6.png)

Side note: Running that command is now preventing my from quitting Atom using
the Atom > Quit menu entry. I had to force quit it to get it to close.

------
jszymborski
I love HTML/JS as a desktop UI toolkit, but much prefer the approach Qt
WebView approach where javascript callbacks hook directly to code as opposed
to running an entire webserver/HTTP stack. If not for the performance, for the
ability to skip the sort of security problems the Signal desktop app had run
into at some point.

------
bnjmn
Does anyone know why they chose Node.js 12.8.1 instead of 12.13.0, the first
LTS release on the 12.x line?

------
brylie
Is there ongoing work to reduce the memory footprint of Electron apps? I'm
genuinely curious.

~~~
YesIndeedSir
Yes - WebAssembly. It would hopefully kill the whole thing as an end game.

~~~
brylie
I have a, probably misguided, fear that We Assembly will inadvertently usher
in an era of read only web, basically breaking the "view source" idea almost
unique to the Web.

~~~
laichzeit0
I hate to break it to you, but minification has broken this idea for years
already.

------
semireg
Electron 4 is end of life so that means many native node modules need a ton of
rework to support node 10+. This is a pain point for electron app devs that
rely on native modules for functionality. Time to roll up my C++ sleeves and
spend weeks adding zero new features ... just trying to get my apps to build.
Ugh. Any native node module gurus for hire? Totally serious here. App is
[https://label.live](https://label.live)

------
chrisrickard
I dig Electron, and had always assumed by now we would have a multi-OS CSS
toolkit for "native looking" styles. I remember
[http://photonkit.com](http://photonkit.com) from back in the day, but I think
there is room for something more comprehensive.

------
feross
Duplicate:
[https://news.ycombinator.com/item?id=21338362](https://news.ycombinator.com/item?id=21338362)

------
z3t4
Electron (and also nw.js) are nice. But remember that when using a Electron
app you are no longer sandboxed.

------
The_rationalist
As in every election threads, people will say "duh each electron has it's own
instance of chromium" While you can trivially use solutions such as
[https://github.com/sentialx/electron-
global](https://github.com/sentialx/electron-global) To fixe the issue.
Moreover, Carlo solve this too. Ionic and Cordova (the electrons of the
smartphones) already use locally installed browser.

