
Essential Electron - kawera
http://jlord.us/essential-electron/
======
gldalmaso
I don't see it being discussed much when Electron comes up, so I'll share some
of the use cases that led our company to move at least one of our web apps to
Electron.

We provide a B2B service that relies on communication with a locally installed
service running on the users machine. This kind of approach is one that has
been heavily bombarded with new features and deprecations leaning towards a
more secure web by most browser vendors, which is actually very justifiable.

The most recent one was Chrome targeting to restrict app cache usage, which we
rely on currently, only to documents served through HTTPS. Given that we have
an app that uses a local service that needs to work offline, we cannot use
HTTPS for that without messing with stuff that needs Administrator privileges,
which we really want to avoid because headaches.

So we figured we need a more flexible approach that is not so restricted as a
web app living on the browser, but we already have a product. Here comes
Electron, and in a couple weeks work, mostly testing things, we have it. We
now deploy both to the web (just in case) and are rolling customers to the
desktop.

Other features that added a lot of value where:

\- No localStorage limit, was starting to become an issue, now we have
breathing room to migrate to other storage

\- Auto Update, actually took care a long time complaint for the necessity to
keep downloading new versions of the local running server, which we now
package alongside the app

\- node process running directly on the client opens up a lot of new
possibilities

------
mhd
Remember when people used to complain about minor desktop UI inconsistencies
like submenu activation, button frames and default icons? Thanks to years
getting people accustomed to the usability nightmare that is the web, this
doesn't seem to be an issue anymore.

~~~
oblio
Meh.

After all, the dominant OS before mobile was Windows. Remember Winamp skins?
Skins for every possible app on the face of the Earth? Opening up Skype, which
had its own theming, Yahoo Messenger, which had its own theming, Office 2003,
which had its own theming, etc., etc., etc.

Except for Mac OS fans, most of the world didn't really care.

~~~
mhd
I remember quite a lot of complaints about those Office changes, or different
styles that came from using Borland C++, Delphi or even cross-platform tools.
If you were doing commercial development, that mattered. End users don't
exactly complain about specifics, they just ditched your program because it
was "odd".

Let's not even mention Unix.

But yeah, Mac OS users were particularly obnoxious there, as usual.

~~~
sime2009
> End users don't exactly complain about specifics, they just ditched your
> program because it was "odd".

Except that they don't. If that were true then we would see a lot more
consistency in desktop app styles.

The typical desktop computer experience hasn't been visually consistent since
the mid 90's. Most young people have never used a computer where most of the
apps had the same style.

------
sktrdie
What would be interesting to reduce the memory footprint is to split Chromium
and only include stuff you actually need in your app. For instance, Chromium
comes with backwards-compatibility code for websites of the 90s (that use
tables and old CSS). Perhaps there can be a stripped down version that only
supports HTML5. Even cooler would be to simply just include in the final
package _only_ the things you're using. So if I don't need localStorage, I
don't include it in my app.

~~~
CGamesPlay
I've investigated this lightly. The bulk of the weight of electron is actually
in the media stuff. Dropping video support would reduce the storage footprint
by around 50%.

------
bananaoomarang
There has to be a more efficient way of writing cross-platform code than
bundling Chrome and NodeJS with your app.

~~~
derefr
What I'm really confused about is why Electron is set up such that each app
ships the whole runtime, rather than there being something like the JRE or CLR
(or Silverlight, or Adobe Air, or...) where each app that wants to use it,
prompts for its installation.

Better yet, why not make the architecture into a single shared "Electron
windowing server" process that all Electron apps run "on", such that I don't
end up running 7 different copies of Chrome?

