
Electron is flash for the desktop (2016) - djsumdog
https://josephg.com/blog/electron-is-flash-for-the-desktop/
======
morpheuskafka
First off, the primary issues with Flash were that it was proprietary, had
numerous security issues (due to its open source nature) and required custom,
non-portable code.

Electron is a free software platform that builds on the open web standards. It
uses the Chromium browser, which is available on every major platform (that
permits browser installation, that is). And it works with "walled garden"
stuff like iOS/Safari, because the modern web actually does a pretty decent
job of coordinating standards.

If you use Linux desktop, you should be cheering loud and proud for Electron,
because that's how Spotify, Discord, and many other apps have full feature
parity between Linux and Windows and macOS.

~~~
antoineMoPa
Linux user not cheering here. I don't really get the point for desktop apps
for things like discord... Why would I want another browser engine running
when I can chat in discord in Firefox that is already running? Electron is
like starting a tiny VM for every app. The only advantages I see here is for
the app developer, who can be more intrusive (full access to run proprietary
code on my laptop, send desktop notifications to make me an addict of their
service, etc.)

~~~
servercobra
I could definitely run a bunch of apps in my browser, but I prefer the desktop
clients when possible. They show up in the dock (I'm sure I could do this with
a browser app), they keep my browser clear for browsign, I can more easily
Alt+Tab to them, and I don't have to worry about closing my browser and
killing my chat client.

~~~
antoineMoPa
If there was something like an electron server with many client windows/apps,
we could get all those nice features without launching many chrome
instances...

~~~
stcredzero
So something like X-Windows, but with a VM.

------
AboutTheWhisles
No it isn't, flash was the best way to do many things for the years it was
popular. Video, vector animation, simple interactivity.

Electron is only the best way to do something when someone knows only
javascript and web dev but doesn't want to learn a new language. Maybe a case
could be made for severe misconceptions also helping electron like 'a custom
native app has to be made for each platform', even though C++ and Qt and many
other combinations can be written once with 99% of the source being the same
for every platform.

~~~
SquareWheel
>Electron is only the best way to do something when someone knows only
javascript and web dev but doesn't want to learn a new language.

Why is there always someone ready to jump in with this elitist nonsense?
There's plenty of reasons to use a web stack even if you know other languages.
It's inherently crossplatform, has an extensive library, and is extremely
quick to iterate on.

Slack and Discord building in Electron means they only need to maintain one
codebase across web, desktop, and mobile. They don't need separate teams for
building in Java, Swift, and C#. They only need to write a new feature _once_.
Crazy, right?

This "web programmers are dumb" attitude is nothing but elitist rhetoric. Cut
it out.

~~~
derefr
> There's plenty of reasons to use a web stack even if you know other
> languages. It's inherently crossplatform, has an extensive library, and is
> extremely quick to iterate on.

The GP's point was that, in the year 2019, none of these features are _unique_
to the web.

• For "frameworks", there's Silverlight, Adobe Air, Haxe, and—strangely
enough—Flash itself, which still works just fine if your goal is to ship a
standalone "projector" app rather than something that runs in a browser.

• Or you can use a cross-platform scripting language (e.g. Python) with a
cross-platform GUI toolkit (e.g. QT, WxWidgets.)

