
Electron 6.0 - fnordsensei
https://electronjs.org/blog/electron-6-0
======
rvz
It's kind of interesting to see this release and previous ones mention
'performance fixes' (V8 and Blink does all the work) that it brings, yet the
job postings for desktop software engineer requiring Electron experience also
put data structure and algorithms and what I see here is a runtime that is
very expensive in both space + time complexity. It makes no difference in
using a different language with a faster runtime to combat this.

Imagine if I were to write a 'next-gen' CAD program or an alternative 3D
modeling program in Electron. I'm not so sure if the manufacturing or the
games industry would take a second look at that. But in our industry, it is
seen as normal for our text editors, ide's, git clients and video editing
software and our messaging clients to be expensive in memory and cpu time.

Can't we do better than this? Or do we have to accept and depend on Google to
create our desktop software?

~~~
sbergot
Imagine reading the sentence: "Imagine spacex building a rocket with cheap
plastic. Why us working in the disposable fork industry are still using this
crap material!". And then you realize that this comment gathers a lot of
support from the disposable forks engineering community.

Time to deliver new features matters. Skill reusability matters. This is the
economic reality that makes electron attractive to all the people that decide
to use it to build software.

The alternative to electron is not always a leaner different framework. It may
also be not building software because you don't have the resources and skills
needed.

~~~
kgraves
That might be the case economically, but this isn't the future that I or end
users want, look where this has gotten modern desktop development, you now
have sluggish, slow, bloated applications vying for end user's resources.

e.g. An end user using Discord and Slack has to download 2 Electron
applications (~500MB of disk space) and this is for a chat app, Ripcord [0]
can do both with less RAM resources and disk space.

> The alternative to electron is not always a leaner different framework.

You can have both, there are newer frameworks popping up such as Flutter,
React Native and Reason Native.