(Honestly, Chrome itself could have become said runtime with its packaged
apps, plus the (only ever experimental) standalone App Launcher install mode.
I guess that's not the path they wanted to go down.)

~~~
FooBarWidget
That approach is not without downsides. It requires strong compatibility
guarantees and version management. That's not easy to achieve.

And traditionally, management of such shared runtimes on anything but Linux
sucks a lot. Remember all those Windows apps that tell you "Java Runtime
Environment 1.5 required" and then they kind of leave you to figure out how to
install that? Not exactly user-friendly.

And at the end of the day, regardless of your OS, you end up with 4-5
different JRE versions installed because compatibility is not perfect, so each
app locks down to a specific version instead of accepting a newer JRE.

.NET isn't any better. I have 5-6 different .NET runtime versions installed
and I can't remove any of them because each app requires a different version.

The method of vendoring all your dependencies may not be the most efficient,
but it's certainly the most convenient one. It seems users these days care
more about how much hassle it is to install than how long the download takes
or how much RAM it uses.

~~~
pdkl95
> That approach is not without downsides. It requires strong compatibility
> guarantees and version management.

Static linking the runtime also has significant downsides. One of the worst is
how it puts the burden of pushing runtime security updates on the app.
Frequent JRE downloads because of security patches is annoying, but
downloading N copies of chrome every for all of your apps is insane.

Of course, this also requires that each app _update_ itself to be compatible
with the new versions every time there is a security patch. The entire point
of including a specific version of chrome is to avoid these updates, so the
very idea of Electron implies the app is not designed for security.

------
marcosscriven
I've been very impressed with the few Electron apps I've seen out in the wild.
Obviously the main one is Atom (as I believe this is what gave rise to
Electron). But others include Kitematic and VS Code, the latter of which
convinced me such an approach could produce a smooth UI.

Generally, I find the way these apps look very attractive, much more so than
any other cross-platform apps I've seen before (Swing, AWT, QT etc).

While I agree the download size is less than ideal, I can't argue against it
being a good compromise at the moment.

~~~
jakobegger
Atom is a pretty neat editor as long as you are only using it on small files.

Try opening a 20MB SQL Dump. Fortunately, Atom will show a warning. If you
click past that, everything will freeze while Atom eats up more than a
Gigabyte of memory. Don't turn on syntax highlighting, or Atom will lock up
and eat all your CPU.

When you are done listening to your computer's fan, quit Atom. Then kill the
"Atom Helper" process, which for some reason keeps on eating CPU even after
you quit Atom.

Now open the same file in BBEdit, or any other native Text Editor... and the
file will open instantly, the app will be responsive, and syntax highlighting
will work, because 20MB really isn't a file size that should be an issue for a
text editor.

~~~
tjalex
I've tested opening a few ~15MB log files (no syntax highlighting) with VS
Code and Atom... I'm amazed that one editor will load within 2-3s and the
other will take 15s (or more!) when they are both built on Electron.

------
rmason
Electron is potentially a game changing product but very little thought has
been given to a smooth on boarding process.

I have had very little problems with the actual coding part, but installing,
especially on Windows, and updating for new versions is voodoo. Every time I
think I have it all figured out it breaks.

~~~
wyqydsyq
I can't speak for Windows but on both OSX and Linux, upgrading Electron
versions is as simple as upgrading the version number of the `electron-
prebuilt` dependency of your project and running `npm update`. You can also
use the `npm-check-updates` package to upgrade to the latest version
automatically.

~~~
rmason
Interesting that you mention npm-check because that was recommended to me. The
web page explaining it looked fabulous and I thought it would solve all my
problems.

But running it took six hours and it crashed. Found online somewhere that it
can't handle the size of electron, too many nested directories I guess.

Tried just updating and it appears to have worked, but now everything crashes
and the error message isn't very helpful.

~~~
wyqydsyq
If you just jumped up some major versions it's likely that you've upgraded to
a version with breaking API changes. I'd suggest reading the changelogs
between your old and new versions.

Assuming you're using the prebuilt version (which you should be unless you're
hacking on Electron itself) there shouldn't be any issues upgrading - it just
downloads the latest prebuilt binary, there really aren't many files.

------
k__
I know a few people who did Qt wrappers for their websites and sold them as
native apps, because some big enterprises only installed old IE versions.

Installing a new browser wasn't allowed, but installing these wrappers that
prevented the use of any other website and most other browser features, was
okay.

With Electron this is even easier.

Also the "Web-Platform" can now do most of the things others can do too.

90% of all things people want to do with apps (mobile or desktop) is already
possible with a web-app. If you need more, you can do a browser extension or
an Electron app.

------
Furincer
Thank you for having a readable font size and thank you for actually
explaining ideas in ways that the layperson can learn from. We need more of
this, not elitist jargon that is all too common.

~~~
strictnein
Yeah, I really liked this format as well. Simple language and easy to read.
Wish there were more articles out there like this.

------
Ezhik
Well, I do need to put my 16GB of RAM to good use.

~~~
creshal
It's not _that_ bad, depending on what you're doing inside of it. My password
manager clocks in at ~150 MiB RAM usage with a few thousand passwords. Could
be better, but it's not as bad as, say, Mozilla products written in XUL.

~~~
Narishma
A password manager shouldn't even need a tenth of that.

~~~
creshal
Realistically? 15 MiB is going to be hard in any desktop GUI toolkit I know.
Something around 50 MiB is more what I'd consider feasible.

~~~
pdkl95
"a tenth" of "~150 MiB" is a reasonable approximation:

    
    
        $ ps -p $(pgrep keepassx) -o rss=
        22844

------
okket
A decade ago you would have been shot for suggesting to run every (web-)app in
this own 50MB+ browser environment/jail.

Times are a-changing and memory is cheap these days.

~~~
creshal
A decade ago Mozilla's XUL-based HTML+JS interfaces, and the programs built in
it – Firefox and Thunderbird – were all the rage.

~~~
NeutronBoy
And the concept of 'web apps' barely existed.

------
therockhead
I can understand why small teams with a web background might pick Electron
instead of going native but I don't understand why the larger companies like
Slack don't write a native app when they have the resources to hire the
talent.

~~~
nkozyra
What advantage would that introduce? Slack seems to work just fine on each
available OS. Being able to write once in JavaScript/CSS/HTML seems a lot more
appealing than writing and testing three apps separately, regardless of your
company size.

~~~
therockhead
1) Native L&F 2) More responsive UI 3) Lower memory footprint

