
Electron 2.0.0 beta - l2dy
https://electronjs.org/releases#2.0.0-beta.1
======
thiht
As much as HN hates Electron, it's probably one of the best things to happen
on desktop, especially on linux desktop ironically.

It works, it's beautiful, it's easy to use, and unlike many people here, I
believe the HTML/CSS/TypeScript/React is rock solid and the closest thing to
THE solution to the UI problem.

~~~
yoz-y
The problem I see with Electron (and probably one of the reasons HN hates it)
is that it leverages the advances in chip making to work as well as an app
from 20 years ago, but is multi platform.

It is a huge productivity boost for programmers at the expense of making
computers slow. On my work computer I am used to run many apps, and with each
Electron app added I feel it slowing down. (latest one to switch was Skype for
me). What is the point of having such powerful computers when they feel like
slugs crawling through a bog?

~~~
beojan
> It is a huge productivity boost for programmers at the expense of making
> computers slow.

It's a productivity boost for web developers, who don't have to learn a new
language, and for companies that can hire cheap web developers instead of more
expensive desktop developers. It's not a productivity boost for someone who
knows (or is willing to learn) .NET or Qt.

~~~
laurent123456
Users benefit from it too since the alternative to Electron often is not .NET
or Qt but no app at all, especially on Linux.

~~~
swiley
I would rather run something in wine or run nothing at all than have to run an
electron app. It's that bad.

~~~
h1d
How bad is it to run Electron apps on Linux?

~~~
pizzapill
Slack uses ~ 2 GB of Ram and ~ 10% CPU when idle. I used it for a short while
but now I'm just leaving a Slack tab open in my browser. Its exactly the same
functionality-wise.

Basically I'm fine with Electron apps but I have yet to find one that I need
and can't be replaced by a browser tab.

~~~
calcifer
On my laptop running Slack Linux 3.0.5 with 3 workspaces & several dozen
channels, it idles at 0% CPU and ~550MB RAM (see screenshot [1]).

