
Electron 1.0 is here - alanfranzoni
https://github.com/blog/2167-electron-1-0-is-here
======
grinich
Our team at Nylas has been incredibly lucky to build on the shoulders of the
folks at GitHub and I'd just like to thank Kevin, zcbenz, Jessica, and their
entire team. They've been awesome to work with and super supportive of this
new community.

Our early prototypes of Nylas N1 were built on Angular in the browser, and
then Adobe Brackets, but we couldn't really get it to a level that felt great
and worked offline. It wasn't until we decided to fork Atom (the previous base
of Electron) that we started breaking past the "uncanny valley" of wrapped
webviews and discovered an application stack that allowed quick cross-platform
deployment alongside native code modules.

After building on Electron/AtomShell for 18 months and seeing the community
grow, I can definitely say there is something really special here. We've still
got a lot of work to do on N1 (email is hard!) but we're confident Electron is
the right platform for this type of extensible app.

A secondary reason we open sourced N1 was to serve as a reference
implementation of a large Electron app. There still isn't a great resource for
"best practices" when creating complex Electron apps with lots of moving
parts. Now that we've hit 1.0, I think it's time to change that!

If you have a free afternoon, I _definitely_ recommend playing around with
Electron. It will likely change your outlook on the future of desktop
software. :)

~~~
kuschku
Well, it still doesn’t feel native on linux.

You get 2 window bars, and 2 toolbars, nested in each other.

