
Electron is flash for the desktop (2016) - charlieirish
https://josephg.com/blog/electron-is-flash-for-the-desktop/
======
anaisbetts
Here's the thing. You know what the alternative to all of these Electron apps
coming out is? If your answer is "A native Cocoa/WPF app", you are on another
planet, the answer is, "It wouldn't exist at all".

 _Nobody_ in the last 5-10 years cared about writing Desktop apps before
Electron came along, there's basically zero money in it, and it's massively
expensive, both in terms of actual dev time per feature (easily 10x the cost),
and also in finding specialist developers who know these dated technologies.
And as for Qt, Qt has existed for _over two decades_ \- if its massive
"Beatles walking off the plane" moment hasn't happened by then, sorry, it's
not gonna.

But now? People are making all kinds of great new apps, and more often than
not, they come out on all three platforms. People are _excited_ about the
Desktop again - Electron is so good it's single-handedly revitalizing the
platform that two of the largest tech companies in the world are behind, yet
couldn't do.

That is a Big Deal.

~~~
matthewmacleod
That's _nonsense_. Desktop apps have been frequently released since forever.

The underlying issue here is that Electron _reduces the barrier to entry for
cross-platform development_. That is, it's cheaper to build a single cross-
platform application in Electron than it is to build two or three native
applications, and you can re-use your existing web experience. I can
completely understand why companies might choose this approach.

The trade-off — and there _is_ a trade-off — is that Electron applications are
_shite_ in comparison with proper native applications. They fail to integrate
with the host platform, they are slow, they hog memory and drink power. It's
fine to make those trade-offs – in some ways, it's better that you can get an
application at all than the alternative of 'no support for your platform'. But
let's be honest here – there is nothing preventing e.g. Spotify or Slack from
building native clients for each platform they support, and I find it
difficult to believe that the costs would be prohibitive.

~~~
newhere420
> Electron applications are shite in comparison with proper native
> applications. They fail to integrate with the host platform, they are slow,
> they hog memory and drink power.

Are they though? The two applications that use the most energy on my Mac - by
far - are Steam and Skype. Steam still has trouble with HiDPI and freezes when
performing various UI interactions. The number of problems with Skype are
uncountable.

I'm currently booted into Windows for work, looking at my current process
stats, the top memory consumers are:

* Visual Studio (hodge podge of all kinds of things, 800MB)

* Chrome (215MB)

* Microsoft Intune (presumably native, 114MB)

* GitHub (.NET WPF application, 108MB)

* Explorer (native, 103MB)

* Search Indexer (native, 107MB)

* Lync (who knows, 98MB)

Meanwhile, the supposedly terrible Electron apps:

* Spotify - 58MB

* Slack - 93MB

* VS Code - 60MB

As far as interfaces go, Spotify, Slack and VS Code easily outclass GitHub,
Visual Studio, Explorer and Lync in usability.

~~~
RedCrowbar
Each Chrome (and Electron) app instance is a group of processes. You are
probably just looking at the main process, while the bulk of RAM/CPU use comes
from the renderer processes.

Here are stats on my (Linux) box:

* atom - ~500MiB (one window)

* slack - ~816MiB

* chrome - ~935MiB (two tabs + hangouts)

* google music electron app - ~500MiB

~~~
newhere420
Nope, those figures were after adding up all the processes. What I have
noticed in switching between platforms is that applications tend to report a
far lower memory usage in Windows than on Linux or OS X.

Might just be an accounting difference. Forked process applications in
particular are very difficult to account, because even their private/RSS may
be COW from another process.

~~~
RedCrowbar
My figures exclude shared memory and are calculated as VmRss - Shared from
/proc/<pid>/statm.