• Or you can use a not-cross-platform language (e.g. C#) but just use the
(pretty large) subset of that language that is compatible with a third-party
cross-platform runtime (e.g. Mono). Before you laugh, this is exactly how many
companies code games to be cross-platform: they just write them for Win32 but
constantly test them under Wine to ensure they aren't breaking Wine
compatibility. Then they ship one native version and two virtualization-layer-
wrapped versions.

• Or—horror of horrors—you _can_ just use Java, and use the various Java-to-
native-X compilers to target mobile platforms like iOS. (It worked well enough
for Minecraft!)

~~~
Pfhreak
> none of these features are unique to the web.

The web has _all_ of them, I have yet to find another platform/language that
meets all the same criteria.

Combine all of the above with a rich toolchain and extreme dev tools
portability -- I can be up and running on basically any machine in minutes. As
well as ease of deployment (at least for hobby projects).

All of those other platforms are, for me, less in one of the axes I care
about. I've developed extensively in Python, C#, and Java for both personal
and professional projects and while I like developing in them for many, many
reasons, when I need to start a new project I nearly always find myself
reaching for Javascript as the starting point.

------
bluetidepro
This doesn't align with what I see in my Activitiy Monitor when I open it up
and look at the Slack usage. I don't know a ton about this stuff, so maybe
it's a relative thing, but my Mac has next to no problems with Slack like he's
raging over in this post. The memory footprint is way smaller than his
screenshots show. I also have 10 workspaces connected (not sure how that plays
into it).

> I mean come on. Its a text chat program.

Seriously? To boil Slack down to just a chat program is silly, when you look
at all the feature it has with it (screen sharing, calling, file sharing,
etc.).

Electron hate is the new PHP hate. As I've seen many others say before on HN,
what people don't seem to get is the experience of using Electron is miles
ahead of anything else in convenience. Instead of writing a blog post ranting
about Electron, why not be constructive and talk about solutions or
alternatives? Wouldn't that be more productive?

EDIT: Didn't realize this post was from 2016. Seems way out of date, carry on,
nothing to see here.

~~~
morpheuskafka
I wish people understood that (especially when it comes to FOSS, but even for
proprietary software), convenience = more features. With Electron, shipping a
Linux desktop app after writing the Windows/macOS one is almost no extra
effort. Meanwhile, asking a developer with <1% Linux users to rewrite a
Windows Forms app into GTK is not going to happen.

~~~
ahartmetz
Hey, I'd be fine with Slack being completely unavailable for Linux. I don't
think any of the places where I have to use it currently would use it in that
case.

------
beamatronic
Old user here... I still don’t understand how Java failed at this. It was
supposed to be the solution. You can, today, make cross platform, mostly
native apps, with Java. But didn’t really become ubiquitous like we all
thought.

~~~
dtech
Combination of things really

    
    
      * Non-native look and feel. Personally I think this is the big one.
      * Applications/Applets took (take?) forever to boot. JIT takes a while to kick in.
      * High memory usage due to heap+reference memory model and GC model.
      * Latency spikes due to GC
      * Installing a JRE is cumbersome for users
      * Incompatible JRE versions are a pain for users
    

If I'm being perfectly honest, a lot of the problems people have with Electron
were or are problems with JVM consumer applications.

~~~
Teknoman117
And electron has a native look and feel?

~~~
dtech
Most of the electron apps have a very customized look and feel, and default to
a website-ish look and feel. Maybe not native but at least users are used to
it, and it's not as alien as Swing.

------
mdhughes
Slack is a poorly-written Electron app, and unfortunately it's the poster
child for it.

Discord does more with a fraction of the resources, and is also Electron. Atom
is a giant editor framework, and is still less heavy than Slack in normal use.

Electron can run quite reasonably when you aren't an idiot/under complex
enterprise requirements which probably explains Slack's load.

~~~
nv-vn
Discord uses minimum 140mb of RAM when idle on my machine. VS Code is
currently idling at 330mb for me (2 files open), and it's a fork of Atom that
allegedly performs better.

~~~
pitaj
VS Code isn't a fork of Atom.

~~~
nv-vn
Fair, though it is praised as being efficient for an Electron app

------
AlexandrB
One victim of Electron and the whole web-app economy is right-click context
menus. Actions that would previously be doable by right clicking often require
selecting, and going to a hamburger menu within electron apps or apps with a
"modern" design.

~~~
eppsilon
Steve Jobs' insistence on one-button mice was an idea too brilliant for its
time... /s

------
tombert
It makes me a little sad that JavaFX never really caught on. I thought that
Swing was horrible for cross-platform development, but the little I've done
with JavaFX is pretty pleasant, and seems to perform at least as well as
Electron, if not better.

~~~
pdkl95
I recently tried to use Swing (for compat. and interop. reasons). While it was
obviously "quirky" (partly just from it's age - some of those "quirks" were
expected behavior at the time), it _appeared_ to at least be _functional_. I
have very simple GUI needs for this project, slapping a basic UI onto the
project shouldn't be _that_ hard, right?

Then I discovered the multiple layers of hell of Swing's various layout
managers. I never thought I'd actually find something worse than packing GTK+
{h,v}boxes. I think I might end up retreating back to Tk...

~~~
Gibbon1
> might end up retreating back to Tk

You could cross over to the dark side and embrace the Microsoft Heresy.
C#/.net

Upside: Just works Downside: Other programmers will hate you.

~~~
tombert
How well does the .NET stuff work across platforms nowadays? Can I conceivably
have a "write once, compile anywhere" mentality?

Conceivably if it is any good, you could get programmers to hate you a little
more or less by using F#.

~~~
Gibbon1
There is .net Core, but that doesn't currently have any GUI frameworks.

My rough impression is cross platform you have three options, web crappy, full
native, and non-native. The last you may be native on one platform and
look/act weird everywhere else.

That said I like stuff built on wxWidgets. There are bindings for other
languages, never used them tho.

~~~
tombert
I have a visceral (possibly undeserved) hatred of C++, so WxWidgets and Qt are
out; as it stands it looks like for what I need I'm stuck with Electron for my
GUI stuff, since I don't want the JVM dependency.

~~~
pdkl95
There is always Tk. It's a very friendly (no sudden unexpected behavior), easy
to use toolkit.

[https://tkdocs.com/tutorial/index.html](https://tkdocs.com/tutorial/index.html)

Tk works more or less everywhere and sometimes already installed:
[https://tkdocs.com/tutorial/install.html](https://tkdocs.com/tutorial/install.html)

and you don't need to use tcl:
[https://tkdocs.com/resources/languages.html](https://tkdocs.com/resources/languages.html)

If you don't like Python, Ruby, Perl, or Tcl, other bindings are available:
[https://wiki.tcl-lang.org/page/Languages+with+a+Tk+binding](https://wiki.tcl-
lang.org/page/Languages+with+a+Tk+binding)
[https://en.wikipedia.org/wiki/Tk_%28software%29#Language_bin...](https://en.wikipedia.org/wiki/Tk_%28software%29#Language_bindings)

While the stock look-and-feel is functional-but-bland on all platforms, modern
Tk is completely customizable and can approximate native widgets:
[https://tkdocs.com/tutorial/windows.html#dialogs](https://tkdocs.com/tutorial/windows.html#dialogs)

------
fimdomeio
At some point in my country for some state fundings the only way to apply was
via a windows app. The company I worked at the time, bought a pc just to
apply. Sure they would have loved a crappy electron app instead.

Electron is not a problem is a symptom. People/companies want to write apps
that run everywhere and that is actually a great thing. The problem is OS
people not having their own little w3c to fix the problem.

Its starting to look pretty clear that sooner or latter all native apps will
be coded in html css and some programing language (js or not) for the sake of
being easy to port, so please OS people, get us a better solution than
electron.

~~~
AnIdiotOnTheNet
Java runs everywhere and is at least an order of magnitude more efficient than
Electron. If it was really about WORE then these developers would be using
Java, a language and runtime actually designed for applications instead of
being shoehorned into that role.

~~~
slantyyz
>> Java runs everywhere and is at least an order of magnitude more efficient
than Electron.

I don't think people are choosing Electron for efficiency. They're choosing it
for getting results sooner.

Electron lets you pump out a reasonably nice looking cross-platform app that
does what it's supposed to do, using a lot of your existing code, in a short
period of time.

That convenience to developers can easily outweigh the trade-offs related to
Electron's many flaws, especially when time and resources are very limited.

~~~
AnIdiotOnTheNet
Except, you know, for the users who's time and resources are the ones being
wasted. But who cares about them, right?

------
mariopt
Electron is the only decent solution for building a cross OS app in 2019. I
challenge you to give me a stack that It's fairly simple to maintain on
multiple desktop platforms, build UIs, has plugins to support most of the
feature we're used today in a browser, etc. Don't forget that javascript now
runs on the server, having a single language for everything is amazing.

The browser just became the best ecosystem for build apps and the native
development frameworks are years behind the browser. The default set of
Widgets available will make you waste months building your own widgets versus
downloading a js plugin and it's done in 30 minutes.

Electron just gets things done, period.

There are examples of fast Electron apps like Realm Browser. You can also
build the UI with Electron and Javascript while you do some IPC with smaller
binaries written in C++, Go lang, C#, etc. to try to improve the performance
of some operations. It is possible to write good and fast Electron apps.

Don't forget that many js developers came from jQuery and other backgrounds
and might not have the best ideas when it comes to build desktop apps and even
understanding an OS architecture. I don't mean to be mean with these
developers, we need to acknowledge that these days lots of companies just want
Javascript developers and any cost.

Another major benefit of Electron is that platforms like Linux do get some
support which is really great.

Without electron, I could not use Linux to work on projects that use Slack for
example.

Without electron, many developer tools wouldn't exist at all and most likely
they would be tied to windows and/or mac. Linux would be the biggest looser
for sure.

Don't think it's fair to shit on Electron, I love fast apps but, sometimes,
buying more RAM and a faster CPU just solves the damn problem. I'm not saying
people should write slow apps but at the end of the day I've stuff to get
done.

I would rather see a better collaboration to try to improve Electron
because... we need it. Either this or the native development tools need to
wake up to 2019.

~~~
saagarjha
> Electron is the only decent solution for building a cross OS app in 2019.

It's not decent.

> I challenge you to give me a stack that It's fairly simple to maintain on
> multiple desktop platforms

C++ core library, thin UI layer on each platform.

> The default set of Widgets available will make you waste months building
> your own widgets versus downloading a js plugin and it's done in 30 minutes.

Why would you build your own widgets? The ones the OS provided have had
_years_ put into them.

~~~
mariopt
> C++ core library, thin UI layer on each platform.

The time required for coding in C++ is much more higher than javascript, just
this point alone requires a bigger budget, time and a HR problem: hiring C++
developers vs javascript. You'll also spend more time configure each build for
each platform, Electron has this automate for you already.

Web technologies are easier to learn: A designer can write CSS for your
Electron desktop app but can not code the style in C++. It's just easier to
add more people to the project. I'm aware than native tools do have IDE for
designing UIs and easier markup languages like QML. Guess what, html and css
are the true winners for the majority of developers/designers. The IDEs for
native development are targets for developers, they don't account for
designers. I've worked with several some years ago for windows, mac and linux.

> Why would you build your own widgets? The ones the OS provided have had
> years put into them.

The widget provided by the OS are basic. If you try to recreate a modern web
interface you've to build each components by yourself. On the web you've
plenty of option to quickly assemble a GUI. On Elementary OS, the OS style is
done in CSS even though they use Vala/GTK+ to code the UI.

Also a cross platform GUI is a promise that is never delivered properly. With
Electron apps can deliver a consistent UI: Slack looks the same regardless of
the platform. With native, the UI looks good on one OS and like crap on
others.

When Electron allows you to build a fairly complex app in 3 months, it's hard
to sell native development due to the massive time you'll need. Just look at
the React Native, it exists because it is a lot cheaper and faster than
writing individual native iOS and Android apps.

~~~
saagarjha
> The time required for coding in C++ is much more higher than javascript

I'm not convinced that this is true.

> The widget provided by the OS are basic.

Not really. I am yet to see an Electron widget that does drag-and-drop,
accessibility, theming, keyboard control, etc. right. OS widgets are by no
means "basic".

> Also a cross platform GUI is a promise that is never delivered properly.
> With Electron apps can deliver a consistent UI: Slack looks the same
> regardless of the platform. With native, the UI looks good on one OS

That's the whole point: I don't want my apps to look dumbed down to the lowest
common denominator. Each native app looks good and fits in on its platform.

> Just look at the React Native, it exists because it is a lot cheaper and
> faster than writing individual native iOS and Android apps.

React Native is much nicer than Electron in this respect, because it doesn't
package then entire Chromium engine and uses native controls to a limited
extent.

------
mherrmann
Shameless plug for my library [1] that makes PyQt a very viable alternative to
Electron.

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

------
forgot-my-pw
Previous discussion:
[https://news.ycombinator.com/item?id=14087381](https://news.ycombinator.com/item?id=14087381)

~~~
untog
And nothing has changed since that discussion, really. The top post is still
correct: if Electron didn't exist we wouldn't be seeing a collection of
beautiful, performant desktop apps. We'd just have fewer desktop apps, and
you'd be using your web browser more. Particularly on Linux.

Which, IMO, is fine! I don't use the Slack desktop app, I have a tab open in
my browser. It can 'ping' the tab bar to get my attention, and it can send
notifications. It works fine.

~~~
michaelmrose
Counterargument at least SOME people would be shipping actual apps that are
worth something. 1 app worth using is better than 5 subpar ones.

------
stcredzero
_Its built on top of electron, so when you download slack you 're actually
downloading a complete copy of Google Chrome. Chrome, at the time of writing
is 15 million non-comment lines. When you download slack, 99% of the code is
'below the water'._

 _And chrome is a hog. Its huge and complicated. It uses ram and CPU like
nobody 's business, and it totally thrashes your battery life._

I remember when Chrome was the shiny, nimbler, new kid on the block.

~~~
Gibbon1
Reminds me of a nerd friends comment about why Eclipse exists, because in the
late 90's some people thought Emac's was a bloated pig.

~~~
stcredzero
Actually, Eclipse was a port of the "Visual Age" family of IDEs which started
out implemented in Smalltalk. Smalltalk started out as something like Lisp,
without the insanity of coding in your data representation. (Unfortunately, it
means you don't have the insanely great benefits of coding in your data
representation.)

Emacs was actually a great way to do work over a slow modem connection back in
the late 90's.

------
loudmax
Flash isn't necessary today because HTML 5 is a shared platform that all
modern browsers have in common. HTML and javascript as native as anything else
in the browser and they're cross platform. This is critical. The criticisms
about Electron's memory and CPU usage are legitimate, but it should not be
understated how important it is to have a target for both web and desktops.

Maybe WebAssembly will get us there with decent performance.

------
mic47
Tab in browser provides way better user experience than electron app (or
native android/ios app). With website you can to mind-blowing things like:

* Open other part of your app in new tab.

* Open other part of your app in new widow, and have time side by side.

* Open external link in new tab, in the same window (OMG!!!).

* I can send link from the web app to someone else.

* Consistent back button.

* Use browser extensions.

* Have cookies (i.e. I am logged out of most of the things in your in-app browser).

Composers are generally thing that are better in apps, but as long as I don't
need to compose complex stuff, web app always wins. And if I do, I'll prefer
to use native/electron app only for composing, not for consumption.

~~~
felixfoertsch
> Open other part of your app in new tab. Unless the developers forbid it...
> and always finding new ways to forbid it...

Man I hate the new web.

~~~
mic47
This is more of an old web, and because of bad design: keeping state of the
app on server, rather than in the browser (or are you referring to limiting
open in new tab?).

But yes, I hate the new web too (sometimes).

~~~
felixfoertsch
I was thinking of web apps like MS Teams that just simply do not allow to open
a new tab on click for whatever reason. I can open the app in two windows just
fine, but I can't right/middle click on something to tell it to open in new
tab. Why would I not want be able to open a Word Online document in a new tab
directly?

There are other apps, that are even worse. Allowing something to open in a new
tab/window but identifying that there are multiple windows open and just
disabling all but the main window...

I don't understand developers that do this. I always felt that multiple tabs
is a _strength_ of the web. They worsen it somehow.

------
sidcool
Can we label this as 2016

In addition, has Slack performance improved since this post was written?

~~~
purerandomness
It got much worse.

------
bixby42
Silly post. Visual Studio Code also uses Electron, and has yet to spin up fans
on my machine. I use it every day, all day, on a variety of platforms. There
seems to always be someone who thinks there clever complaining about bloat and
then pointing to C or now trendy Go and/or Rust. It rarely is. Perhaps Slack
was doing some sort of internal auto-update when the CPU started thrashing. Of
course figuring that would kill a good blog rant about bloat. I sure hope the
author doesn't run Windows.

------
xvilka
Revery UI[1] framework is like Electron but without a browser.

[1] [https://github.com/revery-ui/revery](https://github.com/revery-ui/revery)

------
tiuPapa
I get how Electron is useful. What I don't get is the why of it. Why should I
have open another browser engine when I could just access it on my browser
that I already have running.

~~~
thosakwe
Writable file access, ability to use ES6 and beyond without compatibility
issues, media keys, etc.

But really I think that filesystem access is probably the main one, at least
for me.

~~~
tiuPapa
Ah yes, but I was speaking more about apps that uses Electron to view their
web page like Spotify or Discord

------
SquareWheel
Seems like yet another complaint about Electron's filesize/memory usage? We
already know it isn't great. I don't see what this post adds.

~~~
jamespitts
Comparing Electron to Flash in this way brings in the reader's mind other
considerations than performance, primarily closed source and security
vulnerabilities. It is a misrepresentation, perhaps unintentional. The article
should be entitled: "Electron has performance issues".

------
efficax
I hate Electron too, but the bi-monthly hour of Electron hate on here is a
little tiresome. It's clear that it solves some major issues from a
development standpoint for a lot of organizations, and it's here to stay.
Slack isn't going to rewrite their app (hell they can't even implement dark
mode). It's just another thing we have to get used to.

------
butz
Like Flash was replaced with web technologies, Electron soon will be replaced
by Progressive Web Apps. Just have to wait a bit longer for browsers to
securely implement missing functionality, like access to file system. Although
for most apps that doesn't need any advanced APIs we can use PWAs today.

------
k__
For people who don't like Electron, but still need it's features, I recommend
Revery.

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

It's build with Reason/OCaml and builds native self-contained binaries (~3MB
for simple apps).

------
yarrel
It's _ActiveX_ for the desktop.

------
chxei
why can't all Electron apps use same chrome base like a lib?

------
jlv2
(2016)