[http://i.imgur.com/2C769ex.png](http://i.imgur.com/2C769ex.png)

It might be "best practices" on Mac, maybe even on Windows, but it definitely
looks out of place on Linux. Especially when compared to native Qt apps.

~~~
smpetrey
Maybe, open an issue? It is still a work in progress after all. Lot's of open
issues for Linux so far. [1]

[1]
[https://github.com/nylas/N1/issues?utf8=%E2%9C%93&q=is%3Aiss...](https://github.com/nylas/N1/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+linux)

~~~
kuschku
I had 4 open issues about several topics, all closed as "not enough people
affected" or "WONTFIX".

------
etatoby
I'm happy and grateful for any and all open source software, because it
enriches everybody, well beyond the scope of its creators. But someone has to
say it:

Electron is the cancer that is killing desktop computing.

It all started years ago with Firefox, whose interface itself was built using
web technologies, in a "brilliant stroke." DOM, CSS, Javascript... maybe not
HTML per se, but an XML substitute, and so on. I dare anybody say that
Firefox's interface has ever felt as fast as IE, Chrome, Opera, or Safari (on
Mac.) It never did and still does not.

Then someone at GitHub had the bright idea to take this "winning" concept and
apply it to a developer's text editor, of all things! I still cannot fathom
how Atom can have more than 3 users. Every time I've tried it, I've ditched it
after 30 seconds. Slooooooooooow!

Fast-forward to 2016: now I see new Electron apps popping up every other day.
Even something as simple as a text-only WhatsApp IM client, which could be
written in a dozen of C++ files, is a bloated monstrosity that eats RAM for
breakfast and contains an entire Node.js interpreter and a Webkit layout
engine.

Cancer, I say!

Kill it with fire!

~~~
nilliams
This attitude seems ignorant of the facts and the unfortunate state of desktop
development.

Perhaps the cancer is the fact the desktop development community has had
decades to settle on a decent cross-platform 'native' toolkit and completely
failed.

Perhaps the cancer is 'native' developers spouting 'native is better'
hyperbole, ignorant of the fact these supposedly better 'native' toolkits have
been web-influenced for a long time.

\- XAML from C#/WPF land being strongly influenced by HTML and CSS.

\- Android XML being strongly influenced by HTML and CSS.

\- Qt Quick being strongly influenced by JS and CSS.

\- GTK+ embracing JS and CSS3.

\- Everything else being awful procedural C++. Good luck maintaining that.

And all have massively inferior developer tools than Chrome devtools and/or
far worse abstractions for the scene-graph/tree of elements than the much-
derided yet very powerful DOM.

Native desktop is a mess. I'm glad we're seeing Electron expose it for the
joke that it is.

You can hate web dev tech, but you can't claim that native desktop options are
better. I won't be building apps 3 times or using any of these useless 'cross-
platform' dev kits anytime soon, when I can build the same thing in Electron
in a fraction of the time, and leverage the undeniably huge JS and CSS
communities.

Also very tired of seeing devs use weasel-words like 'bloat' and neglect to
put it into any context, like the fact that on the desktop 1. it ain't bloat
if filesize is cheap, and 2. said filesize is comparable to the most capable
cross-plat options you're supposedly arguing for (see Qt Quick).

Edit: Softened, expanded.

~~~
millstone
WinRT isn't embracing JavaScript because JS is so great, but to make the
platform more attractive to web developers. Same with the HTML/CSS-style
toolkits.

HTML/CSS, and Chrome tools, are definitely the better part of the web. The
really terrible stuff are the JavaScript APIs. Of course there's JavaScript
itself, which is gross. But there's no APIs for basic questions: where is the
mouse pointer now? And is the mouse button down? How many screens does the
user have? What is the width and height of this text? [1] Or anything Unicode-
related. Or any sort of precise, pixel-accurate drawing. Web programming means
resorting to terrible hacks all the time.

Maybe Electron has its own JS APIs that fix those issues, I don't know. But
compared to making a traditional web app, it's a relief to use a real desktop
API that actually has coverage of desktop capabilities.

[1] See the ridiculous lengths Atom went to just to figure out how wide a
character is: [http://blog.atom.io/2015/10/29/atom-1-1-is-
out.html](http://blog.atom.io/2015/10/29/atom-1-1-is-out.html)

~~~
nilliams
> WinRT isn't embracing JavaScript because JS is so great, but to make the
> platform more attractive to web developers.

That may be true for WinRT, but I did not mention WinRT. XAML/WPF were around
a long time before that.

> Same with the HTML/CSS-style toolkits.

Not sure what you're referring to but no, I don't believe that's true for the
projects I mentioned.

Your complaints with JS APIs are warranted, but won't apply to 90+% of apps.
Still seems like an overall win to use Electron/NW.js over any other option
currently.

------
Philipp__
While there are many awesome things about Electron, I still give native
desktop app advantage. Native apps just _feel_ better. It's all those ms
(miliseconds) here and there that in the end make huge difference. Still best
showcase is Sublime v Atom. I use Atom, because it's free and open-source, but
when I fire up Sublime from time to time, it is amazing how better it feels.
It feels right! Guess like everything else in life everything has it's good
and bad sides.

~~~
threatofrain
I wish to go on a slight tangent and offer Visual Studio Code to your
comparison, because while it's still slower than Sublime but faster than Atom,
it also offers unique features that I predict won't be replicated by Atom /
Sublime for awhile, if ever.

~~~
BobTheCoder
Code just looks ugly and Atom looks amazing out of the box. Possibly not the
most important feature, but it does matter quite a bit I think.

~~~
Philipp__
I was always afraid to say it out loud, but look of text editor really matters
to me. That's why I can't return to Sublime, because Atom got me used so much
to that Material + One Dark combo that I can't go anywhere else now. My Vim
config got quiet big over the years so now it looks really really nice, and
uniform.

I think, because I spend a lot of time staring at text editor/terminal I
really want it to look satisfying and pleasant to my eye. It is not main thing
that decides, but definitely is up there.

------
StevePerkins
I can definitely see a niche in which Electron serves well.

However, it seems weird that when talking about mobile apps, the
PhoneGap/Cardova "web wrapper" concept is derided as awful compared to native
code or maybe cross-plat frameworks. From my anecdotal experience, those same
people tend to think that Electron or NW.js are the greatest thing since
sliced bread.

Electron is PhoneGap for the desktop. That's not necessarily a bad thing or a
good thing, it's just a thing that makes sense in certain use cases and not
others. The fact that web wrappers have different levels of "street cred"
across mobile/desktop contexts feels more subjective than objective.

I suspect it's simply a matter of the younger crowd having more exposure to
native mobile development, and little or no experience with native desktop
development... so this discrepancy reflects those different comfort levels.

~~~
untog
> the PhoneGap/Cardova "web wrapper" concept is derided as awful compared to
> native code

Yes, but mobile and desktop are quite different. For one, desktop has a lot
more power - one of the biggest issues with PhoneGap etc. is that it's just
_slow_ , and, particularly, single threaded. That doesn't matter so much on
desktop.

Also the other complaint is that PhoneGap doesn't use native UI components.
Desktop has a huge variety in UI compared to mobile (think Microsoft Word vs
Photoshop) - another "not native" format isn't quite as notable.

More importantly, though, is that _developers_ hate PhoneGap and the
experience it provides. I'd be interested to see the results of a survey where
normal users are given a PhoneGap app and asked to point out what's wrong with
it. I suspect many would think it's just fine. Not great, but fine. Similarly,
if you asked anyone about the Slack desktop app I suspect they'd say it's
fine.

~~~
royjacobs
I am genuinely curious, but why would you consider it not as important on a
desktop to be fast or easily multi-threaded?

Especially the latter is really puzzling to me.

~~~
wlesieutre
And this isn't just desktops. We're also talking about laptops, and Electron
based software _completely_ disregards battery life concerns.

Chrome (technically not Electron but it includes all the same problems) and
Spotify gobble down enough power that I make a point of not using them if I'm
away from my power cord.

Here I thought the gradual year-over-year percentage increases in battery
technology were going to get us better battery life, but it turns out we'd
rather just write shittier software.

~~~
oceanswave
IRT Battery life concerns - Electron utilizes OS based power management and
will auto-sleep the app.

What other battery life concerns do you have that are automatically solved by
another framework?

~~~
wlesieutre
I couldn't tell you precisely _why_ Chrome has comparatively bad battery
usage, but it does:

[http://blog.getbatterybox.com/which-browser-is-the-most-
ener...](http://blog.getbatterybox.com/which-browser-is-the-most-energy-
efficient-chrome-vs-safari-vs-firefox/)

Even if you just leave it sitting in the background with one tab open, Chrome
uses more power than Safari. I'm currently measuring an "Energy Impact" of 1.9
vs 0.1 for that test.

I don't have any hard data for Electron apps, but my experience is that
they're worse than their native counterparts. For example, Spotify (playing
offline files) vs iTunes.

------
bengotow
I've been building on Electron for the last 18 months (@Nylas), and it's
really impressive how far it's come in the last year.

Coming from native Mac OS X development, Electron is an breath of fresh air.
There's an incredible amount of energy and momentum in the web development
community these days, and things like Flexbox, ES2016, React, and ESLint make
it possible to ship fast and iterate quickly. Who would have thought
JavaScript would be achieving what Java/Swing set out to do in the 90's?

I've had a chance to work with the core team on a handful of bug fixes and new
features, and they've been incredibly kind and welcoming. I think Electron
will go far as an open source project, and I'm excited that GitHub is growing
it beyond Atom.

If you're in the SF Bay Area and interested in learning more about Electron,
there's a meet-up coming up later this month! [http://www.meetup.com/Bay-Area-
Electron-User-Group/](http://www.meetup.com/Bay-Area-Electron-User-Group/)

~~~
sievebrain
I would argue that what Java/Swing set out to do in the 1990's was done
already. You can ship Swing apps and make lots of money selling them to lots
of people - JetBrains being a case in point. You don't get many people
starting new projects that way (and Swing has been replaced by JFX anyway),
but this seems more related to fashion than the merits of the various
technologies.

The energy and "momentum" in the web community is something that has been
discussed extensively on HN and elsewhere, so I won't comment on that. Suffice
it to say that motion is not always the same thing as progress.

~~~
blub
Let's be fair and admit that the typical Java app doesn't have all the
features of a modern Electron app.

For instance, I downloaded Atom and after starting it, it wanted to connect to
atom.io and then Google analytics. Now Google not only knows which web pages
one visits, but also which apps one uses. Electron is win/win - for web
developers and Google, of course.

~~~
sievebrain
Hah. In fairness though, most apps do want to report back usage stats and
other telemetry these days. That doesn't sound entirely unreasonable....
though it's conventional for desktop apps to ask first (perhaps one reason
people developers like web apps, the social conventions are different)