If you are using Windows 10, your missing Atom processes will be under
Background Processes in Task Manager. For the sake of the argument, I just did
a fresh install of Atom and this is what I see on the first run:
[https://i.imgur.com/0ZRSumF.png](https://i.imgur.com/0ZRSumF.png). ~220MiB
(no files open, zero extensions).

~~~
Klathmon
That's really interesting! I have an up-to-date atom install that i've been
adding plugins to for about a year now (up to like 50 or so), and has been
running for at least 12 hours (windows 10), and currently has 7 ~500 line
files open.

Adding up all the processes' (7 of them) private memory gets me 194mb.

~~~
RedCrowbar
I installed the 64-bit version, you might be using 32-bit.

~~~
Klathmon
No it looks like i'm running 1.15.0 x64.

It might just be a difference of platforms.

------
sametmax
People complaining about electron are the same type than the ones that used to
say :

\- why are people writing this stuff in C. It's so slow and you don't have as
much control on memory. Write it in Assembly.

\- why are people writing this stuff in Java. It's so slow and you don't have
as much control on memory. Write it in C.

\- why are people writing this stuff in Python. It's so slow and you don't
have as much control on memory. Write it in Java.

Eventually people want to solve a problem with the best ratio cost/quality for
them, not "doing it the proper way".

So unless you provide a better solution for them to do that, or pay big money
to create such solution, they will find the ugly-hackish-half-baked-working-
for-them solution that let them do this.

We had PHP. Now we have JS.

I hate it. You hate it. We all hate it.

But I created portable GUI apps with an installer before in my favorite
language and others and it was a pain. All of it. The UI, the event model, the
API, the portability edge cases, the new stuff to learn, the packaging, the
dependencies...

It sucked.

So get over it or provide a solution, but stop complaining.

And before you start providing an EXISTING solution, remember people tried it
and they didn't like it as much as electron. And since electron is so bad,
that should tell you something.

So the market is saying you are wrong. You can ignore it from your better tech
tower... Try to boycott electron apps all you want. But we know how it has
played for betamax, lisp and the ogg format.

P.S: oh, and if electron is flash, remember that flash won the web for 15
years while it sucked. And you know why ? Because it allowed people to do
stuff they wanted easily, like videos and animations. And it's not because we
couldn't do it any other way, we could. Yet we had to wait almost 2 decades to
see it dies, at the price of battery, stability, security and everything else.
Feature trumps everything. People. Don't. Care. We only manage to kill it
because we finally replaced it with systems that could compete on easiness and
features. So you know what to do.

~~~
2bitencryption
> why are people writing this stuff in C. It's so slow and you don't have as
> much control on memory. Write it in Assembly.

did anyone ever actually say this?

> why are people writing this stuff in Python. It's so slow and you don't have
> as much control on memory. Write it in Java.

this one is odd to me considering Python came first...

~~~
sametmax
> did anyone ever actually say this?

Wordperfect is famous for failing because they sticked to assembly while the
competition moved to C.

> this one is odd to me considering Python came first...

It is indeed. But date of creation has no importance in this. Java became
popular first, and is faster and consume less memory than Python. I'm a Python
dev now, and I when I picked up the language more than a decade ago, people
where looking at me like I was crazy.

------
paraboul
FWIW, we're working on
[https://github.com/nidium/Nidium](https://github.com/nidium/Nidium) presicely
to fix this.

A new kind of browser engine, not based on any existing engine, allowing
developers to use a subset of the web (webgl, 2d, layout) without being forced
to use a bloated ecosystem (and which also works on mobile and low end
device).

Previous HN discussion :
[https://news.ycombinator.com/item?id=6314961](https://news.ycombinator.com/item?id=6314961)

~~~
SOLAR_FIELDS
> To build nidium you need at least 5.7GB of disk space. A build from scratch
> may take 30 to 90 minutes, depending of the speed of your computer.

Is this abnormally large for a project like this?

~~~
pavlov
Building Chromium/CEF requires several times more disk space and takes several
hours on my new MacBook Pro. So I guess the answer is "not abnormally large".

------
migueloller
> If you want to use JS and react to make a native app, try react native
> instead.

Given the discussion of the recent ReactXP thread, I'm guessing most people
don't realize you can do this _today_. React Native supports macOS [1] and UWP
[2].

Edit: There's even some early work on Ubuntu support [3].

[1] [https://github.com/ptmt/react-native-
macos](https://github.com/ptmt/react-native-macos)

[2] [https://github.com/Microsoft/react-native-
windows](https://github.com/Microsoft/react-native-windows)

[3] [https://github.com/CanonicalLtd/react-
native/blob/ubuntu/REA...](https://github.com/CanonicalLtd/react-
native/blob/ubuntu/README-ubuntu.md)

~~~
mijoharas
I'm probably in that camp too, I thought it was just for android and iOS still
(even though I consider myself to keep up to date with these types of things).

Do you know if they have anything for linux yet?

~~~
savanaly
I originally thought React Native was for all platforms, then I read their
website and docs which made me realize it was only for mobile. That all went
down a few weeks ago. Now, today, I find out I had it right the first time.
How big a shortcoming is it of their website that it made me go away thinking
it was something it wasn't when I had the right thing in mind?

~~~
mijoharas
Same here, it makes me wonder how hard it is to build for all the platforms as
well given that they are all spread out across so many different repos.

------
grinich
At Nylas we made a huge bet on Electron-- our desktop app Nylas Mail actually
started as a fork of Atom Shell before the project was rebranded to
"Electron."

To be honest, we would have never built this app without Electron. It allowed
us to have a small team (2 devs) ship the first version of the app without
learning an entire new dev toolchain on multiple platforms. There certainly
can be performance issues with building on Chromium/Node but those can be
pretty easily addressed.

We even had an early engineer with tons of Cocoa/ObjC programming experience
and they still preferred shipping with Electron.

The HN crowd complaining about Electron kind of feels like the early criticism
of Dropbox or the iPod. "This is technologically inferior and has fewer
features so it is clearly worthless."

For some reason there's a deep-rooted philosophical opposition to Electron-
like technologies from lots of hackers. But I predict it will be like Java--
everyone "hates" the JVM for years and calls it slow and then one day it's
running nearly every mobile device and being used across Google.

It's not crazy to think Electron will evolve like this-- it certainly has the
momentum. And the ideas of a web-based desktop app platform have been pushed
by Google, Apple, and Microsoft in the past. Seems like we're finally getting
there...

(For the curious: [https://github.com/nylas/nylas-
mail](https://github.com/nylas/nylas-mail) )

~~~
pdimitar
It pains me to see how a person responsbile for a pretty important app is as
oblivious as you are to the real issues.

Many people use laptops and their battery life matters a lot, being one
"minor" factor. Not to mention that in a technical sense, your app _really
shouldn 't_ take any CPU while idling. Doing a socket wait is something a
Raspberry Pi Zero handles without going to more than 1% CPU, for half a
second.

At any rate, other people in this thread explained it much better than I
could:
[https://news.ycombinator.com/item?id=14091782](https://news.ycombinator.com/item?id=14091782)

~~~
namuol
> [...] oblivious as you are to the real issues [...]

I understand that you're frustrated, but this kind of language does not foster
productive discourse.

As I understand it, Nylas (grinich's OSS Email product/platform) wouldn't have
been possible to build with a two-person dev team had they chosen to implement
it in something other than Electron.

Are you suggesting we're better off without competitors to the existing email
desktop-clients?

~~~
pdimitar
> _Are you suggesting we 're better off without competitors to the existing
> email desktop-clients?_

This is a false dichotomy and you are aware of that fact. This polarization
shouldn't exist in the first place. And it can be eliminated with a small time
investment.

As developers of important apps, your contribution to the world influences
culture. Other follow in your wake. Is that the influence to the world you
_really_ want to give to other programmers and business people? Time to market
is not the only priority.

That you treat a non-flattering language as me being frustrated tells me you
will not understand that side of the argument however. So let's agree to
disagree and move on.

~~~
namuol
> [...] you treat a non-flattering language as me being frustrated [...]

You're right; I was being presumptuous about your emotional state. I
apologize. -_-

Let me try to clarify: Companies like Slack and Nylas and Spotify understand
the performance implications of using Electron and it _is_ a real problem, but
the _benefits_ of using something like Electron, at least currently, outweigh
the performance troubles.

There's simply a _much_ lower cost to iterate quickly on a web-driven
application.

That said, we're all frustrated about the performance implications (users and
companies alike), and this this is reflected in the direction the industry is
taking.

I predict Electron _will_ become less popular in the next year or two as React
Native desktop support becomes proven by one or more major players:

\- Linux: [https://github.com/CanonicalLtd/react-
native](https://github.com/CanonicalLtd/react-native)

\- OS X: [https://github.com/ptmt/react-native-
macos](https://github.com/ptmt/react-native-macos)

\- Windows: [https://github.com/Microsoft/react-native-
windows](https://github.com/Microsoft/react-native-windows)

~~~
pdimitar
> _You 're right; I was being presumptuous about your emotional state. I
> apologize. -_-_

Upvoted for you being nice and constructive. =) I could've been less harsh
myself. Sorry!

> _...the _benefits_ of using something like Electron, at least currently,
> outweigh the performance troubles._

I get it, man. I've been there in the past. I understand your position.

> _There 's simply a _much_ lower cost to iterate quickly on a web-driven
> application...That said, we're all frustrated about the performance
> implications ..._

Not arguing that, that's an undeniable fact.

> _...as React Native desktop support becomes proven by one or more major
> players:..._

Yes. Nothing would make me happier. I started with Windows' crappy MFC, ATL
etc. horrifying libraries and I've been immensely let down by the promise of
Java Swing community that never managed to get its act together well enough to
give you a quick and easy way to create cross-platform UIs. Desktop UI is like
a hobo on a celebrity wedding: everybody knows it's there, everybody feels
awkward about it, and nobody wants to improve its situation. And that's going
for like 20 years now.

Us the slightly older generation of devs are guilty for the situation as well.
We too had to go on about our day jobs and find a quick way around.

I guess I was a bit harsh because I expected the next generation to pick up
the ball and dribble it better than us... >_< Which is a very wrong and
egotistical expectation, I'll be the first to admit.

Just don't give up! Make sure that you educate management periodically. Talk
to them, convince them, give them analogical examples from the physical world
so they get the problem on their level. Never give up the good fight; educate,
iterate, improve.

I loved your app, by the way. I only uninstalled it because I am moving away
from Gmail.

~~~
grinich
You can still use it with any IMAP service! :) We actually just launched the
Windows & Linux beta today: [http://www.omgubuntu.co.uk/2017/04/nylas-mail-
client-now-ava...](http://www.omgubuntu.co.uk/2017/04/nylas-mail-client-now-
available-linux)

~~~
pdimitar
Thanks! I'll give it a try when I move to one of the paid services.

------
Ambroos
A lot of Slack's high (background) CPU usage is caused by GIFs, in my
experience.

Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-view
with nothing animated in view gives it a CPU usage of 0,1% with spikes up to
2,5%. Switch to a conversation with a single animated party parrot emoji, go
to another fullscreen app once again, and CPU usage never drops below a
whopping 22%. For an animated parrot cartoon.

I'm not sure if this is a bug in Slack or Electron. Doing the same in Chrome
does not cause any issues, as GIFs seem to be suspended when the window is not
in view. CPU usage goes down to almost 0 when you switch away from your GIF-
filled Chrome window. For Slack, however, it barely changes. A big shame.

(On that note, I wonder how much power is wasted by party parrots via CPU
usage. Where I work at least one is almost permanently visible in any
conversation as a reaction emoji, so it's probably not insignificant.)

~~~
notalaser
> A lot of Slack's high (background) CPU usage is caused by GIFs, in my
> experience.

Holy fuck, can you imagine the supercomputers that were required to display
Geocities websites in the 1990s?

~~~
magicalist
48x48 gifs with four frames of animation?

~~~
notalaser
The GIFs were significantly more complex than the single emoji that the parent
comment mentioned. Actually, I think even a four-frame 48x48 gif is more
complex than that "single animated parrot emoji" :-).

------
d--b
Electron is just another proof that ease of programming matters.

Node.js too was a terrible idea. Who in their right mind would write server-
side javascript? It turns out: pretty much anyone who didn't want to have to
screw around for hours before being able to respond to a simple http request.

Similarly, it is way harder to write a desktop app than a browser app. DOM /
CSS manipulation, however bad they are, are years ahead compared to what you
can easily do with WPF and friends.

And what about Python for data analysis? The one language that is known to be
10x slower than C becomes the de-facto standard for a field where what matters
most is code performance. Again: ease of programming.

The success of electron only shows that there is a market for a UI library
that can be written just like what you do in the browser but for native
desktop apps... Please someone, write that !

~~~
stedalus
Your Python example doesn't really support your argument. Python succeeded for
data analysis and scientific computing in part because it provided easy access
to existing numerical libraries written in C and Fortran. So you got the best
of both worlds: ease of use and near-native speed. It would not have succeeded
if everything was done in interpreted Python.

~~~
lerpa
> ease of use and near-native speed

And still when we want actual speed we port it to C++ or at least need to use
Cython.

------
Udo
It's appropriate to call Chrome an OS-like platform, and it's quite convenient
to ship apps with, but it's not "Flash for the desktop". As someone who is
opposed to bloat but sometimes appreciates convenience, I think Electron is
getting a bad rap here for something that was screwed up by the JS app
developers.

Go to Electron's website and download the demo (called API Demos). It's 3
processes and consumes 0.0 CPU on idle. Is it super efficient space-wise for
what it does? Certainly not. And RAM usage _is_ a valid concern. But churning
CPU cycles on idle is not Electron's / Chrome's fault. I also suspect that if
an app is behaving grossly on Electron, it's probably a bad actor within a
generic browser environment, too.

My recommendation would be to not ship simple web apps wrapped in this huge
machine without a good reason. But there _are_ good reasons to use Electron or
NW. It's just a poor choice when all you need is a thin wrapper around your
website.

~~~
josephg
Blog author here. Thats a fair criticism. I wanted to pick on Spotify and Atom
more in my blog post, but both Spotify and Atom have cleaned up their act. I
couldn't get either one to reproducibly use lots of CPU. Props to everyone
involved in fixing that.

But I'd also argue that Flash could always be written to be efficient too. The
problem with flash was never the little games people made. The problem was
that one tab with a stupid punch-the-monkey banner add playing somewhere that
would sit on 20% cpu even when the tab was in the background. I think Electron
is similar, except in the desktop space. Well written apps seem to be able to
keep CPU load down (although they still have a huge download and a huge RAM
footprint). But there's been a running trend of noticing some dumb software
running somewhere on my machine eating all my CPU. And in the last year or two
its been an electron app, every time. Just like flash before it.

~~~
apo
> ... I couldn't get either one [Spotify or Atom] to reproducibly use lots of
> CPU. Props to everyone involved in fixing that.

It seems deceiving to conceal that information when your call to action is to
ditch Electron for the sake of performance.

~~~
nnain
The original blog post is from Oct 2016... can't reproduce the bug now. That's
ok; not deceiving.

~~~
daenney
It's not at all clear from their statement that they tried to reproduce that
now, and not that they attempted that in 2016 and didn't manage to.

------
harisamin
A while ago I had been working on a native Mac slack app. I was 70% complete
but sidelined it. Should I pick it up again? Would ppl here be interested in
paying for something like that? Here are some links to screenshots so you know
its not just vaporware :)

[https://twitter.com/harisamin/status/727634194814373889](https://twitter.com/harisamin/status/727634194814373889)

[https://pbs.twimg.com/media/ChkTccjVAAAZ0Kt.png](https://pbs.twimg.com/media/ChkTccjVAAAZ0Kt.png)
[https://pbs.twimg.com/media/ChkTcbMUkAIYolx.png](https://pbs.twimg.com/media/ChkTcbMUkAIYolx.png)

~~~
sovande
Most users will accept issues with their free program if the alternative is to
pay. I'm pretty sure the message pane you have there is a WebKit controller so
it is debatable how native this would be.

~~~
harisamin
There actually isn't any webkit here at all, except for the slack api oauth
login. Everything is native. Trust me, I'm not faking this :)

------
sigil
This is Electron scapegoating. The real issue is twofold:

1\. Electron makes it trivial for developers who don't regularly reason about
native performance to release desktop apps. The result: a flood of apps that
"don't do much" but use more resources than you'd expect.

2\. At the other end, Electron makes complex apps easier to build. The Slack
app might be low-to-medium complexity, but the Spotify app has a ton of
functionality, and I bet dev effort was orders of magnitude lower than for a
native app like iTunes. The result: in this day and age, complex cross
platform apps with higher resource requirements are _more likely_ to be built
with Electron.

In short, there's some selection bias going on in both cases, and it isn't
directly related to Electron. Electron is just the enabler.

I agree with the author on point 1: performance matters, memory usage matters,
and we as web developers should broaden our horizons and learn lower-level
languages. I feel that way regardless of Electron though.

On point 2: I spent the last year building a cross platform continuous sync
app (basically, a Dropbox V1) in Electron [0]. We were a team of 2. I also
write C and C++ for a living, and I simply can't imagine building the same
thing in a lower level language in the same timeframe. It's not just a UI
concern either: writing a sync engine in node (the backend half of any
Electron app) worked out amazingly well. Node is a great I/O orchestrator. The
app runs at < 1% cpu when not actively syncing, 40MB backend process, 70MB
frontend process. Reasonable for what it does. Dropbox uses more than double
that although, granted, it's also not native code.

[0] [https://blend.io/download](https://blend.io/download)

------
boskonyc
Why would a tech company not build its flagship product natively on the
platforms where it runs? It seems like a generation drift: an obliviousness to
the world outside of JS/web dev, and a general disregard for application
performance.

~~~
52-6F-62
Put simply: time to market. Experienced front-end devs with a designer on hand
could put together the UI inside of a day, with a workable user experience.

Hell, if you're not afraid of bloating in the codebase, you could use a large
number of libraries to put together a basic, working version inside of a day
or two. Stretch that to a couple of weeks (at most) and you have a prototype
you can release.

The proof is in Atlassian and Microsoft chasing after Slack on this. Very few
people came forward to wave the "Let's just go back to IRC" flag.

It's shiny, new, you can drag and drop gifs and files into it, and it runs
pretty swiftly (ignoring all of the obvious flaws). Most, especially less
technical, users would find it a charm to work with. In my experience, they do
-- and above all of the competitors.

The rest of your points are rather valid. But maybe its not so much
obliviousness, as eagerness and impatience, and the reality of the market
being as timely and pressing as it currently is. It's a race -- just like the
telephone and the radio (for my point I'm ignoring the scale of impact here).

~~~
alkonaut
> Experienced front-end devs

That's the problem right there(?). People bringing a DOM to the desktop
because the developers were fluent in JS.

> time to market

If there were no drawbacks in terms of complexity/performance/size etc then
I'd agree, but now when you have a perf issue that is too large it might be a
huge issue to fix. You also only get one chance for a first impression - and
poor performance is a huge turnoff. Looking blingy and having all the features
doesn't save an app with a 200ms lockup. or a 10% CPU at idle.

~~~
jernfrost
Agree, I think this is a combination of lack of imagination by developers who
only know JS, and management who has bought the myth that cross platform
development is 3x faster than making native apps.

I saw this happen at work. My team were all experts on native mobile
development. We could crank out stuff fast, because we knew our tools well.
But then some management dude got the idea that we would do it 2-3x faster if
we went with JavaScript.

Turns out it was more like 2-3 slower than making all the native versions,
because we did not have strong experience with these tools and APIs were more
limited, poorely documented, buggy, and the tools were subpar.

------
Gonzih
Telegram Desktop is very good example of modern desktop client done in the
most efficient way. C++ and qt, nothing else. Works like a charm an all major
operating systems. Easy to install, use and update. Great stuff.

~~~
zegerjan
Except they've rewritten their Mac app in Swift now. So there must be a reason
they moved away from that.

~~~
Kipters
They didn't rewrite the app. There are multiple official apps, you could also
write your own (that's what is happening for Unigram, an open source UWP
client for Telegram)

------
gavanwoolery
All of this extra memory and CPU power has made us lazy.

Simple applications often lag, because they are written on top of heaps of
crap. Yet you look at a 4k demo that does more impressive stuff with a
fraction of the resources.

When we step really far back, an application should not require that much
code. Nor should the process of abstracting an application on top of a native
system. These things only get muddled when you depend on specific
functionality of the system that is difficult to abstract (i.e. native GUI
component and layout), which you can easily simulate with your own GUI
renderer, potentially in a more optimal way.

Anyhow, I'll sit here waiting patiently until someone figures out how to write
once, run everywhere in a relatively bloat-free manner. :)

------
evmar
I've been working on a hobby app for some years that is a modern refresh of an
old idea. As the article exhorts (and just for funsies, it's just a hobby) I'm
writing it using native code and to be conservative on resources.

Every place I need to render text or make a thing respond to a mouse click I
need to manually do all my own text layout and event handling and so on. (The
app is in a domain where it needs special rendering -- I can't just reuse a
system widget or library like Qt for this.)

Meanwhile, people are making apps similar to mine on top of Electron and
banging out features way faster than I ever could. If they want some popup to
have some bold text, or use the GPU to animate, or properly handle Arabic text
layout, they get it all for basically free, they just need to bang out some
divs. I am jealous.

~~~
Mithaldu
Well, the question is: Does your app run always like a daemon or just when you
actually need it?

It can be fine to prototype in Electron, or to make _tools_ in it. But if
you're making a chat program or anything similarly long-lived, it's the worst
decision you can make for your user.

~~~
ceedan
"it's the worst decision you can make for your user" \- Is it? Because there
are a lot of Slack users who don't care at all about your tradeoffs. Most of
them don't even notice. We're just the unfortunate ones who do notice.

~~~
Mithaldu
Whether they notice or not is orthogonal to whether it's a bad decision for
them or not though.

~~~
ceedan
"bad decision" !== "worst decision"

------
geodel
Very timely article. But I have been told to shut up and use Atom/VSCode/Slack
like everyone else and upgrade hardware if software runs slow.

I find memory/cpu efficient applications not just useful but respectful to
users specially when upgrading hardware is not possible due to financial or
policy reasons.

~~~
ChrisLTD
We're also in an era when the speed of laptop and desktop CPUs has essentially
stalled. Put another way, if our apps hog more resources there aren't
necessarily faster machines we can buy.

~~~
alexforencich
Yes, this is extremely important to remember. The days of "who cares if we use
a few extra bytes of RAM or a few extra CPU cycles here and there as computers
will be twice as fast and have twice as much memory this time next year" are
long over. And with the huge push for mobile and slim, portable computers,
power efficiency is paramount as users really care about battery life. Yes,
sure you can get a more powerful laptop than your nice, sleek, portable
macbook air, but it's going to weigh 5x as much and the battery life will
suck, especially if you actually use that power. People want to be able to use
their CPU and RAM to run multiple applications efficiently, not waste it on a
few laggy memory and CPU hogs.

------
tyingq
>But that's not abnormal for slack. In fact, slack often idles at 5% CPU
usage. Whats it doing? I have no idea.

Probably something like this:
[https://github.com/Microsoft/vscode/issues/22900](https://github.com/Microsoft/vscode/issues/22900)
(not the cursor thing specifically, but something that feels lightweight, but
isn't)

Which is probably fixable. I would guess Vscode is more code than Slack, and
they were able to fix this, albeit with very good help from a customer.

------
cbhl
I think JavaScript is the new PHP -- it's accessible enough that people are
going to be coding in it for the foreseeable future.

Chrome eats a lot of RAM, and frankly, most of these apps don't need all of
Chrome. But any solution that requires moving away from JavaScript (e.g.
C++/Qt apps) is too expensive in terms of retraining developers. (Facebook
found it was cheaper to create Hack and HHVM than to train its engineers to
stop writing PHP-like code.)

Maybe the answer here is a "React Native" library that results in native
Windows/Linux/OS X desktop apps. But, with larger corps focusing on "mobile
first" and "responsive design" memes, I don't imagine either Facebook or
Google being the first to build such a thing.

------
ziikutv
Electron is flourishing because of low barrier to entry like many already
touted. But lets ask something [probably] more constructive?

I've made 3 apps with Electron that I could probably never make since I would
be busy learning OS specific things.

Can we not have low barrier to entry for creating native apps? Are there any
solutions/frameworks that one can utilize? Is it just a matter of poor
documentation/support from OS makers? What is it?

Edit: Some of the contents that said something along the lines of: Is it
really slow? It opens so fast for me...

The worse thing a developer can do is judge their application anecdotally and
not through something more empirical. Its our job to make our shit available
to more users and support more platforms (hence Electron is used) but it is
also our responsibility to make sure they can use our app and have 50 tabs
open and do other more important shit like... watching genitals in a flash
player. I was in this Electron phase but I started to run traces and see how
much of a hog it is.

If you really care about what you are working on, use Electron as a prototype,
get it out there, then start making a native app. I think this is the best of
both worlds. You get your shit out there, people let you know how it stinks
and in the mean time you make something that is better suited for their OS.

P.S: Sorry for the overuse of "shit". I am fishing for upvotes.

~~~
ziikutv
So many up votes (thanks for taking the bait!)

But I really am wondering:

> Can we not have low barrier to entry for creating native apps? Are there any
> solutions/frameworks that one can utilize? Is it just a matter of poor
> documentation/support from OS makers? What is it?

------
tempodox
> Also all you web devs: Go learn C or Rust or something. Your program runs on
> a computer. Until you know how that computer works, you're doomed.

I can only encourage everyone to heed this advice.

~~~
Afforess
Won't happen. All the signs point to more and more developers understanding
less and less of what is going on underneath the covers.

If anything, we are < 50 years away from only AI and machine learning
algorithms understanding chip design and microcode. Soon enough, no human is
going to be able to parse the tech stack below the operating system.

------
ceedan
The best perf improvement for slack is to disable animated images in the
Accessibility Settings... this also removes some of the fun from Slack. I have
suggested to them that they should have a setting to only play gifs when
they're hovered-over, but still waiting on that to be implemented...

Other tips I've ritualized, use /collapse very often when on slack, and avoid
message reactions with animated gifs. Animated things are why Slack will idle
at 5%+. Lots of them and you're going to idle even higher.

Don't leave slack open on a channel where people frequently use /giphy or post
lots of animated emojis (#random, etc). Reactions to comments with animated
gifs are the worst, because /collapse wont hide them.

In my test locally, a chat window with no animated things is idling at 0-1.5%
CPU. I just added 1 animated gif reaction to a comment and it's idling at
4-6%. It's absolutely horrible. I removed that comment and then posted using
/giphy, now it's idling at 2-3%. A Slack Helper task started to run at 12%.
Ran /collapse and both are back down to 0-1%.

Reacted to a message with 10 animated gifs, slack is idling at 9-12%. Slack
Helper is at 26.9%. Brutal. Can't /collapse to fix this, either.

\- In Advanced Settings, just turned on "Disable Emoji Spritesheet" and slack
is idling at 7-9%, Slack Helper at 27-30%.

\- In Accessibility Settings, disabled "Allow animated images and emoji" and
Slack is idling at 0-1% and Slack Helper at 0-1%.

------
qeternity
How much of all this nonsense is caused by devs using any and every JS library
out there? We've seen this problem on the nodejs side before, and it's even
more painful on the browser side. Sure, Slack almost certainly doesn't know
all 15m LOC in Chrome, but they sure as hell should know every LOC in their
JS, whether that's from in-house code or 3rd party libs.

------
JepZ
There are two totally different points mixed up in that blog post.

1\. Delivering your app with electron 2\. Writing a web app versus writing a
'native' app

Yes, delivering an app with electron might be subpar as it brings code to your
computer which it probably already has. Most Computers which are targeted by
electron apps already have a browser and lots of them have up-to-date chrome
or firefox browsers which offer features very similar to electron. So I don't
say there is no reason why one should use electron, but I urge every developer
to make their web apps accessible to browsers too and let people use their
browser if they want. Even offlines usage is no problem anymore as we have
serviceworkers in the majority (by market share) of browsers nowadays.

The second point, however, is very poorly laid out in the blog post. Web apps
do not have a general problem with performance as suggested by the article.
Maybe some are badly developed but in the end, they are all backed by the
tremendous efforts that were put into browser performance in the past years.
The question if web apps can deliver the required performance was answered by
the 60 FPS discussion a few years ago.

At the moment, the web is the only truly OS independent platform I know of.
That is a very valuable feature and one we should treat with the deserved
respect. So please write quality web apps and do us all a favor, instead of
just choosing one specific platform. Yes, react-native is an option too, but I
think it is a bit limiting to define just one framework as the one true way.

------
Tloewald
Saying that "React and friends" are the good thing you want (without Chrome)
is kind of nuts. React is insanely bloated for what it is, and it's also
highly dependent on the bloated browser (and especially Chrome). React Native
is an intermediary layer between a work in progress VM and JavaScript. So, we
can't win there.

In a sense what we really want is for the browser to be an OS-level feature so
that the browser-based-app is low cost, as is the case with chrome OS and you
could argue was Microsoft's vision with IE. This is doable today if you write
cross-browser code and wrap your web app in a platform-native web view, but
then you lose the conveniences of Electron (cross-platform APIs to solve
common problems such as menus) AND you have to deal with browser
incompatibilities. All this to save RAM and 5% Of one CPU core.

Perhaps in an ideal world we'd have a lightweight VM with nice JavaScript
APIs. The immediate problem we run into is that really fundamental UI gadgets,
such as styled text fields and canvases, are not implemented similarly on the
platforms we care about (Windows, Mac, Gnome, Android say), so we have to
reinvent that wheel and before you know it you have another bloated virtual
machine, except this one isn't battle tested and it only exists three years in
the future.

------
ryandrake
I have a couple of hobby desktop (macOS) applications in various stages of
done-ness, which, if there were a low-effort solution, I'd like to port to
Windows. Yet even with the business logic nicely separated out into portable
C++, it's a huge pain. In the 10 or so years since I've done Windows, the
development environment on that platform became totally foreign. C++/MFC seems
to be dead and buried, now we have WPF (which is also going away if I'm
reading things right) and C# and XAML and Windows Universal and all these
layers of exotic technology I now need to learn and master just to get a
simple native looking port of this thing. Screw that, I'll find something else
to work on thankyouverymuch.

I totally see the pain and the burning need out there for a way to write
something that works across the "big three" platforms that have grown more and
more distant from each other over the years. But Javascript and a browser?
Really, that's the answer? I'd even be willing to toss out my investment in
Objective-C native code on macOS if I could keep my C++ business logic. Is Qt
really viable? My understanding (again, maybe dated) is that a Qt application
looks like a Qt application, not a native application. Is this still true?

------
erinaceousjones
> Maybe we should be buying slower computers so we feel the pain. Facebook has
> been internally intentionally slowing down their office internet once a week
> to help build empathy with their users in other 3rd world internet speed
> countries (coughAustraliacough).

Yep. I've just got back from spending over a month on a ship in the middle of
the Atlantic, with two very flakey 256kbps satellite connections (capped to
like 125kbps each as well). Shared between roughly 50 people. Our policy is to
let anything through (it's a research ship, so being able to look up stuff on
the internet is a must) but aggressively apply QoS rules and caching to the
network. With the sheer amount of applications that assume they have a low-
latency high-bandwidth connection which they can open hundreds of TCP
connections on, just tweaking the firewall / bandwidth shaper / application
control is a full-time job just by itself.

First observation, relevant to Slack: Before we locked down the firewall,
Slack running on 2 laptops was by far the highest traffic application. Even
though the few Slack users just had the client open but minimized - not
actually using it. It was persistently using 20kbps, all day every day, until
we blocked it outright. What the hell other stuff does it have to do other
than download text!? Slack / other devs using Electron oughtta test their apps
on extremely slow shared internet.

Second comment, relevant to Facebook intentionally slowing down office
internet: The Mobile Facebook site (m.facebook.com) was by far the nicest to
use on our severely degraded uplinks. No timeouts, pages took under 10 seconds
to load, we didn't have to wait several minutes of blank page while another
F%$£ing web font that's Arial but with the letter T slightly more
aesthetically pleasing to download. No massively parallel loading of
resources. Good use of caching.

It struck me that a lot of our problems were problems because devs never have
to deal with that kind of crappy internet, it's not an edge case that gets
tested. It results in people unable to load important stuff like Google,
GMail, Outlook web app, and as such their products lose users. No matter how
much we tweak our network internally, even restricting the internet use to a
single computer doesn't result in usable web apps anymore. This is probably
something that we share with third-world internet; a much larger market than
our "research ship" niche.

Finally: People who put company logos in their email signatures hate other
people. Base64-encoded PNG images make one-line email responses increase in
size by like a factor of 100.

------
jernfrost
Good someone pointed it out. The web hype has gone of the rails. We got
perfectly good development tools for native development which works fine.
There are lots of cross platform GUI tool kits too. They offer a better
development experience, more dev tools and better performance and memory
utilization. It is only because the world is drowning in JavaScript developers
who don't want to learn anything else. They want to reuse their latest hipster
framework everywhere.

They go on and on how terrible desktop development is, because hey it wasn't
equally fast as JavaScript when they had never tried it. Newsflash it is slow
and hard to do things you have no experience in.

As a counterpoint, I was able to create a mobile app with native tools for
both Android and iOS in less time than it took me to create one in JavaScript.
Cross platform JavaScript is highly overrated. It really isn't all that cross
platform, often buggy and with primitive debugging and development tools.

------
zensavona
...and you know what Flash did for the web when it came out?

Allowed us to watch videos, drag and drop, consume all kinds of media and have
interactive applications on the web which were at the time totally
unachievable with JavaScript.

Is the internet's memory so short that you've forgotten how recently we have
largely switched to HTML5 video?

~~~
douche
We've just spent the last 10 years spinning to get back to where we were,
because Steve Jobs vetoed Flash support. Before that, we bailed on similar
capabilities from Java applets, and had to reimplement them.

Doubtless there's multiple technologies before my time that gave us the same
powers, but were abandoned because _reasons_.

------
luord
The other day I read a blog post that argued how "Fight for the users" should
be a core tenet for every developer. I agree; and, unfortunately, the main
undercurrent of the defense of electron, at least in this thread, is one of
almost complete disregard for the users.

Yes, most of them probably won't notice the performance impact. Most of them
also don't notice whether their applications are insecure or overstep their
privacy boundaries. It doesn't mean we shouldn't care about security or should
build hidden trackers into all the code we produce.

That aside, Electron is just an ugly idea in general (obligatory IMO). I
wouldn't want to run an entire browser just to run my own apps, next to the
actual browser.

And I say this as someone who works almost exclusively in web development and
who _likes_ javascript.

------
cdnsteve
If I wanted to make a desktop App work on Windows and macOS today, without
using Electron, what are my options to build something very quickly that also
include the benefits of Electron: self updating, app crash reporting, windows
installers, no licensing fees?

~~~
devopsproject
react

------
loppers92
Long time javascript programmers are the loser (if they never learned more
than javascript) they don't know how to programming an almost perfect program.
That is the reason why they using javascript on Desktop. The average
programmer learns just one fucking language but being a good programmer you
need at least to learn 2+ languages. That you can see the performance issues
in your stack. I started with PHP and javascript while this time I didn't care
about performance and now I'm a c/golang programmer. When I started to study c
and golang I just released how bad the whole javascript stuff is actually.

~~~
blueprint
Or maybe it has something to do with time-to-market for existing web apps, or
other loserish things. No, can't be. You must be right. Especially because you
know more than one language. After all, when you learn more languages, it
makes your words more true!

~~~
loppers92
Can you tell me why Microsoft and google trying to write either supersets or a
javascript clone to replace javascript? Because that language is an issue
itself. I don't know one good programmer who is saying that you need
javascript to make real money or that language is awesome. This language is a
bug nothing else.

~~~
blueprint
Just because that tangential point can be made to appear valid in a different
context, it does not mean that it is the proof to support your original
argument. Sounds like you're primarily just upset about Javascript and/or
front-end web technologies.

------
fknop
Meanwhile, we're still waiting for those "pro-native" people to give us better
user experience.

I agree that Electron has its issue like having multiple copies of Chromium
(and not Google Chrome).

Obviously native apps are better overall, but only if they provide a better
UX. Being a vscode user, I don't know which native editor provides the same
UX.

~~~
nonsince
Emacs provides a better UX, Visual Studio (proper) provides a better UX,
Sublime provides something close, although not as good. Slack's UX is
incredibly basic. It's a couple of steps above a basic CRUD app. There are
billions of IRC and XMPP clients ranging from toy to professional-quality, I
use IRSSI, which is admittedly basic, but I find it hard to believe that there
is no better native chat UX in existence than Slack's.

~~~
foldr
>Emacs provides a better UX

VSCode is clearly aimed at people who disagree with this statement. It's
hardly a matter of objective fact.

------
sktrdie
If you like Node.js and HTML/CSS, just have a node daemon running in the
background with an HTTP server to your app! It's just like Electron, but
without the CPU/RAM/Battery usage. You can even have binaries that stay open
after a double-click and automatically open your browser to localhost:40023
(or whatever).

~~~
madshiva
That's horrible and are not native at all.

~~~
Spivak
So it's basically no worse than Electron.

Seriously, if browsers supported an app:// URL which just ran a local site
with special privileges and allowed for some custom branding Electron would be
dead overnight.

~~~
fifafu
if they'd be giving you access to the complete node.js ecosystem maybe. With
electron you can easily integrate native c++ libaries for high performance
stuff or things that require hardware access. It's not like electron is just a
webbrowser.

~~~
sktrdie
You can do all the C++ fast stuff you want on the server.

------
discreditable
Would it make more sense to distribute electron as a dependency and allow apps
to use it? That way, instead of 10 apps requiring 10 different electrons we
have 10 apps that can use a pre-installed electron.

~~~
ascagnel_
How does an app bundling Electron in that way differ from an app using a
native embedded browser widget (other than that it can run in Chrome vs.
Edge/Safari/etc.)?

~~~
discreditable
> using a native embedded browser widget (other than that it can run in Chrome
> vs. Edge/Safari/etc.)?

I didn't know that was possible, do people do that?

~~~
ascagnel_
Not too many apps do it, but it is possible.

[https://developer.apple.com/reference/webkit/wkwebview](https://developer.apple.com/reference/webkit/wkwebview)

[https://docs.microsoft.com/en-
us/uwp/api/windows.ui.xaml.con...](https://docs.microsoft.com/en-
us/uwp/api/windows.ui.xaml.controls.webview)

------
lazyjones
I fully agree with the author, only I'd call Electron the PHP for the desktop
(it does help people get started quickly, at a cost).

There are working solutions for cross-platform native UI development and high-
performance, slim code:
[http://wiki.lazarus.freepascal.org/Multiplatform_Programming...](http://wiki.lazarus.freepascal.org/Multiplatform_Programming_Guide)

The problem is: most people don't bother learning new languages unless it's
very easy (well, Pascal is!). I hope Go will have a cross-platform UI soon.

~~~
dubcanada
What does PHP have to do with this?

And Go already has bindings for QT which is a cross-platform UI framework.

This has nothing to do with people not wanting to learn new languages, it's
just the time it takes to build an app. For you to build a QT hello world app
takes probably 20 minutes worth of downloading, setup, and coding. To do the
same you download electron, create an index.html with hello world and drag and
file into electron, bam a hello world app.

The problem is desktop development is overly complex. React and modern
Javascript make creating desktop apps using HTML/CSS with some combination of
Javascript easy.

What we need to do is find a way to create a very slim browser that contains
just an HTML/CSS to 2d context and a Javascript engine. Call it Electron slim
and release that.

~~~
lazyjones
> _What does PHP have to do with this?_

It's the RAD choice for beginners since... ca. 1997?

> _For you to build a QT hello world app takes probably 20 minutes worth of
> downloading, setup, and coding. To do the same you download electron, create
> an index.html with hello world and drag and file into electron, bam a hello
> world app._

Perhaps the first time ever, the 2nd attempt you will be equally fast.

Does a well-funded startup not have 20 minutes to test a platform?

As far as Lazarus is concerned: give it a try, it won't take 20 mins.

> _What we need to do is find a way to create a very slim browser that
> contains just an HTML /CSS to 2d context and a Javascript engine._

Christ, no. There are no slim browsers anymore and it's a pitiful environment
for native applications.

------
api
Electron is a sub-optimal solution to the fact that desktop development today
is _horrible_. You either have to write your app twice (or three times if you
want Linux) or use Qt, which limits you to either C++ or this weird
langauge/ecosystem nobody knows called Qt Quick.

Electron lets you write desktop apps that work decently well everywhere in a
language you already know.

~~~
irishcoffee
> use Qt, which limits you to either C++ or this weird langauge/ecosystem
> nobody knows called Qt Quick

Hmm, PyQt would remove the need to use c++ if that is an issue.

~~~
mi100hael
Then you have to bundle and distribute Python, which is also a huge pain.

~~~
lima
Distributing a PyQT app with PyInstaller is absolutely painless. It's a single
binary and "just works", the interpreter is automatically bundled.

------
tyler_mann
The electron bundle zipped without any extra app code is only 40MB. This is
barely any bigger than the smallest of most iOS that get auto-downloaded to
your phone every day. I haven't ever noticed any significant performance hits
and I use Slack/Spotify every day. The problem you are speaking to is the same
one that comes with any framework that is distributed. Any app using Swift 1.0
had to ship the Swift runtime with the app bundle until they eventually baked
it into the OS and allowed sharing framework versions. The same problem
happens with JVM if you've ever used a java app on Mac that doesn't use the
built-in Java runtime. Its not really a concern to me, as I think this size is
negligible and the runtime for Chrome is already the model of isolation so
this just extends that slightly further. However I'm sure the Electron folks
would be happy if you wanted to contribute to further the performance/usage
requirements of the platform.

------
_pmf_
Flash was a relatively slim runtime that enabled high performance
applications; Electron is the polar opposite.

------
ppidugu
I'm a big fan and total believer that deletion of few apps like Spotify, Slack
and Atom could improve the performance of CPU. Recently I have been getting
lags with my WebStorm for even firing up smallers commands like $ git status $
git log

I downloaded bunch of cpu profiler tools to observe how much CPU does spotify,
slack and atom and also some other fancy react, electron app built apps take.
Results are unbeliavale.....FYI: My Ram is 4GB with two 2GB slots. But after a
complete cleanup and deletion of above troublesome apps performance is just
amazing. I'm having a happy life with my WebStorm. I'm very positive that for
my future node.js apps that is running nodemon would be fine too.

RIP Electron Family of Apps .

------
poorman
I tweeted SlackHQ back in May 2016 about how Slack was using 17GB of RAM.

[https://twitter.com/NickPoorman/status/737647940026634240](https://twitter.com/NickPoorman/status/737647940026634240)

------
GrumpyCoder
I know I'm being completely naive but can all electron apps share one runtime
(sorta like one browser with multiple tabs)?

~~~
jhasse
Yes, they would simply link stuff dynamically (.so, .dll, .dylib files).

But everyone is using a slightly different version of Electron and macOS and
Windows don't have a good enough package manager, so everyone is static
linking everything.

------
dezzeus
Actually, there was a long running discussion about making a runtime mode of
Electron, in order to address many issues:
[https://github.com/electron/electron/issues/673](https://github.com/electron/electron/issues/673)

I also recently joined the discussion with a more general idea which I
(partially) expressed here:
[https://github.com/electron/electron/issues/673#issuecomment...](https://github.com/electron/electron/issues/673#issuecomment-292617796)

------
jonursenbach
I don't understand the React Native comparison. AFAIK, you can't build desktop
applications with that, nor can you build mobile applications with Electron
like you can with React Native.

~~~
t1amat
There is native support for Windows (from Microsoft), macOS, Ubuntu (from
Canonical) in addition to the first party support for iOS and Android.

~~~
mijoharas
Thanks, I was looking for a linux version.

------
01walid
That is why I do not use Slack for Desktop, and just keep a pinned tab of
Slack open almost all the time. I also tend to reduce my usage of any
Electron-based app because I want to better make use of my laptop resources in
my development workflow requirements.

I feel like I agree with most what's said there, the same would apply to NW.js
and the likes.

This should be a heads up for GUI developers to [re]consider Qt and QML. It
made real progress in the last few months. and there are some nice bindings to
it.

------
jksmith
I love how the latest generation of interest in a particular development area
like UI goes down the road of reinvention thanks to the latest in thing or
programmer prejudice. The wasted bandwidth is insane.

Somebody needs to write a variation of Sisyphus that turns the boulder into UI
development. Suggest not spreading this web dev lunacy onto desktop. The issue
has already been solved with reasonable solutions for 25 years. Desktop
development, automatic software updates, all that stuff.

------
beezischillin
The best way forward for Electron is probably to get a very thin, light core
instead of the current Chromium-based one. Even on a good 16 gigs of ram and
an i7 you feel Electron-based applications' effect on a system.

If you want a compromise between easy multiplatform desktop app development
and not wasting resources, the ideal way there may be something like
Microsoft's React-based desktop framework that they just released. (in my
opinion at least)

------
jscholes
People grew up and stopped using Flash, slowly phasing it out. If Electron is
as influencial as some comments here seem to think it is, the big players in
the desktop market will (hopefully) step up and put together new APIs and
tools which fill the gap Electron is currently filling. And they'll do it all
natively and without the terrible bloat, poor productivity and bad
accessibility that Electron currently brings to the party.

------
joeblau
I've slowly started to remove Electron apps from my workflow. I used to use
Atom, but I've switched to an paid for Sublime. The last two apps I have which
use electron are Hyper and Slack. Hyper could go, but I really like the
interface and Slack probably isn't going anywhere.

Real-time update:

I just checked Activity Monitor and Hyper is leading average energy impact
followed by Xcode. Looks like I might be switching back to iTerm this weekend.

~~~
wishinghand
What is the draw of Hyper over iTerm2?

~~~
hoschicz
It runs Javascript! You can tune and theme it with CSS and JS!

That's actually the biggest selling point. I couldn't imagine using Hyper: I
open terminals very often and waiting for Chrome to load when I need to just
run a command would be very exhausting.

------
johnnydoebk
Is there a Servo + WASM based alternative to Electron yet? Would it be more
effective?

~~~
oridecon
I won't touch these kind of apps until Servo is here, with 60 FPS animations.
If they can deliver that it will be a game changer.

I find disgusting that Electron (or even UWP apps) can't do that on PCs with
high-end hardware. A simple laggy fade effect on a modal and my eyes start
rolling to the back of my head.

------
kazagistar
So when are we gunna start seeing Web Assembly targeting Electron and go full
circle?

------
yourapostasy
Electron has its place, but I'm not entirely certain touting Electron-powered
text editors is a satisfactory success story. The success story is on the
business side, IMO: it is another write once, deploy everywhere mechanism.
Text editors are a very personal choice, but if I had to choose between an
Electron-based text editor or Emacs in say, a developing world context, Emacs
would win every time because re-purposing a 5+ year old laptop that only gets
power from a solar panel is feasible with Emacs, at the cost of a steep
learning curve. There are always tradeoffs.

Electron is very suitable for the particular contexts that it fits within, and
OP made some salient points that there are some settings where it clashes with
user demands. For the paying market that say, Slack cares about though, they
are not sensitive to the tradeoffs made to run Electron underneath to the
point that it hurts Slack's revenue to a level Slack cares about. This opens
up an opportunity for someone else to step in and take the niche that Slack
has currently declined to occupy, and that's not a bad outcome.

------
kurinj
I always thought Electron was a great idea, but it definitely seems like
something that should only be used for prototyping.

There's some excellent software that uses it, but using the Chromium browser
as a runtime is a dirty half-measure. I hope they're​ trying to pare it down
in future releases and make an effort to utilize host-OS resources.

The less your code​ is doing, the better!

------
jitbit
Just reminding everyone that Telegram (a self-funded company, also a
messenger) builds cool NATIVE clients for all platforms.

And Slack (a company valued at $4 billion) writes some intern-level Electron
apps.

This comes from a desktop dev living in Europe (also frontend dev, backend
dev, "you name it" dev).

This goes to you bay area folks, you hipster-coders, JS-framework lovers ;) No
offense.

------
feelandcoffee
I get the idea of Electron Apps having some hate for the performance. I mean
if I have to open a large SQL file (> 250MB) and compare the performance
between Atom and Sublime... well the difference will be day and night.

But there are a few differences between Flash and Electron that are not small.
I mean the first thing is, Electron is open source in a open Standard, and
have a fast development cycles to fix performance and security issues.

I think it's like a PHP situation. Electron is easy to use and sells itself as
a cheap way to build apps, so this attracts lazy developers so we have a lot
of problems, but that doesn't mean the technology is bad. But this is not a
Electron problem, I mean web pages right now are heavy and slow for nor real
reason. We need better fron-end developers.

I love VS Code, Hyper, and others, so maybe I'm biased, but I think Electron
will be a interesting option to make desktop Apps something again.

~~~
GrinningFool
> but I think Electron will be a interesting option to make desktop Apps
> something again

For most of the computing world, desktop apps have never stopped being a
thing.

~~~
feelandcoffee
Sorry I was vague, and yeah you're right they have never stooped.

I was thinking more in the Hype thing for new developers. You know like a
small Renaissance in the Desktop UI/UX deparment, you know would be cool see
beautiful desktop Apps in sites like Behance, Dribbble, etc spotting the first
places, instead of the classic App with default OS UI or weird adapted ports
of Mobile apps.

------
mk89
All nice comments from the author. Good ideas, except that most of the time
these should come from upper-management: security and performance? They are
additional features. We'll bother with them later.

Lots of developers have great ideas when they are given space, meaning when
it's in the "sprint". Some developers simply don't know about the existence of
benchmark tools, etc., but, by experience, many of them know how to google.

What matters is 1) time-to-market, 2) it's swooshy enough, 3) it does what
it's supposed to do.

I may also completely wrong: it's not always management to be bad here.
Sometimes, it's a "bunch" of people who think they are doing the right thing
(like choosing a technology instead of another). Management can't always be
blamed for it (of course not) - especially when one of the people choosing is
trustworthy.

------
andreicon
Flash used to work on the desktop as well, they had this little "projector
applications" iirc

~~~
nsebban
You could "compile" your animation as an executable file, as well as an SWF
file.

~~~
zwetan
you still can, it is called a "projector", you basically merge the Flash
Standalone player exe with a SWF into one executable.

------
sanbor
For something like a music player maybe electron it's not the best choice. But
Slack might have several features where they need to parse and show html.
Also, they're probably using webrtc for calls. On top of that, they can reuse
most of their code which is a web app. That means less bugs and if they fix a
security issue in the web app they also fix the desktop/electron app.

I wonder why the author doesn't just use the web app in chrome. The
notifications works pretty well.

Personally, I prefer the performance penalty and enjoy apps in Linux than
having great desktop apps that only work on Windows and/or Mac. It would be
great to not have to choose but we all have limited resources and Linux often
doesn't make it in native desktop apps.

------
thinkloop
Why would anyone use electron for an app that requires being constantly online
- just use the site?

------
toni
On macOS, the alternative would be to use Fluid[1]. You can build mini-apps
from a lot of websites and the footprint is very little. (No affiliation, just
a happy user)

[1] [http://fluidapp.com/](http://fluidapp.com/)

~~~
josephg
Unless I'm missing something, isn't that just wrapping the webpage in an
embedded WebView? If so its basically doing the same thing as electron, except
using Safari instead of Chrome and not giving the app any native API access.

This helps in 2 ways:

\- Safari is less of a resource hog than chrome

\- It avoids the huge 380 meg download of electron

But it doesn't solve the runtime problems. The app is still running inside a
VM (safari), so its still going to be way slower than its native equivalent
and it'll use way more memory. Also in a real browser background tabs get
throttled in dozens of ways. But I bet none of that throttling happens via
Fluid, because even background windows can be visible at any time on macos.

I'd be curious to see a quick comparison of CPU and RAM usage of slack-for-
desktop and slack-in-fluid if anyone is willing to give it a whirl. I'd do it
myself except I deleted slack after writing that blog post.

~~~
rvanmil
Slack with Fluid: 1 process, 208 MB.

Slack Electron: 4 processes, 56 MB + 355 MB + 64 MB + 29 MB = 504 MB

This is after signing in to one team, (janky) scrolling through a couple of
channels and running for a few minutes.

------
c-smile
Just in case: FreeConferenceCall / StartMeeting (
[https://www.startmeeting.com/spring-2016-updates](https://www.startmeeting.com/spring-2016-updates)
) is using Sciter ( [https://sciter.com](https://sciter.com) ) for their UI.

This app provides video communication, screen sharing and chat so is
comparable with the Slack, Skype and others.

Sciter core is a single dll of 5-8 mb in size (StartMeeting uses it as a
static library ).

Sciter does not create any processes or even threads (modulo HTTP client that
uses thread pool). StartMeeting runs the same UI on all supported desktop
platforms: Win/Mac/Lin.

------
guzgarcia
Electron as is, consumes relatively more resources than QT and it's obvious
because uses Chromium under the scene. But this is not the only reason for a
slow electron based program. Code is the most important thing in any
application and it's the primary cause of bad performance. A well writen and
optimized application will have a good performance, no matters on which
platform is based (good ones, obviously). "Electron is slow" is like "Java is
slow" right now. Do you want a probe of a well writen electron app? Check VS
Code; it's fast, it have a good performance and consumes a lot less resources
than Atom, for example.

------
shadowmint
yeah yeah. It's bad. So big. So slow. So bloated; so... What's your
alternative?

I don't see any meaningful suggestions in this article, just complaints.

You don't like how resource intensive electron apps are? Well, don't use them.
If its really a big deal, people not using the apps will inform the people
making the apps that they're bad.

That's not happening, so clearly it's not a big deal for most people.

Still... things could always be better in a perfect world.

Are you building desktop applications? What are _you_ using for it then, and
whats your cross platform perf story like? How long do cross platform releases
take you? What are you paying for your tools and tooling?

~~~
niutech
The alternative mentioned in the article is React Native, which runs on
iOS/Android/Ubuntu/OSX/Windows.

Another lightweight alternatives to Electron are: Mozilla Positron
([https://github.com/mozilla/positron](https://github.com/mozilla/positron)),
Webkit for Android/Windows ([https://github.com/daewoong-jang/webkit-
android](https://github.com/daewoong-jang/webkit-android)) and Qt Quick
([https://www.qt.io/qt-quick/](https://www.qt.io/qt-quick/)).

------
Lagged2Death
_Sure! You say. Disk size is cheap you say!_

Here's some irony for you: You really need an SSD in a modern PC - largely
because of exactly this sort of insane bloat - and as a consequence, _no_ ,
disk space isn't so cheap anymore.

------
itaysk
On Windows I was a huge proponent of Chrome's "save to desktop" feature, which
basically gave me the same experience of a native app (separate window, no
window chrome, pinnable to start and taskbar, notifications, links open in
separate window, etc). I have recently switched to Mac and I miss this feature
so much. I have found [https://applicationize.me/](https://applicationize.me/)
but it's not seamless as "save to desktop". I wonder why they dropped it from
the Mac version of Chrome...

------
fareesh
From what I understand, a barebones JS-on-desktop framework at minimum needs
blink, V8 (or equivalents) and some custom bridges to provide native APIs to
JS, right?

Which one of these is the resource hog?

------
frogfuzion
Very late to the conversation!

I'm not going to offer an opinion, but just anecdotal evidence. We don't use
Slack, but since we have Office 365 I was tasked with evaluating if Microsoft
Teams was something we should start using instead of Skype, etc.

I have advised to wait. I was seeing similar metrics to what OP is describing
where the Teams Client was using 200+ Mb of RAM (many times more than VISUAL
STUDIO).

Also the UI seemed laggy. I'm not 100% sure it is Electron, but the installer
and interface seemed as much.

------
sparkling
tl;dr: Everybody wants native apps, but nobody wants to write them.

------
tehabe
I would prefer progressive web applications, which are stored in a cache and
run in the available "browser" of the system, might it be Chrome, Safari,
Firefox, or Edge.

------
ericlnu
Good article. I've almost always had slow computers... My current cell phone
is faster than my netbook, with more RAM too. So I know the pain. So please
give everyone a break. My internet access isn't crap either, but when browsing
the web is painful to the point where the only thing running on your 'desktop'
machine is the browser, there's a big problem. Not only the machine, but
developers' mentality.

------
mschuster91
I disagree with the "flash" sentiment. The biggest disadvantage of Flash was
and is that it's closed-source. Which means it's likely _still_ filled with
exploits waiting to be exploited. Also, it could not be ported to any other
platform by the community.

Electron, on the other hand, is open source and can be built for a wide
variety of systems and CPU architectures, as well as it can be audited for
security issues.

------
skybrian
There is competition, for example between Slack's electron app and their
website, or between Sublime, Atom, and VS Code. It seems like the author of
this post doesn't trust users to choose memory usage and battery life over
other things.

I expect that's correct - they are sometimes less important to users than
other things. Emacs is tiny now, but at one time it was considered a memory
hog and people kept using it.

------
franciscop
While I love Node.js and its environment, I totally agree with this post. I
don't have the Slack client installed for this reason and only use Electron
when I write code. React Native seems like a nice middle ground: Javascript,
but _compiled_ to native.

PS, I notice that the author is using Ghost for the blog, so I am guessing the
author is in the same line (like Node.js but not Electron).

~~~
johnonolan
Not sure what line that is but Ghost's desktop app is definitely Electron. For
the record, it was also built handedly by one open source contributor (Felix
Rieseberg) and absolutely would not exist if not for Electron.

~~~
franciscop
Cleared up (I hope)

------
abalone
There actually is a Flash for the desktop. It's called Adobe AIR. And it
suffers from the same CPU/energy hog problems.

I do wish big, well-funded companies would invest is proper native apps. I get
that making it easy to crank out cross-platform apps has benefits, but is it
really too much to ask for nice native implementations of our most important
tools?

------
dangoor
There was some effort in the past to allow browsers to provide desktop app-
like experiences for webapps. Progressive Web Apps are doing similar, though
the target is very strongly toward mobile. It would be more efficient for disk
space, though likely not CPU/RAM, to just make webapps be able to work more
like desktop apps.

------
quantum_state
It seems to me that there is not much to worried about ... it is an ecosystem
... things would naturally evolve ... if electron happens to consume too much
power n conserving power is an important concern ... the developers will need
to do the right thing .. otherwise the app developed will not get used by that
many ppl ...

------
isaiahg
Lately I've been playing around with Red language and their view feature.
Easiest way I've created an interface before. The Red language is really
interesting and cool, but their view construct is the coolest. If you haven't
played around with it, it's worth about try at least.

------
artursapek
When I profile Slack on x.slack.com, it seems to be pretty good about being
"idle". The flame chart is mostly empty. As the article also points out, I
think this is a problem with Electron/Chrome. Just want to be sure the Slack
devs get their credit here.

------
woah
I understand why you'd want to wring every last efficiency out of your
computer, but I run Slack, Spotify, and many windows of VS Code on my bottom
of the line MacBook all day, frequently on battery power, and don't have a
problem. What's the big deal?

------
mydigitalself
Btw, I can tell you exactly what the "Preventing Sleep" is all about. I'm 100%
positive there's a bug in Chrome's WebRTC stack that causes that to happen.

Fire up Chrome, doesn't happen. Go on a Hangout, yip "Preventing Sleep".

~~~
bengotow
But... isn't this correct? I wouldn't want my machine falling asleep while on
a conference call, so preventing sleep is a good thing?

~~~
belovedeagle
I'm pretty sure GP is talking about CPU low-power state like OP did, not OS
sleep. They're entirely different things.

------
peternicky
This guy compares electron to react native...totally invalidated his opinion,
in my eyes.

------
crispytx
I think Electron is really great for developing an MVP. But yeah, Slack should
probably build their next version with Visual Studio and Xcode the way
Microsoft and Apple intend for people to build apps for those platforms.

------
iameli
So minimize your use of the Electron APIs. And then when someone releases a
leaner Javascript runtime, port to that, keeping 90% of your application
intact.

This would be a good idea even if Electron didn't have these problems.

------
rcarmo
I'd take this a step further and posit that JavaScript is the modern
equivalent of Ethernet (the original protocol): simple enough to actually work
despite all its shortcomings, hence doomed to success.

------
Andrex
> _I just ... don 't care about your app enough to justify running more chrome
> instances_

Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then?

Electron has won out because key apps have opted to use it and decided that
the trade-offs of user CPU and battery are worth some amount less than their
productivity as developers. Yes, there are alternatives to developing native
desktop apps in JavaScript (I'm not sure I've seen React Native used this way,
but it probably exists somewhere out there.) People opt for Electron because
it's holistic, battle-tested and easy to use.

I'm not excusing Electron's (many) flaws. There should be a concerted effort
by the team to "disable" parts of Chrome that don't make sense for native
apps, or at the very least let it be configurable. He's right, there's no
reason Slack should have access to the GamePad API (or WebVR, etc.)

My overall point is that like everything, productivity of the end-user is
always going to have some kind of trade-off with the productivity of the
developer (or more specifically, the business considerations of the company.)
Always. We don't write assembly anymore even though the apps would be a
gajillion times faster than writing Electron-wrapped web apps.

Now, complaining that Electron/Slack/etc. are CPU/battery-hungry is completely
valid and a good discussion to have, but you only get me to jump into the HN
comments once you start delivering global developer edicts with no regard for
the other considerations those projects have made.

> _The other sad fact is that even most developers have no idea that this is
> even happening on their computers. They run slack but have no idea how
> hungry it is. As a developer its your responsibility to know this stuff._

I'm not sure I completely agree here, "responsibility" is a bit heavy of a
word.

> _Users: Please complain more about slow programs. Its 2016. We carry
> supercomputers in our pockets. Its simply not ok for apps to be sluggish._

Wait, this is the first instance (edit- second, but mentioned in passing in
the previous paragraph) the author mentions "sluggishness" as a metric. IMO
sticking with measurable stats like CPU and battery life are better because
you have no idea if someone other than yourself experiences or even perceives
this sluggishness. What about non-developers at BigCo that only run Chrome,
Slack, Spotify, and Word? Would they feel sluggishness? I would guess not,
since I rarely experience it as a developer on a Macbook using Chrome, Slack
and Atom. (Things only get dicey when I start doing Vagrant stuff.)

> _Also all you web devs: Go learn C or Rust or something. Your program runs
> on a computer. Until you know how that computer works, you 're doomed._

Doomed to have a successful career? I prefer being "doomed" then. (For the
record, I do know

> _And until then get off my lawn shakes fist._

Aaaaand there we go. Maybe next time don't bury the lede? :P

> _Oh, and read this talk on the website obesity crisis. Its very funny. And
> very sad. And very true._

This is an entirely separate concern (and one I agree with.) Heavy web pages
are heavy because they are multi-megabytes to download, not because their
"installed" wrapper (Chrome) is hundreds of megabytes.

~~~
zeveb
> Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then?

I read Slack in emacs. I write code in emacs. I browse the web in emacs &
Firefox. I play music via my phone's native Google Play Music client, although
if I wanted to I could use emms, an emacs music-playing mode.

I have no desire to run some GUI-only, CPU-hungry, memory-ravenous, of-the-
moment JavaScript nightmare of a program. _My_ productivity as a developer is
hindered by those things. I have no desire to write JavaScript: I'd rather
write Lisp, or Go, or Python.

Yes, it's possible — and preferable! — to uninstall Slack, Atom, Chrome and
Spotify. Try it today.

~~~
arca_vorago
I find it interesting how many devs I have met in the last few years who seem
so tied to GUI's... as a sysadmin who lives mostly on the cli, I never
understood it.

Side note; many of said devs also used OSX instead of linux, maybe some
correlation there.

Emacs is where it's at. Really, it's my main operating system. Email, org-
mode, erc for IRC, RSS reader, editor, twitTER, eww (for some things like
documentation), dired for folder management etc. Currently working on learning
ledger.

"Using a free version of vi is not a sin but a penance."

------
richsu-ca
I get < 1% CPU usage when it is idling on a Windows 10 desktop. Will check
later on the MacBook Air and see what I get.

Memory used is 71 MB Total no. of processes: 5

Measured using Windows Sysinternals - Process Monitor.

------
ap46
You'd think they'd afford a Mac & windows developer.....

------
bartkappenburg
I even got more used Slack memory than the article's writer:
[https://imgur.com/a/AQGYD](https://imgur.com/a/AQGYD)

------
zelos
I just noticed this morning that VSCode has started causing my MBP's fans to
spin up whenever I type in it. I spent about an hour updating my MacVim setup
to replace it.

------
Marazan
Flash player was A pretty minimal download and was not a resource hog. Shitty
punch the monkey ads hacked together by people who couldn't program were the
CPU killers

------
k__
Isn't it more like Adobe Air with JS instead of AS?

~~~
tantalor
The analogy is _extremely_ weak. At best, "flash" is a stand-in for "bad
performance".

~~~
throwaway2048
The funny part is flash and air have way better preformance than html 5 and
electron.

------
rjurney
What strange things to want to be in 2017. "Desktop" and "Flash" are not
exactly hot spaces or desirable technologies.

------
jrochkind1
I didn't realize react-native could be used on the MacOS desktop. Anyone have
experience with it, is it ready for prime time?

------
tdelet
Is being "Flash for the desktop" considered a good thing?

Wasn't AIR Flash for the desktop? And didn't that already flop?

~~~
zwetan
considering Adobe MAX 2016 Resources about 8 Billions AIR Applications
installs, I would not call that a flop

see here for more numbers and details [https://discuss.as3lang.org/t/adobe-
air-by-the-numbers/476](https://discuss.as3lang.org/t/adobe-air-by-the-
numbers/476)

------
ilzmastr
How is "We carry supercomputers in our pockets. Its simply not ok for apps to
be sluggish." not a non sequitur?

------
Akira1364
I tried Hyper, listed in their "apps made with Electron" gallery thing. lol
250 megabyte fancy command-prompt

------
dethos
Good to see I'm not alone, I've been complaining about this "bloat" and
mindset for ages.

------
ndesaulniers
Electron exists to allow JS devs to bypass browser vendors slowly coming to
agreement on new features.

------
z3t4
Computer resources are like a budgets. It doesn't matter how much you get, it
will all be used.

------
wooptoo
Or you could use Chrome Apps, i.e. a desktop shortcut which opens a web page
in a separate window.

------
cerved
Spotify runs at less than 1% for me but maybe that's because I don't own a
crapbook

------
farzher
Electron is amazing. It's the best thing to happen to desktop since I can
remember.

Yeah it makes slow apps, but these apps wouldn't be possible otherwise. It's
perfect for prototyping new exciting ideas, it's fun to use, and there's no
alternative.

When your app get super popular maybe you should rewrite it in gross native
code though.

------
mananvaghasiya
Election really is flash of desktops, just use 3-4 years old hardware to feel
the pain.

------
ska
Shipping the prototype is hardly a new problem, this is just the latest
iteration.

------
carapace
"It would take 450 floppy disks to store these three simple apps."

------
dheavy
"The modern web makes me want to throw up", "Electron is flash for the
desktop", "Databases have failed the web" — wow... author does not look very
happy with the state of the web development today.

------
kruhft
It's not Flash, it's the new Visual Basic 6.

------
tastythrowaway2
I thought director was flash for the desktop?

------
johnchristopher
So. Where is the html5 of electron apps ?

------
sixdimensional
Look at WebAssembly, then consider...

------
lazarus101
In most cases it's either an Electron app or no desktop app at all. It's
simply not feasible to write native apps.

~~~
krzyk
Then don't, it's really wasteful to have webdevs write desktop apps using
Electron. I don't see a gain over using a webpage. I use slack this way and I
don't see any problems.

~~~
lazarus101
No one would bother writing Electron app if there was no demand. Most users,
(even tech savvy users) prefer using Electron Slack instead of keeping the
webapp open in a browser.

------
mmagin
No mention of Adobe Air? :)

------
murukesh_s
Better than JRE based ones. They eat far more memory and are slow and often
buggy.

------
automathematics
So many divisive opinions here, but in case anyone reads this far down, here's
my 2 cents:

\- Yes, desktop apps existed before Electron. But the top comment is right.
How many desktop apps. _NOT_ utilities but full featured apps (like Spotify
and Atom) that you loved either got swallowed up by other companies (Mailbox)
or discontinued due to "lack of use" (read: lack of profitability). I'm sure
if you dig deep you can remember quite a few...

I'm a game developer with a background in C++. But I'm developing my company's
prototype in electron. This is because I can do it myself without needing to
tap a bunch of people to help and find funding. I can bootstrap. Electron
allows this and it's incredible. I couldn't make a cross platform game engine
in a year on three platforms using native. Maybe you can and you're just a
better human/coder than me (but seriously, email me in a year with your
progress!) but Electron is allowing it.

What does this allow? This allows me to release a product (yay) and maintain a
product easily (double yay!) and when you guys don't throw money at me.... I
can KEEP maintaining it because of my low overhead. With native code and a
staff of 20 I would be forced to shut down the product.

THAT BEING SAID

If the game does well? I'm not only using Electron, I'm using React (yes, it's
a game. Yes I know, I've had this discussion. I'm crazy) so the next step is
to port it to react native on the desktop and remove the Electron dependency.
Totally doable since Microsoft is supporting it on the Univ. Windows Platform
([https://github.com/Microsoft/react-native-
windows](https://github.com/Microsoft/react-native-windows)) but macOS?
Someone's working on it but it's of course not apple
([https://github.com/ptmt/react-native-macos](https://github.com/ptmt/react-
native-macos)). Ubuntu is on top of shit though
([https://developer.ubuntu.com/en/blog/2016/08/05/introducing-...](https://developer.ubuntu.com/en/blog/2016/08/05/introducing-
react-native-ubuntu/))

I can't speak for Spotify or Slack or any of the people mentioned (yes I know
Spotify isn't using electron) but for a small company of 1 and a half people
Electron is allowing innovation and project completion in a way that nothing
else is for me. It's a great door to open to allow future optimizations. And
hey, maybe Electron will slim down too... give it time. Remember how bad
Windows development was? No? I do. But .NET has come a long way, maybe
electron will too. If not, we can always port!

~~~
castone
Why not use Unity instead?

~~~
automathematics
Mainly two (honest) reasons:

1) After years of C++ in games, I've written a lot of JS. I believe in where
the language is going and I saw an opportunity to use JS to write a cross
platform 2-D game engine with low overhead and went for it

2) Unity lends itself very well to 3D games in my experience, or 3-D games
with a fixed camera to look 2D. So this would likely lead to overhead
involving "Well, let's just render the 2-d components in 3-d" which easily
spirals into needing a modeler, a rigger, an animator, a concept artist and a
programmer MINIMUM to run the game. As it stands now I need a 2-D artist and a
single dev.

Oh, I lied:

3) I can't create a business as easily marketing a unity mod than marketing a
stand alone FOCUSED engine on one type of game. But if my plan fails, I can
still write a unity renderer for my game since most of my logic is serverside
and platform agnostic. So who knows! :)

------
aylmao
So much this.

------
brilliantcode
I don't get this article. What does the author propose instead? Cross-platform
is tough to get right and it places much burden on developers focusing on
application logic for his niche.

I don't think it's fair to label Electron as Flash just because it's doing
things in the background that Chromium authorizes. We know that Chrome Browser
and it's underlying technology is in use everywhere and anyone can open it up
and take a peek or embed Chromium in their C++ projects.

On top of that Electron takes care of cross-platform issues, and it's
performance is under constant iteration by Google, so you have a much better
chance of getting to market without having to do the plumbing work.

While I share the concern that Electron seems to spin up fan on my Macbook,
it's quite rare that I don't think much about it.

If anything, Electron improves desktop user experience by leveraging web
technology. I shudder to think what Slack will look like if it was done with
Java Swing. But in some HN'ers mind, that is the "right" way of building this
world. I see a big split in thinking amongst the demographic well marinated by
Java Is Everywhere (TM) vs Javascript is Everywhere.

------
rhapsodic
I wonder how a JS/HTML desktop using the Adobe AIR runtime would compare.

~~~
floatboth
heh, speaking of Adobe Air, I remember Air based twitter clients running
smoothly on my Eee PC 900 (single core Celeron 900 MHz!!)

------
douche
I'm surprised to see so little mention of Java as a cross-platform native app
platform. Maybe I'm just old enough to remember coming up though when Swing
and AWT were the next big thing. Nowadays, IntelliJ and it's derivatives are
all Java-based, and pretty popular and performant.

I love getting a chance to get out of web-dev world and go build some ugly
tools with WinForms from time to time. You have to do more work yourself, but
there's so much less magic involved.

~~~
MaanuAir
To continue in the Java vein: weren't Eclipse SWT & RCP supposed to be the
ultimate answer to native cross platform UI development in Java?

I had no experience with them: did they gain some adoption or recognition at
least?

Maybe all cross-platforms app solutions are just doomed to stagnate, at least
until the next hype one rises, after all.

------
jlebrech
it's a stop gap will WASM is used for both desktop and web.

------
luxuryballs
Most users will never notice this, and if some problem is solved using
Electron well then Electron solved the problem, life goes on. If you don't
like an app or how it behaves then just don't use it.

------
forgottenacc57
It's not flash for the desktop, the author just wants to say something mean
about electron cause he's angry.

The flash analogy doesn't hold in any way. "Well, flash was errr ummm BAD you
know.... and this electron thing it's BAD too .... err umm SAME AS FLASH!

Grumpy grump just wants to yell and stomp.

------
userSumo
I am a young programmer, student, front end developer/designer, with some
knowledge of languages such as java, php.

I am developing one electron app, and it is going great. And I don't even know
javascript that much. But in my case, usage of browser engine is essential,
since it has to do with rendering HTML and so on. I have less than 1000 lines
of javascript and almost everything was working after 2 weeks.

It is not that big of a project anyway, but from the begging I knew that it
should be fairly easy and doable.

In fact, I can imagine that I could do so many kinds of apps with electron,
and I can easily see how I would approach it.

Let's say music player. No problem. I believe that electron can easily play
media, and it would all look great. Or some productivity tool, or note taking
app. Working with files, editing text files, even viewing documents like .pdf
would be easy (would just use some plugin). Or even embedding youtube videos
in notes would be easy. And all that with easy control of layout and great
rendering of fonts and images, plus animations.

With little knowledge of front end stuff, and some general programming
principles, you can already see how you could build app on the top of
electron, which is a platform everyone here knows without even trying. It
makes me feel kind of powerful to be able to do such a nice apps myself.

~~~
userSumo
but if there was something exciting like red-lang with easy to do custom UI (
if needed ) and with some ecosystem around it, i would definitely look into it

[http://www.red-lang.org/](http://www.red-lang.org/)

------
eru_melkor
Holy shit! Are we behind reddit on this?
[https://www.reddit.com/r/programming/comments/64oqaq/electro...](https://www.reddit.com/r/programming/comments/64oqaq/electron_is_flash_for_the_desktop/)

