
In response to “Electron is flash for the desktop” - nbrempel
https://rempel.world/posts/electron.html
======
Animats
Flash was much better than Electron. The Macromedia Flash run-time was modest
in size. Originally it was under 1MB. It wasn't intended as a container system
for video; it just had the ability to use video as an animation object. It had
a good approach for displaying animations, and could start playing well before
the entire file was loaded. Electron is bloatware by comparison, and it's
mostly a kluge on top of the DOM.

Here's a good Flash animation. Fits in 1.9MB.[1] Enjoy. Flash had excellent
authoring tools aimed at animators. Try doing that in Electron. Electron is
from people who are still stuck at the command line and try to do graphics by
writing code.

[1]
[http://vitenka.com/users/ChanCats/penelope_pitstop_gt.swf](http://vitenka.com/users/ChanCats/penelope_pitstop_gt.swf)

~~~
johnfn
> Flash had excellent authoring tools aimed at animators.

Electron has excellent authoring tools aimed at web developers. Namely, the
ones they are already using.

That's kinda the whole point. :)

I don't disagree with you. The Flash authoring tools WERE amazing.

When I'm feeling in a trolling mood, I tell people that Flash is still ahead
of JS and HTML5. Not only was the IDE incredible, but AS3 was literally a
typed version of JavaScript with XML liberals. That's right, it had the best
from JavaScript, TypeScript and JSX, 10 years before any of that existed in
the front end web development toolkit.

And you guys hate on Flash! :)

~~~
coldtea
> _Electron has excellent authoring tools aimed at web developers. Namely, the
> ones they are already using._

You must have a very different definition of excellence if you believe that
the current web authoring tools (whatever IDE or editor + plugins people use)
are in any way close to "excellent".

~~~
derefr
What would you expect web development to be like? I mean, holding static the
requirements that the resultant DOM has to:

1\. reflow when resized (unlike a PDF);

2\. work with screen-readers (unlike naive custom rendering engines in games
et al);

3\. work with accessibility-enabling UA stylesheets (unlike native UI
toolkits);

4\. be printable without a separately-authored for-print version;

5\. if stateful, uses idiomatic HTTP request/response cycles that enable
network-level HTTP caching;

5\. if a web-app, talks to a simple mostly-stateless HTTP API that can also be
consumed unchanged by API client libraries.

There is a reason that Dreamweaver and Publisher are separate apps; and there
is a reason Rails/Phoenix/etc. don't support server-side stateful controls
like Seaside or the IBM 3270 terminal protocol do. The web is its own thing,
and as long as the web _is the thing we 're targeting_, the authoring tools we
have are likely about as good as we're gonna get.

(Unless, that is, you can teach your devs to think in terms of distributed
actor systems, where all your Javascript code assumes any actor could be
remote like in an Erlang system. Then we _could_ have our UI builders and
transparently server-ize them too. But would anyone put up with it?)

~~~
candiodari
How about the paradigm that was in use for, oh, 3-4 decades, before the web ?

The general idea:

    
    
      void OnPaint(PaintCommands p, Rect limitToRect)
    

You can finally sort-of do this, with RequestAnimationFrame and Canvas
maximized, and it is indeed way faster than HTML, at least, on my desktop. It
resizes if that's what you do inside of it. For games this is pretty much
mandatory.

It still sucks in many ways though. More could be achieved with just directly
exposing OnPaint, 2d and 3d versions. Plus various basic things, like copy-
paste, don't work.

It doesn't satisfy half your demands, I realize that (though windows
accessibility can be quite good too, and the web's accessibility sucks badly).
But I would argue that having actual complex apps was worth more (compare MS
Office to Office 360 or Google Docs, or worse, compare things like Corel Draw
or Lucidchart to the Lucidchart web app, or any other HTML5 drawing/charting
app).

And let's just not talk about Desktop Games versus either web games or even
phone games. It's depressing.

~~~
majewsky
Have fun fulfilling any sort of accessibility requirements with this.