~~~
blub
It is not allowed in the EU to gather data without informing the user and (in
some cases) requiring opt-in. I think this is a very sane decision, even if it
makes developers uncomfortable, because it is a privacy issue.

It is not usual to gather telemetry on the desktop, with perhaps the exception
of some AppStore apps. Of course now that Microsoft got greedy and web
developers are starting to develop desktop apps, we might see a different
trend.

~~~
matt4077
That depends on the data. I believe Atom uses the analytics privacy feature
that deletes the last digits of the IP. That way it doesn't fall under the
privacy directive.

------
lpsz
Am I the only one unhappy with the trend of moving toward web-wrapper
applications? As a developer, I also love the idea of cross-platform, and of
more elegant frameworks, but it pains me to run things that are slower or hog
the battery.

* JavaScript-heavy Spotify now vs. Spotify a few years ago

* Atom vs. something like Sublime Text

* Or, Slack that takes the cake especially if you log in to multiple Slacks.

It's cool for developers. It's not cool for the users.

~~~
oceanswave
Here's the thing: What's the #1 application that people use today on their
desktops? Browsers.

There's a really high chance that you had another browser process open that
was dedicated to writing your comment. Mobile included as the HA app is a
Cordova-based solution.

But you feel compelled to say that thing that you used to accomplish your
reading and commenting task was somehow slower and hogged your battery.

It got the job done didn't it?

Further, what's the #1 tech that some really smart people are focused on
optimizing because of its usage. Yeah, again, the browser.

Show me another standards-based general UI stack that has had as much man
hours dedicated to optimization... AWT/Swing/JavaFX? laugh. WPF, also really
slow. WinForms? Not a lot of dev going on there at the moment.

~~~
kedean
The problem with Electron isn't just the fact that it's browser based. It's
that it's a different browser. If I run slack, spotify, atom, and an actual
browser all at once, my computer is going to slow to a halt. What electron
needs is some way to run in concert with my actual browser, or some kind of
hub process that coordinates them to reduce the absurd memory and disk space
footprint.

~~~
oceanswave
generally Chrome and IE/Edge spawn separate processes per tab for isolation,
but will sometimes group them based on some conditions. On the flipside I'd
hate to have some 3rd party program bring down my browser.

So I get what you're saying, but the worst case is that your browser will do
the same thing for each tab.