[1] [https://i.imgur.com/juQbGW7.png](https://i.imgur.com/juQbGW7.png)

~~~
oselhn
Comparing it to similar native app like pidgin it is still about 10 times
more.

~~~
calcifer
With 10 times the features, it’s not at all unreasonable.

------
anticnstrctv
Does anyone else feel that there's a huge hole in the UI world?

I like the electron/react/react native ecosystem - I really do, and this is
coming from someone who dislikes javascript a priori. But is HTML/CSS/JS
really the best we can do for desktop and mobile applications? I know
responsive-cross platform saves money for a lot of startups and orgs, and I'm
not saying the web stack doesn't have it's place.

I frequently imagine something that takes the best ideas from react/redux and
from other ui and layout frameworks and lets you build something that has
consistent, cross platform (desktop and mobile, maybe even web with some kind
of compilation pathway to js or webasm), responsive ui, without the huge web
stack. Maybe Python? It's got lots of competent developers in the market to
support it. Maybe Rust or Go, if something lower-level was desired. Or
language-agnostic, though sticking with one might be valuable.

~~~
kodablah
Yes, I think we all feel it. Every UI lib has something wrong: C++ sucks and
is hard to iface w/ other langs (Qt, wxWidgets), not enough widgets (IUP,
libui), not native enough in my OS (GTK), carries a full browser (Electron,
nw.js), carries a full JVM (JavaFX, Swing), etc, etc. And then every subreddit
and community always has people asking what's the best UI lib for language X.
We all travel back to awesome-lang-X lists' GUI section every so often hoping
someone will finally fix it.

Qt or wxWidgets, make a supported C iface (I am aware of some work on both
fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken
your libs (libui guy just got permission from his new company to get back
working on the lib, yay). World, don't hate non-native-OS-widgeted apps.
Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-
embeddable, or must-be-multiprocess shit. And let us trim some fat off at
compile time please (waiting on you Servo, but please stay lean and single-
process for embeddability). JVM AOT...we're waiting, we know it's coming.

And no, I would rather not have an interpreted (or dynamic) language if I can
help it.

Edit: To clarify before a ton of responses pick apart my specific criticisms,
I'm making these points to show there is a void. I could poke a ton more holes
in these libs and more (I have used most), but it's hardly worth arguing the
nuances here.

~~~
barrongineer
With Java 9 jigsaw and jlink you can now build fairly light JavaFX apps. The
entire jre no longer has to be bundled. Only the pieces you're using.

~~~
floatboth
Unfortunately JavaFX still does not support Wayland, just like most Java GUI
things (except for SWT which seems to have some support
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=516841](https://bugs.eclipse.org/bugs/show_bug.cgi?id=516841))

~~~
pjmlp
Given the progress of Wayland's adoption, I don't see it as a major issue.

------
pier25
Sadly the biggest problems with Electron are not yet solved:

1) There is no way to separate the Electron engine from your app, so you have
to bundle Chrome and Node with each app.

2) Electron has an autoUpdater API, but since Electron doesn't solve the
installation/updates problem e2e (packager + installer + updates server) it's
really a half baked solution. This is specially bad in Windows since Squirrel
for Windows is in my experience a disaster.

I have a number of Electron apps in production, internally and for our
customers, and for our next desktop project we won't be using Electron.

The idea of using web technologies for the UI is still very valid IMO, but
considering the 2 previous problems it's way less of a headache to just make
our own native wrapper in C# and Swift (sorry Linux) and finally distribute
the app via the official stores. At least for our use case.

~~~
dugmartin
Sadly all of this was solved years ago with Adobe Air (single engine, real
automated updates, plus a more sane Javascript syntax with AS3). I haven't
used it in years but I just took a quick look and the last release was today -
[https://labs.adobe.com/downloads/air.html](https://labs.adobe.com/downloads/air.html)

I know there is a lot of Flash hate out there but Air+Flex(+FlashDevelop) was
a pretty nice solution for building , debugging and distributing cross
platform apps.

~~~
pier25
I was a Flash dev for years, and then kept on doing Adobe Air apps for museums
and mobile. Adobe dropped the ball on it pretty quick once HTML5 went
mainstream. New features and bug fixes take ages.

I still think AS3 is one of the best languages I've ever used. It was really
ahead of its time.

~~~
zwetan
"New features and bug fixes take ages."

ORLY?

It has been many years that Adobe AIR is updated on a quarterly basis, every
March, June, September and December

[https://www.adobe.com/devnet/articles/flashplayer-air-
featur...](https://www.adobe.com/devnet/articles/flashplayer-air-feature-
list.html)

~~~
pier25
So?

Major features are the ones that matter. It took Adobe like 3-4 years to bring
concurrency to iOS. AS4 was killed after years of promises. Etc.

------
Aelius
I agree with all the complaints about electron performance, but the thing that
really gets me is how horribly developers fail at responsive design, with a
toolset that is probably the most suited for responsive design since
terminals.

How the hell do slack, discord, and gitter STILL not collapse their sidebars
when you resize the containing window to be tall and narrow? It makes them
unusable in a tiling WM, and it's generally disrespectful of screen real
estate in any WM.

This is the price of easily accessible development. We're doomed to relive
past mistakes in UI, as new developers are blissfully unaware of lessons
learned by existing frameworks.

Many people here are saying electron is popular because of a lack of sane,
consistent toolkits across each OS. There's also security to think of too.
Electron is likely very insecure relative to native software, but the
responsibility is purely on the electron devs: freeing the app developer of
that burdon. Electron rose in an environment with no competition in that
regard. But now, Windows has UWP, and Mac has their own app platform. I
sincerely hope we see these more universally leveraged, such that developers
will stop abusing the web for app development.

And I guess Linux will just have to make a WINE for UWP, I can't imagine the
Linux community coming together to create something like that for themselves.

~~~
kroltan
> And I guess Linux will just have to make a WINE for UWP

I might be wrong, but isn't that literally Snap Packages?

[https://www.ubuntu.com/desktop/snappy](https://www.ubuntu.com/desktop/snappy)

------
dvfjsdhgfv
It's really sad that in spite of the main glaring problem of Electron apps
they didn't as much as even mention any work done on performance optimization
in 2.0.0. The changes mentioned are just make up when compared to the real
problem.

~~~
nukeop
What do you find lacking in Electron's performance? Compared to all competing
UI frameworks it isn't really any different, except it allows for faster and
easier development and deployment.

~~~
adolfojp
It wastes tons of memory.

~~~
nukeop
I don't think 100-150MB is a "ton",and I don't think it's "wasted". It's
actually as much as a single tab of a browser. If it takes much more, it's not
Electron's fault, it's the program's developer's - memory leaks are not
uncommon in javascript SPAs.

~~~
dvfjsdhgfv
First of all, it's not 100-150. If it stopped at that, nobody would even care
to mention this huge problem. What you get in real life is something like 800
MB for memory alone, and CPU usage can be similarly high. There are legitimate
reasons to use that much resources, just not by the GUI.

Really, it's as if all this fundamental computer science, O(n), finding the
shortest path, all these efforts in optimization that we do at universities -
as if all this just went down the drain and the moment you leave the CS
department you say, "Ah, screw all this, I'll just allocate all I can, just in
case". This is just so wasteful and it really makes me sad that so few people
care.

~~~
nukeop
A browser (or Electron) does not allocate as much memory as it can on a whim,
every byte of that memory is used to bring you features, caching, and so on.
What program have you seen that takes 800 MB of memory? And why would a modern
GUI program not utilise memory if it's available and it's free in order to
cache data, requests, build an in-memory database, and so on? Browser
programming is a lot more than finding the shortest path in a graph. It's
commonplace to have 4-10GB of free memory at any given time and it should be
utilised if it's available instead of being wasted by being unused.

~~~
dvfjsdhgfv
> It's commonplace to have 4-10GB of free memory at any given time and it
> should be utilised if it's available instead of being wasted by being
> unused.

I'm not sure when this became the new normal, but I was taught the exact
opposite. How about trying to squeeze that into 200 MB rather than allocating
4-10 GB just because it happens to be available at that moment?

~~~
nukeop
For some purposes, you can't "squeeze that into 200 MB", especially for
caching. If you have memory that's lying around empty, what is the point of
having it at all if it's wasted 99% of the time? Is it a virtue in itself to
under-utilize resources you have available?

Is it good if a company employs a 100 people but only 15 of them do work and
the rest is idle?

~~~
dvfjsdhgfv
First of all, yes you can, even easily - provided that you use a different GUI
toolkit. 200 MB is a huge amount of memory anyway, in many cases you can do
much better. Electron fans like to talk about caching, but really, that's a
browser issue, it has nothing to do with GUIs, at least not with traditional
ones. Why should you need to cache any GUI elements if you can (re)create a
thousand dialogs in a blink of an eye? Maybe you can cache the _data_ in those
windows, but that's a completely different thing, and the memory used is
usually some orders of magnitude lower.

Now, as for using all available memory: that's exactly the reasoning that
causes so much problems for users, and that's why after so many years of
hardware upgrades our machines still feel sluggish: using all resources for
_your_ app, only because they happen to be free at that moment, is _not_ OK.

First of all, they are free now, but they might not be a moment later (because
another brilliant app author has the same idea and tries to allocate
everything). Second, the resources should be used in a reasonable way. If a
piece software doing extremely simple computation is suddenly allocating a few
gigs of RAM and takes over all cores, my thought isn't "Oh, what an efficient
app, it's using all these resources I don't need", but I wonder what went
wrong! What is perfectly OK for, say, a 3D rendering node, is completely wrong
for an app that could do the same thing with 10x lower resource usage.

I'm not sure if I am able to explain it in more clear terms.

~~~
nukeop
So you're saying increased resource usage is ok for node, but did you know
that node is exactly what electron is running on? 200 MB of memory is nothing
for a GUI app - and most Electron apps don't even take 100. They need that
memory for all these amazing features the framework offers, like running
javascript, processing css stylesheets, async execution, etc.

~~~
dvfjsdhgfv
No, by "3D rendering node" I don't mean Node.js but a node (like in a cluster)
of a 3D rendering engine.

------
vbsteven
I wonder if it would be possible to change the electron build process so it
builds 2 outputs: 1 "big" package with full Chrome inside and 1 "light"
package that just contains the application code.

The light package could then be offered as an alternative download on the
website to run on a specific "electron-runner" that can run multiple electron
apps side by side.

I know that I just described a regular browser with tabs or windows but hey,
Electron is what we have right now and it is not going away soon. This might
be a solution for people running multiple Electron apps side by side.

~~~
nukeop
If you don't need the APIs that interact with the local system, you can
already build for Electron and for the browser easily. If you need those APIs,
however, there's no other possibility because of the browser sandbox.

~~~
NoGravitas
It's possible to have a native (node?) app for the local side, which talks to
a browser extension. This way you don't have to run multiple instances of the
browser runtime. There's someone writing a full-featured, Patchwork-like SSB
client in Firefox this way, but unfortunately I can't remember the name.

------
FreezerburnV
Since it’s something I’ve been paying attention to for a while: this (beta,
sure, but soon to be full. Probably would work fine for doing some dev work)
release of Electron finally bundles the version of Chrome that implemented
SharedArrayBuffer support. This means that developers can now spawn web
workers (real parallelism) and communicate with them much faster than
previously with message passing. So there could be some big wins for things
like developing games in Electron since you’ll be able to do some big number
crunching off the UI “thread” and hand the results back to the UI with little
performance penalty. (Especially if there are a lot of results, such as a
theoretical fully-updated scene graph worth of matrices in an array) Hooray
for less jank on the renderer!

~~~
ihsw2
Notably, `SharedArrayBuffer` was disabled (starting Jan 5 2018) due to
Spectre.

Nevertheless, it is going to be re-enabled so it is worth reading up on shared
memory in JavaScript -- more to the point, Atomics.

[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Atomics)

I know a lot of people scoff at the Node/browser runtimes, which is warranted
and totally unrelated to the language known as _JavaScript_ , but performance
is improving.

~~~
FreezerburnV
Is it disabled in the version of Chrome shipping with Electron? Considering
they’re usually some number of versions behind, and this is a tool to make a
desktop app, it would seem to be desirable to have it enabled regardless of
Spectre since a desktop app can own your computer anyway if it wants. (It does
make sense to have it disabled in a general purpose browser until mitigation’s
are in place)

------
mherrmann
People not satisfied with Electron's performance might be interested in fbs
[1]. It makes it very easy to create desktop apps with Python and Qt. It was
in the #1 spot here two weeks ago [2]. (I'm the author.)

[1]: [https://github.com/mherrmann/fbs](https://github.com/mherrmann/fbs)

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

------
greenhouse_gas
What would be interacting is an electron like environment with a pared down
JS/CSS engine which only let "modern JS/CSS" (maybe something like Servo). It
can be optimized for that, and you don't really have to render electron apps
from the 90s anyways.

Another idea is that when wasm will be able to interface with DOM, you'd be
able to write GUI code in any language which compiles to wasm. So you won't
_need_ Rust (or Go, or Haskell, or D, or your up and coming toy language)
bindings for win32, Qt, GTK, etc. Just waste a few hundred megs (only
partially /s) and you've got a full ui.

~~~
jbergens
MS seems to be on the way to support PWA directly in Win 10. If other systems
would do this as well we won't have to ship a full runtime like Electron.

[https://blogs.windows.com/msedgedev/2018/02/06/welcoming-
pro...](https://blogs.windows.com/msedgedev/2018/02/06/welcoming-progressive-
web-apps-edge-windows-10/)

------
refulgentis
What happened here?

"macOS Changed a macOS thing. #123

Windows Changed a Windows thing. #123"

~~~
dspillett
The #123 is a link. Click that for the ticket with more information.

Though looking at it, the actual description is no longer than "changed an X
thing".

~~~
davej
That issue was 4 years ago. #123 looks like placeholder text.

------
tradedash
We have been using Electron for [https://tradedash.io](https://tradedash.io)
(our crypto currency trading platform) for some time now. There are some minor
issues with the platform itself but there are a lot of good things too.

The JS ecosystem as a whole needs to improve but as far as Electron goes, I
must say that I am pleasantly surprised with how well it has been doing even
though we are handling data from multiple exchanges at a rate that is not so
trivial.

~~~
disiplus
why is this a "native" app and not just a new tab in chrome ?

------
eklavya
You can use React and js to build native desktop apps without electron today.
Use [https://proton-native.js.org/](https://proton-native.js.org/) (based on
libui).

~~~
plopz
While that is certainly a promising library to watch for in the future, I
wouldn't say its ready to go today. Its based on libui which is in alpha and
was stagnant for quite awhile. The developer just recently (this week) started
working on it again so there is potential.

------
0XAFFE
I wonder why there is no runtime package for all your electron applications,
so you only have to install the runtime once and every app can depend on this
runtime. This would greatly reduce download sizes of individual applications.

~~~
Drakim
I assume because it would defeat the intention of electron, since the entire
point is to "magically" make your webapp into a standalone application with no
dependencies. Just download and start it up, like any application.

Whether this is wise is another question.

~~~
greglindahl
... and with this sort of magic, I expect that all of the applications that I
download are going to have completely different versions of all of the
dependencies, so, ... there's no sharing anyway.

------
swiley
Just a reminder to everyone who says there's no way to write cross platform
apps:

TCL/TK is still a thing and MacOSX still ships with wish, it even runs on
android. The one platform you can't use it for is the iPhone.

~~~
lmm
If you're willing to not support the iphone you have plenty of good options.
Unfortunately for many people iphone is a requirement.

------
wodenokoto
What is the stack behind RStudio? It isn't electron, but it is an HTML app,
run by a browser (safari on my macbook pro, wonder if it is IE on windows)

It doesn't feel as heavy as electron apps.

------
billfruit
I have only a very cursory look at Electron, but I find two things
problematic: Lack of support for legacy systems, and the complicated build
process of apps built with Electron, most can't successfully build unless you
download a ton of stuff from npm. The kind of place where I am with many many
older machines, never connected to the internet, Electron hardly makes any
sense.

------
ericfrederich
Never really heard of Electron before I tried using KeyBase on Windows. It
seems electron is the reason that it doesn't work on my machine.

Ran into this last night. [https://github.com/keybase/keybase-
issues/issues/2813](https://github.com/keybase/keybase-issues/issues/2813)

------
samwillis
Does anyone know if there has been any work on bringing the work from
“headless chrome” to electron?

It would be awesome to be able to use the full node.js environment with a
headless browser natively.(headless chrome with puppeteer is good but electron
would be better)

------
dcgudeman
Why not upgrade to the most recent version of chromium? (64 instead of 61)

~~~
samwillis
Because it takes longer than the chromium release cycle to do an
electron/chromium upgrade. I think they only tend to do the upgrade a few
times a year. Chrome 61 will have been current when they started the upgrade
process.

------
paxys
Nothing in this seems worthy of a major version bump to be honest.

~~~
l2dy
See [https://electronjs.org/blog/electron-2-semantic-
boogaloo](https://electronjs.org/blog/electron-2-semantic-boogaloo).

As of version 2.0.0, Electron will strictly adhere to Semantic Versioning.

Major Version Increments

* Chromium version updates

* Node.js major version updates

* Electron breaking API changes

~~~
jbergens
Sounds a bit like angular and we might get electron 3 and 4 very soon if they
feel a need to update Chromium or Node.

------
ohthehugemanate
Can anyone explain for me: WHY is electron such a resource hog? Is it just
because chrome is a resource hog? Could it be trivially re-engineered to wrap
quantum instead?

------
darklajid
Waiting eagerly for VS Code to upgrade. As far as I understand, this fixes the
"precision touchpad" bug on Windows..

------
ed_blackburn
How long before the Electron APIs are aped by OS extensions and managed more
effectively than Blink?

------
twtw
Is Electron still single threaded like Node?

------
_o_
With all the GUI crap going on in software development, I am starting to miss
MFC and BCG libraries, I know it is not feasable for most developers to code
in c++ but at that time the GUI, even if run over RDP, was fast, responsive,
now I having a feeling like 386 was faster than todays i7+. And to cirmuvent
obvious incapability of RAD to provide decent user expirience, they are
changing our UI percepction from trendy perspective, leveling everything to
flat and extremly simple, like ncurses on graphical desktop. =/

------
nkkollaw
One thing I don't understand about Electron is, why not share a single Chrome
process (or if anything one per Chrome version if needed)