[0] [https://cancel.fm/ripcord/](https://cancel.fm/ripcord/)

~~~
jwblackwell
Who really cares about 500mb on a laptop?

~~~
majewsky
There is a world beyond people who throw their notebook into the trash after 3
years. There are still plenty of users with 128 GB or even 64 GB. Now imagine
Windows taking 30 GB out of these 64 before you even start installing any
apps. Those people absolutely care about 500 MB.

~~~
hoffs
This is such bullshit, who the hell runs 64gbs of hdd. Budget laptops 6-8years
ago already shipped with at least 300gb hdds.

~~~
9HZZRfNlpR
Plenty of laptops were released with small SSD's thou, probably still are.

------
wongarsu
> Per our support policy, 3.x.y has reached end of life.

3.0.0 was released 10 months ago. If the current frequency of releases stays
constant any version reaches end of life after about 9 months.

~~~
NullPrefix
Electron does not have a LTS branch ?

~~~
wongarsu
They support the last three major releases, and that's it. So right now that's
6.x.y, 5.x.y and 4.x.y. A new major release is released about every 3 months.

To quote the official stance: "If an application has exceptional circumstances
and needs to stay on an unsupported series of Electron, developers can silence
the end-of-support warning by omitting the final release from the app's
package.json" [0]

[0] [https://electronjs.org/docs/tutorial/support#supported-
versi...](https://electronjs.org/docs/tutorial/support#supported-versions)

~~~
imtringued
Considering how electron applications are deployed "exceptional circumstances"
covers every single electron app in existence.

------
rado
Appreciating the contrast with the 512-byte OS posted today.

~~~
mothsonasloth
Its a valid point, the average computer in the Western world is at least 4GB.

However when I was in South Africa a few years back they were still running
with XP and < 2GB RAM with HDDs that I saw in a school and hotel.

Ok, hardware components are cheaper and easier to come by but we shouldn't
stop caring about system resource usage.

~~~
iamnotacrook
If they're using old PCs running deprecated versions of Windows then they long
ago stopped caring about resource usage and efficiency (energy usage and
operator time) and are instead optimising for hardware cost. It's no reason to
favour this or that platform for development.

~~~
clappski
> instead optimising for hardware cost

I imagine a big reason that they're on old hardware is cost - just because
it's relatively cheap for someone in the West to get a decent modern machine
at a reasonable cost doesn't mean that it's the same everywhere, especially
when there's big disparities in the purchasing power of the native currency
vs. the sellers/manufactures currency. It's not so much an optimization, I
imagine most users on legacy hardware don't choose to be, it's more likely
that they can't afford more modern hardware or it isn't available for them to
purchase.

Another huge reason for users to stay with older operating systems (especially
in business and government) is dependencies on legacy software - if an
organization relies on software that has never been updated after Windows
95/XP and doesn't function on later versions then they're going to be stuck
using legacy machine configurations until the process can be changed to
something else.

> stopped caring about resource usage and efficiency (energy usage and
> operator time)

How do you know that they don't care about how efficiently they can use a
machine for whatever they're doing? It's a baseless assumption.

Even if your user percent that's stuck using older hardware/operating systems
is in the single digits, that isn't an excuse to ignore their requirements
IMO. Doing so is a sign of sloppy engineering, akin to designing a new mode of
public transport, for example, that doesn't cater for disabled people.

------
polote
Every time I hear about Electron, I have mixed feeling about it, is it :

* one the best thing that happened to desktop software as it enable web developers to build desktop portable app

* one of the worst thing that happened, because it makes the desktop world rely on Google and decrease even more the expectations on how much resources an app should consume

What are your opinions ?

~~~
rimliu
Imagine if desktop developer wanted to go into web development. I assume he
would learn HTML, CSS, JS. Why cannot web developers wanting to create desktop
app learn new languages and SDKs? I've spent many years as a web developer,
and a bit fewer years as iOS developer. Now I am back with web again, but I
still thing way too much of the recent trends are being optimized for the
developers at the cost of users.

~~~
zazaraka
Microsoft has a zillion native SDK developers. Recently they replaced their
native Visual Studio installer with an Electron based one.

That should tell you something.

~~~
lawnchair_larry
That isn’t how big companies work. The decision about what to use is up to the
5 or so developers working on an app. Microsoft doesn’t force specific
languages or frameworks across all of their devs, and the native SDK devs are
working on their own projects.

------
aorth
No mention of Wayland support, which means that desktop applications like
Skype and Signal will continue to have a poor user experience on GNU/Linux
unless you use Xorg. Using these applications with fractional scaling in
Wayland is a bit rough—I guess we are waiting for Google to land patches
upstream of Electron in Chromium?

~~~
snazz
Have you noticed any issues with XWayland aside from the DPI scaling? I find
it pretty seamless on a standard-DPI (or a little higher) monitor.

------
interfixus
I once drove a huge refrigeration truck across Australia. The full cooling
system was running all the way, although storage was howlingly empty, save for
twenty liters of drinking water, kept there because the fridge in the driver's
cabin had broken down.

Electron always reminds me of that trip.

~~~
ktpsns
I love that analogy. The fridge in the driver's cabin is a web widget in a
traditional toolkit, for instance [https://doc.qt.io/qt-5/qtwebengine-
webenginewidgets-markdown...](https://doc.qt.io/qt-5/qtwebengine-
webenginewidgets-markdowneditor-example.html) The large cooling system which
requires a substantial amount of fuel is Electron.

------
mosselman
It is totally me, seeing as how many electron projects there are, but I have
never been able to make anything with it. Not even a POC, I have found it very
complex.

~~~
luismedel
I don't think it's very complex. Only look at the target users! :-)

Jokes aside, lack of basic code protection (aside of script minimization
and/or obfuscation) it's that prevents me from using Electron/Atom/whatever. I
know anyone could decompile a C# application easily, but I find the javascript
case worst.

Do you know any commercial applications using any of these solutions? (I'm
speaking of shareware / paid software, not "Whatsapp desktop" type)

~~~
mceachen
PhotoStructure for Desktop runs on macOS, Windows 10, and Ubuntu Desktop, is
packaged with Electron (I'm alpha testing 6.0.0 today), and will be
commercially licensed when the closed beta ends.

I'm also preparing a PhotoStructure for Servers build that is electron-less,
and uses either docker or snap (it's how I run it on my NAS). I'm looking for
more beta testers for this headless build, if you're interested.

[https://blog.photostructure.com/introducing-
photostructure/](https://blog.photostructure.com/introducing-photostructure/)
has more background and signup information.

Disclaimer: I'm the author.

~~~
luismedel
Thank you. How do you cope with the code being visible inside the application
drectory?

About PhotoSctructure: \- Great application idea, sincerely. My photo library
is a big mess and this sounds super handy. \- May I recommend another icon? I
find strange that PhotoStructure "for Desktop" has a cloud in it's icon :-) \-
Regarding being a tester, thank you, but my current file server is a _very_
stripped down debian box right now (Fujitsu Futro S900).

:-)

~~~
mceachen
The cloud bit is because it's going to support dweb/multi-user sharing (added
in a version coming Any Day Now).

I'm testing it on an rpi 4, so if you've got ~> 2gb ram, it should run.

~~~
luismedel
Awesome. Please, tell me how can I help at "luis at my-username-here dot com".

Thank you!

------
fohara
I'm surprised Kivy [0] doesn't get more attention for desktop app development.
Apps are developed in Python, it's cross-platform and MIT licensed. Running
the hello world example uses just ~2.5% cpu and ~57mb memory on a 2015 mbp.

[0] [https://github.com/kivy/kivy](https://github.com/kivy/kivy)

------
mothsonasloth
It seems like you have three choices at the moment for desktop development
(for non .NET) that I am aware of.

* C++ and GTK or other UI framework : hard but excellent performance.

* Java and Swing UI framework : easier but less performant.

* Javascript and Electron : easy but terrible performance.

Which one will prevail?

~~~
Crinus
Lazarus is easier than the first two by far and you get self-contained native
executables (no runtime requirements or extra DLLs, at least on Windows),
native widgets (on Linux you can choose between Gtk and Qt, though the latter
does need a "bridge" .so), very low memory consumption (think a handful of MBs
for a very simple application and memory requirements do not grow much outside
of your own use - to give a ballpark, i just opened Lazarus itself with a
simple program and the task manager reports just 36MB of RAM use for the
entire IDE) and very good performance.

From the development side you get WYSIWYG UI editing, an IDE that has deep
understanding of the code and updates it "live" as you make modifications to
the UI (and other "managed" components), very fast compilation times, a very
mature and rich framework (which is also very stable as the developers almost
never break backwards compatibility meaning your code will compile for years
to come) and recently the IDE got an online package manager and installer
(repositories existed for years but they were manual to install).

Also the entire IDE can run and be usable even on a first generation Raspberry
Pi (though for comfort, especially with the UI designer, it is a better to use
something slightly faster).

The negative side is that as it relies on native widgets, it is much harder to
create custom themes. Though there are themeable controls available
(especially if you are not against paying for them as there are a few
companies selling commercial components for Lazarus). Personally i prefer
native controls anyway.

~~~
rafaelvasco
Yeah Lazarus is really a RAD environment. Unfortunately I don't like Pascal
nor Modern Pascal that much. My holy grail is something of the same quality
but using C# which, for me, is the superior language by far.

~~~
Crinus
What do miss from C# compared to Free Pascal? Outside of something like LINQ
and lambdas i can't think of any other major difference between the two
languages (and lambdas are WIP, i think they already work in the trunk), what
do you have in mind?

------
waldsonpatricio
One library that is trying to be the mid-term between native performance and
ease of use is Revery[1].

[1] [https://www.outrunlabs.com/revery/](https://www.outrunlabs.com/revery/)

------
ksec
Hopefully with Apple's Catalyst, there wouldn't be a single Electron Apps ( Ok
apart from VSCode ) on my MBP.

If you want iOS or iPadOS, you need to be Native. And you can now port it to
Mac with ease.

The days company ship crappy Desktop software with Electron needs to come to
an End.

------
daliusd
Almost two years ago I have created app (using Electron) that takes xlxs
template and data files and generates bunch of xlsx files [1]. It was Electron
1.7.8 and now it is 6.0.0. I guess I need to check it out again.

[1] For curious: [https://github.com/daliusd/xlsx-
generator](https://github.com/daliusd/xlsx-generator)

~~~
simlevesque
You should add a screenshot in the readme.

~~~
daliusd
Thank you. Done.

------
dirkg
Its always the same complaints about Electron's size/runtime.

Try to build a desktop app using a native language/UI framework of your choice
(C#/Java/C++ with whatever fancy UI libs you want) which will even come close
to the power or HTML+CSS - hint, you can't. Just trying to implement the
layout/cascading behaviors, never mind all the stuff on top, would take
forever.

Next add the fact that you can get true cross platform apps with a single code
base in reality, not the pseudo lies promised by ReactNative or the even more
ridiculous RN on Web, or new pretenders like Flutter.

Electron isn't being used for tiny utilities - its used for apps like
Slack/VSCode which really do need to run on multiple platforms and have the
exact same UI/UX, which is simply impossible even if you dedicate 3 dedicated
teams at 3-5x the cost.

Why don't people complain about how bloated browsers are? Electron is simply
V8+Node bundled for desktop use.

~~~
z3t4
If you statically link the ui lib - the binary can become quite large too.
Another option is to make a web app and use "add to desktop".

------
wlesieutre
Not mentioned in the release notes, but if I'm not mistaken this update adds
support for Touch ID. I thought that was coming in 5 but it looks like it
didn't.

[https://github.com/electron/electron/pull/16707#issuecomment...](https://github.com/electron/electron/pull/16707#issuecomment-506392471)

Welcome to 2016, electron apps!

This should help BitWarden be a more competitive alternative to 1Password for
Mac users.

------
gpsx
I feel embarrassed to ask such an obvious question, but what would it take to
_not_ download electron with every app? I assume the main drawback to doing
this is having the correct version. This isn't a big problem for web browsers.

~~~
edflsafoiewq
Arch packages the Electron runtime separately from apps.
[https://wiki.archlinux.org/index.php/Electron_package_guidel...](https://wiki.archlinux.org/index.php/Electron_package_guidelines)

------
rafaelvasco
It seems to me that the short term solution for the runtime overhead is to
have the core runtime running in the background and the applications running
decoupled from it on top. Is there any reasonable mature project going this
way ?

------
Epskampie
Can anybody explain why electron includes all off

* chromium

* node.js

* v8 ?

To my understanding chromium includes V8, and node.js is built on top of it.

~~~
truth_seeker
ElectronJS Application Architecture -
[https://electronjs.org/docs/tutorial/application-
architectur...](https://electronjs.org/docs/tutorial/application-architecture)

------
gingabriska
Can anyone suggest a software niche where Electron has not be used so far?

Here is one I think: 3D printer slicer, to my knowledge there is no slicer
which uses electron I think it limits the contributers who can quickly deploy
plugins in JavaScript

~~~
nickexyz
For slicers there is [https://pathio.xyz](https://pathio.xyz). Not fully
Electron though, which is probably a good thing..

Edit: [https://pathio.xyz/hello-world](https://pathio.xyz/hello-world) "Pathio
is built on a mixture of modern web-technology (Electron) and a powerful
native slicing engine (written in C++17)"

------
Robin_f
Great, another release not supported by Spectron so you can't actually write
tests for it.

------
ausjke
Electron is the true and only available cross-platform desktop build
environment these days, it actually makes business sense for many. All
alternatives(Qt, whatever) come out short in my opinion.

The major complain of course is its memory/disk space.

I don't see how that's going to be resolved soon even though RAM/Disk is cheap
these days, maybe a smaller js engine, or maybe replacing nodejs with
something lighter(e.g. golang backend).

Another approach is to run a local daemon(e.g. one go binary) that does all
the backend operations(filesystem, network,etc), while use browser as your UI.

~~~
megous
That will not help much. V8/node is not that big. The big part is chromium.

~~~
ausjke
slack desktop is 60MB zipped. after unzip it's 205MB while slack binary itself
takes 115MB, indeed node_modules only took 8MB,

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