Software like Excel which will spawn a different instance of Excel for each
workbook, even though it could theoretically be a single process... so it's
not like native apps are a panacea in your argument.

------
ksec
I know this is not really electron's fault, but could there be way to shrink
these run times to a lot smaller?

Like Whatsapp App on Desktop you literally have a 60MB download and 200MB
install just for a screen that is EXACTLY the same as the Web Version of
Whatsapp.

While I dont expect all the apps are like CCleaner or the old uTorrent which
is only a few MB in size, 200MB is just redicously large.

~~~
marcosscriven
Not trolling, but do you find 200MB is actually a burden? Here in London cable
or fibre links means that downloads in seconds.

EDIT - Ok, sorry, it seems quite a few people do have pretty horrendous
bandwidth issues.

~~~
keeperofdakeys
Personally I think frameworks like Electron lead to huge bloat in terms of
download size, disk space, and system ram. However there is no doubt that it
increases the accessibility of developing applications for multiple platforms.

I think the following is a great narrative on why it can matter though:
[http://blog.chriszacharias.com/page-weight-
matters](http://blog.chriszacharias.com/page-weight-matters)

~~~
drivebyops
I have found these nodejs desktop apps to use less RAM than other more
traditional Toolkits like Qt. I can live with more disk space being used if it
means better memory usage

~~~
blub
Extraordinary claims such as these need at least some sort of evidence. It
does not make sense intuitively that a browser engine has a lower memory
footprint.

~~~
keeperofdakeys
It could be that it's the other programs that are also bloated.

------
gbugniot
"Electron has lowered the barrier to developing desktop applications". Nope, I
don't think so. Perhaps for web developers.

For non-web developers, there are already well-suited technologies to develop
desktop applications: Swing, Qt, Cocoa, GTK, WPF/WinRT, and so on. Maybe
theses technologies seem less sexy but there are here from the beginning to do
that kind of job.

Please, use the right tool for the right job.

~~~
bengotow
I think it's easy to argue about tools, but take a look at popular desktop
apps these days: Slack, Atom, VSCode, Spotify, WhatsApp Desktop... they're all
built on Electron or the Chromium Embedded Framework. It seems the community
has spoken, and no longer considers Java / Qt the right tool for many jobs.

~~~
sievebrain
Comparing the developer experience between them makes it hard to argue that
HTML/CSS/JS are the right tool for building GUI apps. The awkwardness of the
web 'platform' is just huge, in comparison, even ignoring the performance
issues. Atom and VSCode, for instance, have a long way to go to catch up with
the real Visual Studio or IntelliJ.

The real reason you're seeing apps based on Electron these days is that it's
easy to hire HTML/CSS developers. That doesn't mean these are good platforms
though. I remember when the bulk of apps were being written in Visual Basic
because it was easy to hire VB devs (lots of people learned VBA via MS
Office).

~~~
oceanswave
"Atom and VSCode, for instance, have a long way to go to catch up with the
real Visual Studio or IntelliJ."

You're right. They need to catch up to using 5.8 _GB_ for Visual Studio and
480MB for IntellJ to start. :)

------
greenspot
My biggest gripe with Qt is HiDPI support which was introduced just 6 months
ago, so quite late. It feels cumbersome compared to HTML/CSS which have native
HiDPI support built-in for years. Also the implementation in HTML/CSS is
straightforward. You don't need to think about it a second, it just works.
Actually this is my number one feature of web tech, it's HiDPI ready and
websites and apps like Slack look always slick, crisp and clear, on any
platform.