As a dev I'm biased of course and this might not matter to most people. One
thing though, you don't have to write the full app three times. For example
all the business logic can be in C++ and write a native UI on top of it.

~~~
nkozyra
I think it _might_ matter to non-devs but the tradeoff has to be pretty
compelling and in Slack's case I don't see it. Like, there's still dev work
happening to make these apps, so it's not like you're shutting out a whole
group just because it's a web stack and not C++.

------
dsincl12
The font size is way too big on that page.

~~~
reitoei
If only there was some way to make it smaller.

------
jblow
"Typically, desktop applications for each operating system are written in
each's native language. That can mean having three teams writing three
versions of your app. Electron enables you to write your app once and with web
languages."

I stopped reading there. If you have total ignorance of how native
applications work, maybe fill that hole before trying to evangelize that
everything should be written in JS...

------
rv11
Well, you are getting cross platform almost for free. It is a pain with other
such frameworks.

Spotify, steam , brackets use these kind of tech, and I personally like them.
somehow I find them fast, more stable( probably due to chromes multiprocess
architecture).

~~~
rtpg
Agreed. Main issue is everyone's downloading Electron over and over to run the
apps. Would be nice to have an EVM or something so that Slack could just be
the ~1 meg or so of actual app-dependent code.

~~~
kozak
Windows 10 (actually, 8+, but never mind) has its own platform for "native"
HTML apps. One more abstraction layer, and your app can run both there and in
Electron.

------
srikz
Very nice introduction with relevant links. However, I feel the 'Think of it
like this' section is strictly for MacOS (and Linux?) users as it doesn't
behave that way in Windows and can confuse the reader.

------
toomanybeersies
What's the key differences between Electron and Chromium Embedded Framework?

~~~
tretiy3
It is nodejs vs c++. Also, everything works out of the box in Electron case.
In CEF, instead you have to study examples and dive into Win32 API/GTK/cocoa
samples to find out how to run and extend basic "hello world".

------
Hurtak
Does anybody have experience with both Electron and nwjs? How do they compare?

~~~
cjbprime
Electron seems to have more mindshare, nwjs has some nice features like the
ability to open multiple windows from the same renderer thread. In Electron,
each window you open has its own renderer thread with no JS state shared
between windows.

------
y0ghur7_xxx
Electron is really awesome. I wrote a rest client¹ a few weeks ago for my
personal use, and it worked out really well. I saw that even the auto update²
use case is taken care of.

Really awesome to make a quick app for someone who is already good in making
webapps and needs the power/access/network rights of a desktop app.

¹[https://github.com/S2-/http-client](https://github.com/S2-/http-client)

²[https://github.com/electron/electron/blob/master/docs/api/au...](https://github.com/electron/electron/blob/master/docs/api/auto-
updater.md)

------
131hn
I like electron very much, yet, how come i'm feeling to be the only one to
like & miss the nw.js mixed context mode ? This is so much more confortable
...

------
GoToRO
Do you also get a website? given that you program using JS + HTML + CSS.

~~~
deejbee
You can spin up a http server from the Main process (we do spin up websockets
on our app) if you need to, and if you're writing a single page app using
angular for example then you can just specify the .html page using loadURL()

------
0x006A
Whats the security update plan for Electron?

~~~
cjbprime
There's an Electron auto-updater module, and an example update server
implementation, so you just push updates (of any kind, including security
updates that fix Electron itself) to your users (supports Windows and macOS)
using that.

~~~
pdkl95
That only works if the apps are compatible with future releases of Chrome. If
that was acceptable, there would be no reason to bundle a specific version of
the runtime with each app. As several people in this thread have already
pointed out, apps break between versions; this implies that the "security
update plan" in practice will be to ignore security updates.

~~~
cjbprime
I'm so confused.

The app author controls the update channel. At their own pace, they'll bump up
their Electron dependency to a newer version and make sure their app is still
compatible with the latest Electron. When they're ready to release that new
combination of app and Electron, they can push out the new version to everyone
as an auto-update.

Where does Chrome come into it? Who will be ignoring security updates?

~~~
pdkl95
Consider the next time there is a serious vulnerability in Chrome. Maybe it's
a TLS problem and network requests cannot be authenticated. Maybe it's a
buffer overflow in something that renders data from a remote source. Chrome
needs to be updated to a newer version immediately.

Is _every_ app author going to push out an update that includes the latest
Chrome with the relevant security fixes? Or are they going to irresponsibly
leave the vulnerability unpatched until their app is updated to support the
new version of Chrome?

The very idea of using _old_ versions of Chrome (via Electron) - which is the
stated reason for bundling Chrome with each app - tautologically means at
least some apps will be using vulnerable versions of Chrome.

> At their own pace

That's the point; browser bugs don't happen at the _app author 's_ pace.

~~~
cjbprime
Jeez, I guess. In practice the Electron authors would presumably issue point
releases for critical security vulnerabilities. If so, this is no different
from shipping OpenSSL with your app and needing to get an update out for that.