------
endergen
I'v been experimenting with trying to make a smaller Electron like Javascript
application wrapper. It's called Shrinkray, and only adds 60K of overhead to
the size of the app. See:
[https://github.com/francoislaberge/shrinkray](https://github.com/francoislaberge/shrinkray)

It is macOS only (for now). I haven't measured if it is more performant when
in the background, but I will. It'seems certainly way smaller in disk size,
but comes with tradeoffs in API/functionality.

~~~
kodablah
I really liked the concept for this[0] project last year. I now do a similar
thing and all of my need-browser-abilities-on-the-desktop projects just
require you also have Chrome installed and I just use "chrome --app". I also
get security updates for free! I think it's much more reasonable to run a
localhost-only web server and use a browser on the desktop than requiring the
browser embed native capabilities directly from JS source (and if you really
needed that, you could build some fast IPC). You just need to make sure you
sign/auth all of your localhost calls w/ a rotating key to (admittedly only
somewhat) prevent other process accessing your webserver. Or someone could
just make a chrome plugin that does direct IPC to your backend and no web
server needed.

I think the problem is everyone is trying to match the Electron API and the
multi-process/IPC hoops. If they would just build it like a localhost-only
webapp, they'd get so many benefits including the small app size.

0 - [https://github.com/utamaro/neje-ui](https://github.com/utamaro/neje-ui)

~~~
endergen
Shrinkwrap is basically a local server that hosts a folder of static
html/css/js content that is served through an app that is just a full window
WebView element.

You could use a similar trick of wrapping go code, but instead of assuming
Chrome is installed, just host your front end using the native webview.
Requires no other installation than your app that way.

------
lobster_johnson
We actually already had "Flash for the desktop". It was called Adobe Flex
(originally Macromedia Flex, and today Apache Flex), and it was... not half
bad, actually.

It was based on Adobe AIR, a cross-platform VM that used ActionScript as the
language, which at the time looked a lot like what ES2015 is today -- Adobe
basically tried to make ActionScript the same as "ES 4.0", an effort to add
classes, properties and private/public visibility to JavaScript that was
eventually abandoned in favour of smaller improvements in what became ES5,
then ES2015. Flex/AIR had a pretty rich UI framework with semi-native widgets
and access to the OS.

It was unfortunately heavily based on declaring your UI with XML, and apps
tended to look like "AIR apps", much like Swing apps look a bit off and non-
native.

~~~
blub
Balsamiq Mockups is built with Flex/AIR. It's quite decent, but a bit
sluggish.

------
awinder
Can we talk about the other red headed stepchild of desktop dev which is java
cross platform apps? It'll take a lot to get me off my high horse that if all
that was ported to electron, it'd be a great upgrade for users.

It's also a bridge for Linux desktop to get critical, same-in-class app
support. Not a final destination but a possible breakpoint infusion.

~~~
diek
So, like IntelliJ? We should port IntelliJ to Electron?

~~~
rlabrecque
I mean we already have VSCode and Atom both running on Electron.

~~~
awinder
I had tons of memory problems on webstorm, basically romping through 4GB+, it
was taxing my 16GB laptop at times. Switching to vscode has been a huge
resource saver.

~~~
tommica
I have the opposite issue - PHPStorm works fine, but VS Code and Atom are
completely sluggish even on simple PHP files

------
ogezi
I completely agree with this. Electron drops the entry barrier for desktop
development much like flash did for web development.

As computers get faster I think that the difference in performance of apps
using electron versus platform native apps will be imperceptible.

~~~
harrygeez
I would much rather see React Native succeed than Electron.

~~~
pier25
I would much rather see a native to JS bridge completely decoupled from React.

------
DonFizachi
"With Electron, we’re seeing a similar explosion of new desktop software. The
lower barrier to entry into creating cross platform desktop software far
outweighs the detriment of computer resource usage. A good friend of mine is
able to launch and grow a business solo in part because of this low barrier."

Until something better comes along I’d have to agree that Electron is the only
way to assure that a developer’s audience are first class citizens regardless
of the platform on which the developer’s application is deployed.

In my case, my app ran on an embedded web server and the UI was rendered by
Electron. When ever I make changes the app code, I simply run scripts to
create installation files for Windows, Mac and Linux (deb). This is done in
minutes. What other platform would allow achieve something similar?

------
revelation
Where did this "drops the barrier to entry" myth even come from?

There is nothing easy about having to make your desktop UI in HTML+CSS and
dealing with the cumbersome "browser JS" and "nodejs in background" divide.

~~~
pinneycolton
It's a great question. I think it drops the barrier for individuals who don't
want to spend time learning other languages or concepts. What's a Dispatcher
and why is it important for the UI? Some of these developers may never need to
answer that question -- and that may not be a terrible thing.

Things that allow people to do more with their existing skill set, even if
it's not the most efficient, are generally good. They support organic growth
of platforms, creativity, and exploration of things that were previously out
of reach for some individuals. They can certainly become unmaintainable and
problematic, but if the app's usage grows to a point where those are important
problems to solve, they will get solved. Or they won't and they'll become a
limiting factor in the usefulness of the application.

Evolution is a fantastic thing ;)

------
mnm1
I think Electron apps are much more similar to desktop JVM apps than Flash
(not in tech but in pros and cons). Both Electron and JVM apps are absolutely
huge distributions and resource drains, the main criticism of both. They have
the same goals and serve the same function. You might conclude that this is
just another criticism of Electron, but it's not. I run multiple desktop JVM
apps still (Jetbrains stuff). Far from ideal on resources or startup time,
they generally do the job and are cross platform. I'll take that over the
alternative: these apps not existing or not being cross platform.

~~~
pikzen
>JVM apps are a huge resource drain

Aside from the fact that you don't redistribute the entire JRE with every Java
app.

Or the fact that their UI toolkits are not horribly hacked together messes,
and actually manage to hit 60fps.

Electron apps are a regression from Java apps. And HotSpot is a little wonder
of performance, unlike V8

~~~
mnm1
Sadly, these apps do contain their own JREs. The memory footprint is hundreds
of megs and they take half a minute to start. Just like Electron apps. I don't
deny the tech under the hood (JVM) is wonderful, but the comparison to
Electron apps is apt.

------
b123400
I've worked with companies making apps with electron/nw.js, what strike me
most was not the performance or the product itself, but the reason they
decided to use electron. The argument is always about development efficiency,
while ignoring the user experience sacrificed. I find it lack of
craftsmanship, just kind of sad.

Though, it is true that nontechnical users are unlikely to realise the
difference, they probably don't know an app with not many functionality costs
hundred megabytes. Maybe I am just getting old and grumpy, maybe that's how
assembly programmers see C programmers.

------
Avshalom
Wait, where is this explosion of new desktop applications?

Also isn't it only a lower barrier if you already know html/css/js

~~~
jacquesc
I'm currently using these Electron Apps every day: Slack, Nylas, VSCode,
Insomonia, Freeter, Mongobooster

On a 2015 macbook pro with 16GB of RAM.

The buggiest and most resource intensive apps I use tend to be the native ones
(iTunes, Dropbox, BusyCal, Evernote).

~~~
x0x0
Slack on the desktop is a hunk of garbage. Sign in to even 3 slacks and it
will eat almost a gig of ram and 5% CPU to... display v2014 irc chat. They
really should be ashamed of themselves. I have to remember to kill it whenever
I'm on battery.

~~~
Tijdreiziger
I've been quite happy with Rambox, an app that aims to unify all your
messaging services into one desktop app. Ironically, it's also built with
Electron, but right now, it's sitting at 30MB RAM and 0,1% CPU with 3 Slacks,
WhatsApp, (FB) Messenger and Discord loaded.

[http://rambox.pro/](http://rambox.pro/)

~~~
mercer
Have you ever used Franz? If so, is Rambox better, in your opinion? Franz
doesn't seem to be much better in RAM than a browser, but I can't imagine what
Rambox does to improve that.

~~~
Tijdreiziger
I haven't used Franz, because it's not open-source. I actually found Rambox
after hearing about Franz and searching for an open-source alternative.

Both Rambox and (as I understand it) Franz just load the web interfaces of the
services you configure, so performance wouldn't be better than Chromium, since
that's what Electron uses. The added value is in the wrapper, which helps to
keep everything organized, lets you open and close all services at once (by
opening/closing Rambox), and provides a global 'do not disturb' mode for
notifications.

------
neilalexander
If anything, the problem with Electron is that it takes the wrong approach to
lowering the entry barrier to application development. Rather than forcing
developers to come up with more user-friendly programming languages and UI
toolkits, Electron takes the easy way out and bends HTML and JavaScript into a
hugely overweight kludge to accomplish things it was never really designed
for.

The result? Fat applications that take up lots of resources, poor user
experience that doesn't match the native look-and-feel of the OS, and a huge
surface for problems or security vulnerabilities. (Just the other day I was
tweeting to the developer of an Electron app when I discovered that their
simple chat app was linking to CoreMIDI on macOS - what exactly for?!)

I still recoil a little bit when I look at the DOM of the average Electron
application, because it's horrendous and scary and HTML _still_ is not the
correct tool for the job, no matter how much people try.

I'm glad that it is inspiring people to create, but in doing so we're teaching
new developers bad practice.

~~~
zer0tonin
>(Just the other day I was tweeting to the developer of an Electron app when I
discovered that their simple chat app was linking to CoreMIDI on macOS - what
exactly for?!)

Probable because Chrome does it and the developer has no control over this.

~~~
neilalexander
Yes, that's exactly what it is, and that's exactly the problem. This model
teaches people to just "trust" that Chrome is right and it teaches people not
to optimise.

------
jorvi
'Some' bloat.

Not to ham on the guy personally but someone posted his new cross-platform app
on HN that put an icon in the systray/menubar and built it on Electron. The
end result was something that should take up a few mb of memory at most
consuming over 300Mb(!) of memory. That's simply ludicrous.

------
coldtea
If only the main browser devs could sit and design something that mixes the
best of Flash and HTML:

    
    
      - text/document presentation (with advanced typography -- css3 is still crap)
      - embedded hw accelerated bitmap canvases (for when you need total control)
      - vector based main drawing (hw accelerated)
     - styling language (that doesn't cascade by default)
      - embeddable/loadable fonts
      - richer set of form controls (e.g. at least sliders, date/time pickers, etc)
      - compact, compressed delivery
      - ability to pry content open (no opaque blobs)
      - video/audio playing
      - a JS-without-the-BS (like an "enhanced strict-mode")
      - a high level control (widget) description language (XAML, JSX style)
      - self-contained custom widgets
      - overridable built-in widgets (form controls)
      - a sensible layout system (grid style), that doesn't assume everything starts as a text-based document.
    

and no legacy DOM stuff, no SVG crap, no CSS, etc.

Instead of all the BS work in asm.js, Dart, the nth W3C standard, etc and
kludges on top of kludges, they could have something up and running in a
couple of years, and push it to their evergreen browser new releases.

Have Google and Bing penalize websites stuck in legacy HTML and most of the
web give way to this new hotness in 10 years or so -- and the rest run in
legacy-mode in stricter sandboxes.

------
saosebastiao
Why isn't it possible to dynamically link to the browser engine and js
runtime? Isn't that the whole point of dynamic linking?

~~~
Const-me
Technically possible.

The main problem, people developing apps on top of that framework will have to
deal with compatibility issues across various browsers and their versions.

On Windows (including mobiles), the only embeddable browser is Internet
Explorer.

On OSX, iOS and Androids since 4.4, it’s different versions of Blink.

Electron solves this problem by redistributing a specific version of the
browser, this way the app no longer depends on the OS and its updates.

------
sanbor
Maybe some day desktop OSs will adopt the save model that iOS and have a
webkit component. That may allow different browsers and electron app to
reuse/share components (i.e. Webrtc, etc.)

~~~
floatboth
macOS had a WebView for _ages_. Same on Windows, though unless it's the latest
version of Windows you get a crappy old IE engine. On X11, you can use
QtWebKit/WebKitGTK.

But web developers wanted to have a super recent engine and the same one
across operating systems so we have what we have.

------
tinus_hn
These qualities aren't Flash's achievement. The plugin model allowed people to
experiment and try out a lot of different approaches.

------
makkesk8
Funny how people are bashing electron when games have embedded chromium for
years.

~~~
TillE
As a web browser, yes. It's not even suitable as a game UI, basically just for
displaying websites.

------
BuuQu9hu
As participation increases, quality declines, unless there are structural
safeguards built into the system. I see nothing in Electron which suggests
structural quality. I wonder whether rose-colored glasses are overly tinting
the viewpoints of folks in the JS community.

~~~
tree_of_item
> As participation increases, quality declines, unless there are structural
> safeguards built into the system.

Well, yeah, but that's a refutation of the entire web. Maybe we should go back
to the days when only a chosen elite was able to distribute writing or
software to a wide audience?

~~~
izacus
What a strawman. Noone wants to go back to days of "chosen elite", but
JS/Electron really really REALLY isn't the only simple way of building cross-
platform apps. Don't make false comparisons.

Cross platform desktop toolkits are usually SIMPLER to build apps in because
they don't have the document-centric baggage of HTML/CSS/JS stack.

People have been building cross-platform software since forever - heck, in
1980s you had to port your game/software on several different architectures
and bedroom programmers (far from "chosen elite") regularly supported Ataris,
Amigas, Commodores, PCs and other platforms.

~~~
tree_of_item
> Cross platform desktop toolkits are usually SIMPLER to build apps in because
> they don't have the document-centric baggage of HTML/CSS/JS stack.

Which one is simpler than Electron, in your opinion? Because it seems like a
lot of people would like that sort of thing.