With Qt, just watch this 30 minutes presentation about Qt and HiDPI, while ok
there are some parts which unnecessarily complicate matters:
[https://www.youtube.com/watch?v=2XPpp4yD_M4](https://www.youtube.com/watch?v=2XPpp4yD_M4)

------
fsloth
What do you think the suitability of Electron is for software that is designed
to provide revenue with per seat licences and no service component? I.e.
'traditional desktop app'. It seems to me, given how easy it seems to be to
copy and modify an Electron application a third party could always copy an
application, whitewash it and capture a portion of the market.

The counter point to this is that ownership of the developer brand and
distribution channel is which will always drive sales. I'm not sure which
aspect is more important when planning a technology platform and revenue
model...

~~~
grinich
People can crack/clone desktop apps regardless of the language they're written
in. You can certainly add the same types of protection to Electron apps that
might be found in traditional native apps, but it just makes things harder and
not necessarily impossible.

One of the benefits of Electron is the updater system, which allows you to
release updates pretty frequently. You could tie that to the paid user account
and just innovate faster than people cloning your app!

Electron also uses a specific binary packing system (ASAR) to ship app code,
so cloning is also a bit harder than just copying a bunch of JS files.
[https://github.com/electron/electron/blob/master/docs/tutori...](https://github.com/electron/electron/blob/master/docs/tutorial/application-
packaging.md)

~~~
tehno
Cloning is as simple as "npm install asar && asar extract app.asar", modify
what you want and "asar pack" again. So the packing system is really no
protection in itself. See
[https://github.com/electron/asar](https://github.com/electron/asar)

------
porker
Congratulations on reaching 1.0. Electron is really interesting, but until
memory usage can be curbed, it's going to be a limiting factor.

I have been going back and forth with Slack over their desktop client; on
Windows when signed into 5 groups it uses 1GB RAM. For a rich-chat client.

And if you're thinking "But RAM is cheap these days" \-- well yes it is, but
by the time you've got 15 Chrome tabs open, a Jetbrains IDE and 3 VMs, plus
assorted other software running, 16GB disappears very fast...

------
albeva
Slow, sluggish, resource hungry and looks alien everywhere. Yeah right.
Progress ... If there is one thing its done is lower standard for native
applications everywhere.

~~~
spiderfarmer
Just like websites. They'll never succeed. /s

~~~
blub
Quality of implementation has some correlation with market success, but
ultimately there are many variables involved.

Just the other day someone had detailed that they have a business based on
Delphi with some ancient database. Can't be rewritten, but it brings in
revenue.

~~~
TeMPOraL
> _Just the other day someone had detailed that they have a business based on
> Delphi with some ancient database. Can 't be rewritten, but it brings in
> revenue._

And quality-wise it's probably better than any alternative "cloud-based"
solution they could buy these days.

------
jokoon
Burn this.

Instead, please, can any investor just hire any computer science PhD (who
eventually specialized in compiler engineering), and tell him to work on
PREPARSED or COMPILED HTML, and make a browser module out of it, for the sake
of speed and memory footprint?

PLEASE. I BEG YOU. DON'T EVEN TAKE CREDITS FROM ME. IT IS SO WE CAN SAVE THE
WORLD.

------
e0m
Think about how much time people spend in front of 24" screens with a
keyboard. "Desktop", or whatever that evolves into, is overwhelmingly where
real work still gets done. For as critical as that environment is in the
modern workplace it's historically been drastically underserved by this
community.

Yes, there are a lot of tools like Swing, Qt, Cocoa, GTK, WPF/WinRT, but their
development communities are much smaller than the javascript/web ecosystem.
They also create enormous portability problems, particularly in an environment
(especially in the business world) so heavily dominated by Windows machines.

This community is acutely aware of what happens when the barrier to entry is
lowered and the development tooling improved. The tooling that Electron
provides via Chromium is also something that should not be understated.
Chromium's dev tools are remarkable and improving every day. Few other
ecosystems, especially old desktop ones, have debugging environments as rich.
The painting performance / profiling tools alone go to great lengths to
keeping everything running at 60fps. Furthermore modern CSS layout engines
like FlexBox give you an enormous head start on a notoriously difficult
problem and is a joy to work with when you don't have to worry about browser
compatibility.

I will admit, the getting-started cost of Electron is high. Shipping all of
Chromium and Node is no small feat and frankly probably not suited for a minor
utility. However once an app crosses even a modest level of sophistication the
benefits of this environment are definitely worth it. There are also several
specialized tasks that Node probably isn't suited for. Luckily, since you have
full process control and the ability to compile native modules any additional
specialized task can be run on the side.

The past 18 months working with Electron at Nylas have been some of the most
enjoyable development experiences of my life. Much of the crap that frustrates
people out of web development (compatibility issues) go away. Being able to
build an app at the core of people's day-long experiences is deeply satisfying
and something I'm indebted to the Electron team for.

If you're in the Bay Area and still have questions or are just curious, come
join us at the Electron Meetup on Wed May 25: [http://www.meetup.com/Bay-Area-
Electron-User-Group/events/23...](http://www.meetup.com/Bay-Area-Electron-
User-Group/events/230303142/)

------
staticelf
One issue I have with Electron is that if I put my computer to sleep without
restarting it and have all the applications up all the time, Electron apps
gets very slow and sluggish and lags very much. Slack is a good example of
this.

I have to restart my computer every now and then in order to keep using Slack
and Atom, because otherwise it lags so much. I don't know, I think I prefer
UWP apps instead.

~~~
k__
VSCode doesn't seem to suffer from this and isn't it also running on Electron?

Maybe it's more of a memory leak thing that TypeScript doesn't have.

~~~
staticelf
No idea, don't use it. But the two applications I use that I know use Electron
suffer from the issue I am experiencing.

------
colordrops
My team is trying to use Electron to build and deploy apps for Linux, Mac, and
Windows, but running into issues with the Mac build. Getting a dmg built on
Linux (our build server) is apparently not trivial. Is there a docker image or
some other project that wraps all the dependencies up to build Electron apps
for all major platforms?

~~~
grinich
We've open sourced the build scripts for Nylas N1, which actually just builds
on Travis/AppVeyor for Windows, Mac, and Linux. We originally had an internal
Jenkins server doing the builds and it was way easier to just configure hosted
services to do this for us. It's free if your project is open source, and you
can do some clever things to keep signing keys private and include private
source paths during compilation.

Here's the grunt task for Mac DMGs. The parent directory has a similar script
for Windows and Linux (and lots of other utilities too).
[https://github.com/nylas/N1/blob/master/build/tasks/mkdmg-
ta...](https://github.com/nylas/N1/blob/master/build/tasks/mkdmg-task.coffee)

------
mherrmann
Electron is really cool, unfortunately its startup performance is slow
(several seconds on a ~2010 machine). That's why I had to pick Qt for a file
manager I'm launching... ([https://fman.io](https://fman.io))

------
twotavol
Every Electron application I've used has been sluggish and straight up
pathetically slow compared to any native counterparts. I think there are two
reasons its picking up steam:

* Your can now make your web devs (HTML/CSS/JS etc) do your application development as well

* General popularity of web development is exploding

* There's no comparable free, permissive native framework. The closest thing is Qt and its LGPL. No one wants to touch the GPL.

------
kristianp
It would be nice if Electron could enable cross-platform apps, written in
languages other than javascript, that compile to native for the back end and
to javascript for the front-end.

~~~
calsy
The big thing with javascript is that it has truely become a platform
'agnostic' language. It covers all bases in frontend (web, mobile and desktop)
and backend development.

No other language is in such a unique situation, so its wise for Electron to
be JS centric moving towards the future.

~~~
vesak
Why does it happen so often that the technically weak languages get picked and
become widely used? Why Javascript? Is there something about technical
superiority that makes less business value?

~~~
bengotow
Honestly, I think JavaScript was just in the right place at the right time. If
you haven't seen ES2016 yet though, it's really worth a look. Electron
JavaScript isn't the jQuery crap of the 1990's. It's got destructuring
assignment, classes, template strings, let / const, you name it...

[https://github.com/lukehoban/es6features](https://github.com/lukehoban/es6features)

~~~
T-A
I feel compelled to point out that jQuery 1.0 was released in August 2006:
[https://en.wikipedia.org/wiki/JQuery#History](https://en.wikipedia.org/wiki/JQuery#History)

------
webXL
I just came across a great Electron app called Nativefier
([https://github.com/jiahaog/nativefier](https://github.com/jiahaog/nativefier)
[https://news.ycombinator.com/item?id=10930718](https://news.ycombinator.com/item?id=10930718))
last night. It's a super easy way to make dedicated browsers & launchers for
certain web apps. (very anti-web, I know)

My first use case for it was making a dedicated Amazon Video client for my
wife's laptop (although Nativefier doesn't have one of the necessary plugins)
so we can have our regular Amazon accounts separate without switching
credentials all the time. But I can think of a bunch more for this

------
john_reel
Electron has gotten a lot of criticism for being bloated. Are there any good
alternatives for making desktop apps that are scripting language based? I’d
especially like to use Lua(JIT), but I’m not aware of anything anywhere near
as reliable, cross-platform, easily deployed, and easy to build interfaces in
as Electron. I’m not the biggest fan of the JS and/or the JS ecosystem, but I
would love the speed, lightness, and convenience of another language (just
look at how fast and lean Lua with LuaJIT is!) with the power that some JS
tools like Electron have to offer.

~~~
jventura
For Python you have PyQt
([https://riverbankcomputing.com/software/pyqt/intro](https://riverbankcomputing.com/software/pyqt/intro))

------
crisnoble
Is there a "built with electron" type directory out there somewhere?

~~~
Zirro
[https://github.com/sindresorhus/awesome-
electron](https://github.com/sindresorhus/awesome-electron)

------
calsy
This is awesome! I wish I had something more constructive to say but thats all
I could think of at the moment.

------
stuaxo
Are there plans for electron with the servo browser ?

~~~
Crespyl
I believe the plan is for Servo to support the Chromium Embedded Framework
interface, so theoretically it could be a pretty straightforward drop-in
replacement.

~~~
stuaxo
I think it already does support CEF to an extent - no idea if it's enough

[https://blogs.s-osg.org/servo-the-embeddable-browser-
engine/](https://blogs.s-osg.org/servo-the-embeddable-browser-engine/)

[https://github.com/servo/servo/labels/A-embedding](https://github.com/servo/servo/labels/A-embedding)

------
mixmastamyk
Interesting, reminds me a bit of XUL and XULRunner from the old days, which
sort-of failed. What does this have in common, or is different this time?

~~~
simonw
Today's HTML, CSS and JavaScript is a much more powerful and mature platform
than XUL ever was.

The number of developers with the skills to build a native-quality interface
using the web platform is hundreds of times the number of developers who ever
learned XUL.

Using HTML and CSS for desktop UIs is a proven pattern now. Even Apple used
WebKit views for iMessage on OS X.

~~~
mixmastamyk
Yes, I've even done it myself a few times over the years. But one thing I
don't like is that most don't follow the OS theme. I'm not a fan of every app
having its own, ala "skinz."

------
iamcreasy
Electron looks like it has for both worlds, but what is the drawback of
this(kind of) system(s)?

~~~
Xiol
You have to write Javascript.

~~~
dchest
Or Go, Dart, TypeScript, PureScript, Elm, CoffeeScript, Oberon, or any other
language which can be compiled to it.

~~~
oceanswave
Or, create a C or C++ NodeJS module and use it from your JS, or interop using
EdgeJS or python-shell

------
theknarf
I like the idea of making desktop apps with html, css and JavaScript. I just
wish that Electron/Atom wasn't so horrible slow. It shouldn't take me more
time to open up a desktop app than a webpage.

------
hs86
Would a dynamically linked, system-wide Electron installation help with the
extensive resource usage of Electron apps? It would decrease the installation
size but what about the runtime performance?

~~~
oceanswave
not sure where the red herring came from. VS Code uses less system resources
than a blank excel document for me. Opening up another tab in a browser can
spawn another browser process, which is done for isolation.

Same example, 142MB is the footprint for VS Code. VLC is bigger.

Where is this "extensive resource usage" that people seem to be concerned
about even apply to Electron? Metrics?

A similar paradigm would be to create a Chrome Packaged App, but you're going
to still have the same resource utilization as another browser tab.

------
Longwelwind
I find it more comfortable to make a GUI using HTML/CSS, but I wish I could
use a more modern and more reliable language than Javascript.

Is there an equivalent to this but with Python or C# ?

~~~
oceanswave
Using a similar technique, you could use [http://coherent-labs.com/dotnet-
browser-controls/](http://coherent-labs.com/dotnet-browser-controls/) but
you'll also pay out the nose for it.

~~~
oceanswave
Oh, forgot about
[https://github.com/cefsharp/CefSharp](https://github.com/cefsharp/CefSharp),
but theoretically anything that uses Chromium Extensibility Framework (CEF).

------
marcosscriven
One of the things I really like about Electron apps is they _look good_
consistently across platforms, which is something I don't often see for cross-
platform apps.

QT seems to be the other major cross-platform framework, but I've never seen
one that looks good IMO.

Would be very curious if any fellow HNers could point to good alternatives
(preferably C++ based, but as I allude to, I'd compromise by using something
like Javascript if it meant a better real world outcome for the user).

~~~
albeva
"looks constantly good" is debatable. I find that it looks generic and web
like. It has none or very little native look & feel to it. Coupled with being
slow, resource hungry long loading times ...

~~~
marcosscriven
To put it another way, can you name any applications you feel do cross-
platform right? Are there any example you feel tick all the boxes for you, and
do they use any framework?

~~~
Mister_Snuggles
It's far from perfect, but Corel AfterShot Pro[0] is an example of commercial
software that uses Qt and ships for Linux, Mac, and Windows.

Some of the imperfections I notice are:

* The options dialog has a lot of things that just look "different". The controls are native, but the way they're positioned, etc, clearly isn't. The Mac has a lot of common things, like which order the Yes/No/Cancel buttons would appear in a dialog box, that aren't done the same in AfterShot.

* Being a photo management/editing application, it naturally uses a dark theme that looks out of place everywhere. Adobe Lightroom and Apple's now-discontinued Aperture both do this. It seems to be a normal thing with this type of application.

* On Linux, the window decorations come from AfterShot, not from the window manager. It also has the Windows close/minimize/maximize buttons.

* On an old-enough Mac, the integrated GPU doesn't provide the OpenCL stuff that AfterShot requires. This causes it to crash at startup, whereas a real Mac application would tell the OS to fire up the discrete GPU.

* I seriously doubt that it exposes any of its API to AppleScript/COM/DBUS, but I haven't checked. I know that it doesn't register itself as a source for the system-wide photo browser on the Mac (as an example, Insert > Pictures > Photo Browser in Microsoft Word on the Mac will show your Aperture, Photos, and iPhoto libraries as whatever structure they have in that application, not just as files on disk).

[0] [http://www.aftershotpro.com/en/products/aftershot-
pro/](http://www.aftershotpro.com/en/products/aftershot-pro/)

------
felixrieseberg
If you're based in San Francisco, come to our next meetup! We'll have a bunch
of people working on and with Electron there.

www.meetup.com/Bay-Area-Electron-User-Group/

------
marcosscriven
Related to another comment I posted here, what's the opinion lately on native
controls/UI widgets vs something cross-platform like this?

It always used to be argued (and maybe still is) that using the UI framework
of the platform is preferable, but IMO the results of Electron apps I've seen
look great, and I don't find them confusing to use.

The reverse seems to be true on mobile platforms, where people seem to be
preferring native UI widgets and behaviour.

~~~
VeejayRampay
I think you're raising a valid point here. Electron apps are not confusing
because they do look like "applications" in the broader sense. Built on web
technologies, they end up looking like your average well-conceived and well-
designed website out there. And that look is something that all users have now
become accustomed to, so it does help bridge the platform gaps tremendously.

------
mgkimsal
It's too bad the titanium platform with desktop/mobile/js/web combo never got
more momentum. Building a 'web' app - with php or ruby - and bundling as
desktop app was pretty darn cool. I only dipped my toes in around 2011 or so,
and was sad to see it never get more traction. :/

------
voltagex_
So CatLight [1] seems to be a C# app using Electron for UI. I'm assuming
there's a local web server running, but I wonder how this works from a build
perspective? I wonder if Electron can be built with MSBuild.

1: [https://catlight.io/](https://catlight.io/)

------
tmarkovich
On a slightly unrelated note, I love the theme of the Electron plot. Is there
any place where I could find it?

------
robotnoises
Anyone with experience with Electron and NW.js have an opinion on which is
better?

~~~
paulbjensen
Hi, I'm writing a book comparing them both at the moment:

[https://www.manning.com/books/cross-platform-desktop-
applica...](https://www.manning.com/books/cross-platform-desktop-applications)

Having built apps in both, my view is that if you want the tool that fits best
with Node.js' conventions, Electron is closer to that philosophy. I say this
because of the way that the Node.js contexts of the main (backend) process and
the renderer (front-end) process are kept separate. This is different to the
way that NW.js has managed to blend the Javascript contexts of both into one,
which can lead to odd behaviour when it comes to apps that run with multiple
windows.

In terms of momentum, Electron is definitely capturing the most attention and
it looks like it will eventually become the goto framework for cross-platform
desktop applications over NW.js, which is a shame because NW.js has been
around for a while now and was the pioneer of being able to build desktop
applications with Node.js.

------
pj_mukh
Hmm? Slack's MacApp purports to use MacGap not Electron
([https://github.com/MacGapProject/MacGap1](https://github.com/MacGapProject/MacGap1)).

~~~
oceanswave
[https://slack.com/jobs/69902/desktop-application-
engineer](https://slack.com/jobs/69902/desktop-application-engineer)

"The Slack Desktop apps are built using diverse technologies such as Electron,
node.js, ES6, RxJS, C#, and Objective-C,"

------
jweinstein
Congrats to the Electron community!

We've been excitingly using Electron at Wagon to build SQL analytics tools.
We're using Haskell + React + Electron as our primary technologies:
wagonhq.com/blog/electron

------
cdnsteve
I haven't used Electron, but what about mobile apps? I have a need for an app
that works on desktop and mobile. So is the recommended option Electron for
desktop and for mobile PhoneGap/Cordova?

~~~
stefano
PhoneGap/Cordova apps are slow. Very slow. And even a hello world app can
weigh tens of MB. Debugging is painful compared to a native app.

The thing is, you won't notice how bad the situation actually is until your
code base has grown. Performance can seem acceptable at first, when there's
very little code to load and run. When your codebase inevitably grows, you'll
start noticing slow start up times (> 10 seconds) and a laggy UI.

If you have to do any computationally intensive operation, you'll have to
resort to cordova plugins because JS running in the UI thread is a non-
starter.

------
iconjack
Microsoft tried something similar years ago with HTML Applications (.HTA),
essentially web apps that could talk to the file system. Didn't seem to work
out, though.

~~~
oceanswave
Microsoft also had smart watches, mobile phones and tablets years ago, and
none of them really panned out either. ¯\\_(ツ)_/¯

------
justncase80
Congrats! This is an awesome tool and I hope it ushers in a whole new
generation of desktop apps!

------
gontard
"any application that can be written in JavaScript, will eventually be written
in JavaScript" this seems to be more and more true and depressing. A
JavaScript hegemonia.

------
uola
To me, unless things have changed, electron is crazy. Many people today use
some sort of abstraction layer that generates their html/css. I really hope
they move towards interfacing js or node.js directly with skia (which is the
graphics engine for chrome and used by, I think, sublime text).

------
rufb
This reminds me of Shoes. Of course, Javascript isn't designed for simplicity
like Ruby, and Electron is aimed at serious product development rather than
novice and weekend programmers. The product design just isn't "there" yet if
we are to measure it by _why's standards. But it's nice to see an ACCESSIBLE
actively-maintained tool for making cross-OS apps that "just work" again.

In fact, _why released Shoes around 2007 and disappeared in 2009. To put this
in perspective, Google Chrome and the 1st iPhone were released in 2008. The
web standard mess (JS in particular) was only beginning to be untangled back
in 2007. Maybe today's _why would have preferred to try and make Javascript
more approachable rather than choose a simple language like Ruby and make it
more powerful. I don't know.

At any rate, the trend for things like Electron is to become increasingly
complicated to the point where it merits a mention in developers' CVs — as it
happened with Rails and Node and countless other frameworks before. Hopefully
at this point there are players with stakes high enough at making things
accessible to push for an entry-level version of Electron. Maybe Codecademy or
one of its cousins.

