Electron 3.0.0 | Hacker News Reader

Electron 3.0.0

electronjs.org

137 pointsrmason136 comments

I really hope whatever the NativeWindow changes are allow Slack to finally stop rendering when the app goes to the background. My battery has been killed a couple times by the Slack renderer using ~30% cpu playing gifs while the app isn't visible, and their support says its because they don't have a notification hook for minimizing

Is writing native apps honestly still so hard these days?

I can appreciate the concerns about maintaining multiple codebases and dealing with different delivery mechanisms and their rules, but modern iOS/macOS and Windows APIs (at least; I cannot speak for Android and Linux) seem just as easy, let you work in arguably better languages, evolve at a faster rate, and provide a better experience for users and their machines.

It's not writing the native code that's the problem, it's designing the same GUI experience across platforms that's nearly impossible to do.

If it was so easy as you said, a lot of macOS apps would've been portable to Windows years ago given the market share.

I work for a cross-platform company, Windows is a much more difficult to develop for compared to macOS. You can write a Cocoa UI but what do you do on Windows when you need to support Windows 7 and above? Win32 controls are grossly outdated but the best accessible/consistent experience across multiple versions, UWP controls is limited to Windows 10 and best under MS Store, WPF has been neglected but so far it is the fastest way to develop a GUI. Microsoft has decided to split UWP out of Microsoft Store to bring it to everyone with UWP XAML Islands etc.

The reason Slack prefers Electron is because you can just write the same HTML/CSS front-end, deploy it, and all Slack apps can simply be refreshed to show the newest UI. You cannot do that with native apps at all. You could get around with a few webviews embedded in the native apps but might as well go full Electron.

It's not writing the native code that's the problem, it's designing the same GUI experience across platforms that's nearly impossible to do.

I don’t want the same “GUI experience” across platforms, I want a GUI experience that is consistent with the platform I am running.

When I was a heavy Mac user, I hated iTunes on Windows because it felt like being on a Mac instead of Windows.

You do realize every web apps that you use have a consistent look among all platforms and none of the native looks and I think we're used to that approach of using apps that seeing a 'web like' app on desktop doesn't feel odd anymore.

How many people use web apps as part of their regular work flow?

Gmail, gsuite, Trello, Hangouts, etc.

I would think that most people who use Gmail as part of their job would use a mail client just like most people who use Office365 for email use Outlook. Considering how much email is done on mobile, I don’t see too many people using gmail on mobile phones on the web.

Do you get notifications for new email from gmail in the browser or meeting reminders?

And all project management software on the web sucks in its own special way. That’s not something to aspire to.

As far as gsuite, I only use Google Sheets for simple stuff but can GSuite really take the place of Office for complex workloads?

This is one of those things that very much matters to hacker types but very little to everyone else. The most important thing about cross platform development is having the exact same application feature for feature pixel for pixel if you can. Someone who knows how to use Spotify on any one platform should be able to navigate any other with 0 cognitive load.

People learn applications, they don't learn systems -- apps have never been consistent enough for that.

Absolutely not the case.

Examples of apps which go the extra effort to use each platforms toolkit and look and behave natively?

The classic example of this was Microsoft Office; they tried to unify the UI and implementation for just the reasons you argue in the mid-1990s and faced a user revolt as a result. Subsequent versions were very much a rewind, with a native Mac human interface on a cross-platform core.

I don’t know how it is now as I haven’t used Office in about 15 years.

It feels very Mac like today.

It only does. Everything seems like some optimized hack of some sort that things aren't as performant as true native apps. Just maximizing the window size feels sluggish.

SourceTree has a native Mac and a native Windows app. I would guess that they are completely different code bases.

With so many platforms that's unrealistically expensive. It's not just Windows and OS X anymore.

Is having 1-3 Mac guys and 1-3 Windows guys (which is realistically all the vast majority of apps would need) really that much more expensive? To me it seems the real attraction is being able to hire from a giant pool of cheap, generic, interchangeable, fully replaceable developers.

> from a giant pool of cheap, generic, interchangeable, fully replaceable developers

A giant pool? Sorry, not really. JS skills are highly sought after, and finding good, experienced front end developers is very hard. Inexperienced developers are easy to find in any language, including your favorite one, whatever that is.

The "cheap, generic, interchangeable, fully replaceable" part just sounds bitter and vindictive, no need to respond to that.

When compared to the hiring pools for iOS and Android devs, the size of the web front end pool is certainly larger, because that’s what’s currently hot and has the lowest barrier to entry. You’re right that quality is just as hard to find, but given the performance issues that continually plague most modern web apps (with apps like VS Code serving as evidence that it need not be that way), I’m not convinced that quality is the highest priority with these hires.

I will concede that I am a bit bitter. It’s frustrating to watch the industry push ever harder to render specialized developers unnecessary.

If you compare the demand for websites vs mobile apps, we have about a total of 5 million downloadable apps and about 644 million active websites according to netcraft, which can be interpreted as 131 web devs for every 1 app dev. The pool for webdevs should therefore be much larger.

As for quality, correctly accessing a devs level of competence can be very tricky, regardless of the required skill-set. With web devs, its even more tricky because an "over-qualified" desktop/app devs can do just as much damage in terms of technical debt as a poor quality web dev. A webdev is also a specialized developer, but due to the low entry barrier, many don't realize this.

Money people sometimes think so because they’d rather keep that money for themselves, users be damned.

And Android, and iOS.

You can reasonably easily share the bulk of your mac/iOS/tvOS/watchOS codebases, and apple is actively working to push that percentage higher. So really, you’re not looking at 1-3 “mac people”, but rather 1-3 “Apple people”.

Android dev is messy business, no question there, especially if you care enough about experience quality to test across a broad range of phones, OS versions, launchers, etc. It’s no wonder why the average Android dev team is 2x the size of the average iOS dev team. Not much you can do there but hope Google makes an effort to clean up (and it seems they are, albeit slowly).

Even with all these platform specialists accounted for, companies like Slack and Spotify aren’t hiring any more engineers than they would otherwise. The only difference is instead of hiring specialists, they’re hiring hordes of web front end.

When there were way fewer personal computers and software was much harder to develop and distribute, companies would write software for Mac, PC, Amiga, Atari ST, and even Apple IIgs.

People were making cross platform apps before Electron.

Equating electron and cross platform is a gigantic fallacy.

Qt and other GUI frameworks (like Juce and FLTK) exist and are blisteringly fast. You don't have to package an entire web browser to make something cross platform.

Qt, or whatever, isn't pretty enough for the designers.

I'm more familiar with GTK, but can't you still make it look like anything you want pixel perfect?

I think the real issue is you can't bring all of your javascript/html/css libraries and tooling over.

I think you're correct.

This is a total non issue with Qt Quick, but I think complete UI look control is a waste of time and effort. It’s wheel reinvention where light brand accents would suffice.

Qt and Juce can be customized to look however someone wants. I don't think it is really so difficult to make images for buttons, change palettes and make sure everything is anti-aliased.

To me QT apps look like they came out of some old code base with old UI and web apps look more appealing imo.

How easy is it these days to create web, smartphone and tablet-UIs with Qt and those other frameworks? Cross platform is not limited to desktop anymore.

Both Qt and Juce emphasize mobile UIs heavily.

In Slack’s case, why an app at all? It already works with browser notifications. The Slack app is a worse experience than the website. It’s a memory and more importantly a battery hog.

Biggest problem in web apps, at least to me, is window management. When you switch to Chrome (on Mac), all browser windows come to foreground. I want to keep Slack as its own app so that it stays in the background until needed. I also want to keep it separated in Dock and Cmd-Tab switching etc.

Would something like this work?

https://fluidapp.com/

Theoretically yes, but then you still face other problems when the website has not been designed to be used as a desktop app. Slack's own application offers e.g. an easy way to switch between multiple teams (I have 16).

I really enjoy a separate app as opposed to a browser tab. For one thing I can push it out of the way up in my task bar. I don't live in Slack and only use it occasionally, so it's nice to have it close by but not in my face. Also, the ability to quickly alt-tab to/from it makes it much more accessible for me.

I tried to use the browser version and it works well enough, but it broke my workflow and was distracting. The app has its own set of problems but at least it lets me work the way I want.

You shouldn’t push for the same human interface on different platforms, they all have their own conventions that applications need to fit.

At least back in the 1980s and 1990s, cross-platform toolkits tried to look native everywhere, and that’s why.

Have you mailed Google customer support to do so with their Gmail?

Today, web apps are getting to the point that it can functionally be called 'apps' (whatever its definition is) and we're all seeing exactly the same UI from every platform and people seem to be just fine with that.

Yes.

At least N times the work for N platforms.

Fewer developers, harder to recruit.

Cross-platform options like Qt are not modern/pretty enough and sometimes aren't that much thinner than Electron (depending on how well written the app is). Java/Swing/SWT is also quite bloated and looks terrible.

Development is much slower in languages like C++. Other languages are not cross-platform or have immature/buggy cross platform support. How's ObjC on Windows? C# on Mac? They exist, but nobody uses them.

I really think we're in a UI dark age. Native UI development has gone backwards compared to the ease of WYSIWYG GUI design 10-20 years ago. Go back and use the VB.NET GUI builder from 2004 and be in awe at the incredible productivity you could achieve. Platforms are more fragmented today too. There is even fragmentation on the same platform! Do I use Qt or GTK or (insert one of a dozen others) on Linux? WPF or Windows Forms on Windows? Cocoa or UIKit on Mac? Which one will MS or Apple kill tomorrow? ... or I could just say fXXk it and use Electron and be done with it.

This is 100% the fault of vendors. If you hate the bloat blame Microsoft, Apple, and Linux developers, not people who use Electron.

Edit: mobile UI development is less fragmented but it's not really that great either. You get no choice in dev tools and the code is absolutely unportable. I see higher-level web or web-ish views/libraries/frameworks taking over there too. It's already happening.

> Go back and use the VB.NET GUI builder from 2004 and be in awe at the incredible productivity you could achieve.

That almost nothing like this exists today is evidence that personal computing is dying, IMO. Companies don't want to empower users, they want them to be good little content consumers who do what the ads tell them. Developers (OSS developers included) don't respect them and assume they're too stupid to be permitted to use anything but the safety scissors. After all, if they were worthy of creating things they'd be C greybeards.

> Developers (OSS developers included) don't respect them and assume they're too stupid to be permitted to use anything but the safety scissors. After all, if they were worthy of creating things they'd be C greybeards.

Thanks for mentioning that too. I loathe that mentality.

What people don't understand is that it hobbles the developers/geeks too. It causes us to build systems that waste our time futzing around with minutia. Bad UX and bad tooling is objectively bad in that it imposes needless cognitive load.

I learned this when I (almost cliche) switched from Linux desktop to Mac. I was amazed at how much more I got done when I didn't have to futz with drivers, config options, broken packages, etc. I now probably spend an hour a month messing with my computer compared to an hour a day.

I haven’t done any desktop GUI development since VB6 and I only used .Net Windows Forms for Windows Mobile up until 2011. What is the modern drag and drop method to build GUIs on Windows?

> Other languages are not cross-platform or have immature/buggy cross platform support. How's ObjC on Windows? C# on Mac? They exist, but nobody uses them.

What's wrong with C# on Mac? It's basically bindings to the native API via Xamarin.Mac.

You can build a cross-platform app with Xamarin on iOS / Android / Mac, UWP on Windows, and Gtk# on Linux. Using something like MvvmCross will allow to share most of the business logic between platforms.

What did the old VB.NET GUI builder do better than the Windows Forms Designer in a newer Visual Studio? (I haven't used either, but know Delphi from far back when and its open "clone" Lazerus)

> At least N times the work for N platforms.

Only if 100% of the code is the GUI.

It's still N times the work. You trade rewriting the core for figuring out how to meld your vision to two different APIs, two different UI libraries, etc., and of course fixing all the quirks.

It is. Especially for multi billion dollar companies with 100s of developers. Because you know careful evaluation, strategic direction, ROI etc has shown users prefer to update their own hardware instead of demanding companies to write efficient software.

If it's hard for a dev to write a native apps, then maybe they should re-evaluate their career choices and leave it to the competent ones.

If the "competent ones" have to resort to bitter FUD wars to protect their turf, then maybe they are the ones who need to re-evaluate their so-called careers.

Somewhere out there, there's a bitter COBOL developer still complaining about that "new fangled" c++

or, everyone can do whatever they want. i like that a bit more. :)

> provide a better experience for users and their machines

Ah, but you see, the modern developer does not care about the user experience. "Developer time is worth more than user time", "move fast and break things", etc. Users are the cattle we feed ads to and farm for salable data.

The modern developer very much cares about user experience which is why the gold standard right now is pixel perfect feature perfect cross platform apps for web mobile and desktop.

Except that’s not the gold standard.

Where are you getting the idea that it is?

Usage? Who is developing new cross platform apps in something other than a web stack?

It's still about twice the work. Or n-times, for n platforms.

It depends.

You could still use a web UI but without embedding Chrome and Node.

That sounds like writing and maintaining your own (cross-platform) version of Electron. And then not ending up with a native app for your troubles.

Not really. Just a shallow native layer that uses the platform as much as possible.

Except for the UI of course.

'Just'. Which platform? What are you going to render HTML with? And know it produces identical output, etc?

For example Webkit on Mac and iOS. Blink in Android and Chrome OS.

You'd need node for file system access though. Unless you write your own io layer

Indeed. That would be written in the native layer.

Twice the work for front-end only, and even that is arguable. The overall logic of the client across different platforms will be very similar. The only thing that will change is language and implementation details.

Different environment, different conventions, different bugs, different design, different support, different everything. Different teams that have to communicate. It is 'arguable' that it's twice the work, that is true. Twice is the lower bound.

There are options that let you write the bulk of your code in one language then code platform specific user-interfaces against that library. This is basically the Xamarin philosophy for iOS/Android development, and Xamarin apps generally offer a much better user experience than these web-app wrappers cluttering the App Store.

We were talking about desktop apps in this case. It's slightly different on mobile but the parameters are similar. The range of options here involve fiddling with dials that affect cost and quality. The comment I'm replying to amounts to 'why not pretend these dials don't exist?'. The answer is, because they're really there, you can't effectively plan development like that.

Yes. It's typical for a team to have different people handle different platform and spreading task on multiple people suddenly slows down the progress than letting 1 set of people handle the front end.

I want to work at a company like that, where I can just blame the "stack" we're using and shrug my shoulders.

do you really though

If it makes for easier programming, yes.

Writing Slack as a native app would be a massive pain. Especially due to all the web-like features it has, the fact that it's one codebase (mainly) for desktop and web.

They also have to support Windows, Linux, Mac and mobile. Not an easy task

> Writing Slack as a native app would be a massive pain.

If it was allowed I'd write the native macOS app for them. I'm sure it'd pay off selling it for $5 or $10 in the Mac App Store

Do it then: https://api.slack.com/

Slack APIs aren't perfect, but they're good enough to allow 3rd party clients for terminals, Emacs[0], and the like. I've never dug into it because I avoid Slack in general, but I think the biggest hurdle right now is just user authentication.

That's a pain, and does limit your audience, but maybe you'd still find some buyers on HN.

[0]: https://github.com/yuya373/emacs-slack

OAuth2 is as standard as it gets. Any language worth it's salt has ready-made libraries for it. There's tons of documentation and guides online too.

Not sure why that's an issue.

There are more complex apps with native versions for multiple platforms, by smaller companies.

Such as?

Affinity Designer, Photo, and Publisher to name a few, from the same company. [0]

Then there are many games, which by their nature require native performance, and of course have to present the same frontend. :)

[0] https://affinity.serif.com

These are powerful pieces of software which massively benefit from native code doing processor/GPU intensive tasks. Totally different use-case.

Slack is literally just a fancy messaging app.

Games feel like a separate edge case. One of the most common complaints about cross-platform apps is they don't "feel native" or adhere to platform UX expectations. With games, there's an expectation they'll provide their own wholly own UI that doesn't match an existing commercial OS.

Also, video games aren't generally expected to be accessible to blind people via screen readers. If you develop a cross-platform app with a custom UI, it's going to have zero accessibility unless you implement each platform's accessibility API.

Yes, game devs already put in the effort of providing their own UI stack, and port that to every OS.

If most Electron apps were built as "games", i.e. providing their own UI via DirectX/OpenGL/Metal etc., I wonder if they might still be more efficient and less bloated than Electron apps are now.

LibreOffice has native versions for all major desktop platforms, does many more things than Slack, and is maintained by open source volunteers and the Document Foundation staff of six.

qTorrent, VLC, CMAKE, Obs, AbiWord and Touch Designer. That's off the top of my head.

To say a company that has 200 MILLION in revenue can't re-write their client in Qt is indefensible nonsense.

You're probably right about cant, but why would they want to? A native version of their app would either embed a web browser or end up half-implementing one poorly. Why not just start with one?

Any Qt app can use QtWebView. There's a difference between putting a web browser inside your app and putting your app inside a web browser.

Yeah, the latter feels more put together, you don't have the awkwardness of communication between C++ and JS, and your web browser app will work in a web browser.

And all cross-platform apps made before Electron.

blender

The Mac cocoa version of Telegram achieves most of the same features as slack without resorting to webviews and shares 99% of its code with the iOS app (meaning the Mac build adds practically no overhead).

Windows and Linux are another beast, and Telegram’s solution is to use Qt for those platforms. Again, slack like capabilities with no webviews.

The difficulty of native dev is not as high as it’s often represented.

I have little experience with native iOS development, so you might well be right. That said, Telegram strikes me as quite a bit simpler than Slack. Not just in number of features, but also considering how many of the features are 'strange' UI.

As an aside, apparently the next version of Telegram will be a complete rewrite done in Swift, and snappier as a result.

For a billion dollar company? Give me a break.

Slacks annual revenue was 200 million in 2017, when they were a 5 billion dollar valued company. 200 mil is just 1000 Bay Area salaries, and they do have other budget items.

Its entirely possible that they cannot fund 5 native development teams, while building their core features to justify their valuation, and paying their sales and marketting team to actually generate revenue.

5 Devs on each team, which should be more than enough if they're getting 200k a year would cost a total of 5 mil. A tiny amount for such a huge improvement for users.

I legitimately can't tell if you are joking.

It does sound like a joke. It also ignores that fact that other, proper, multiplatform technologies exist that still produce a far superior end result for the user even if not 100% platform guidelines/conventions compliant.

What do you mean? Slack is valued at ~5 billion dollars, that has very little to do with their actual cash on hand. In 2016, they were bringing less than 65 million in revenue, for example.

I think I like when programming is hard.

When you're working on your own project, some time sink that you didn't anticipate may be frustrating, but other than that, I definitely prefer it to coding something I already know how to do well.

> their support says its because they don't have a notification hook for minimizing

That doesn't even seem correct - the BrowserWindow emits "hide" and "show" events [1] that Slack could use to do exactly what you're describing. I'm guessing they just don't want to implement it for some reason?

[1] https://electronjs.org/docs/api/browser-window#event-show

I’m guessing they meant visibility (which minimizing can effect) but it depends on what they mean by “background”. Sounds like that’s only reliably available on macOS:

“Additionally, on macOS, the visibility state also tracks the window occlusion state. If the window is occluded (i.e. fully covered) by another window, the visibility state will be hidden. On other platforms, the visibility state will be hidden only when the window is minimized or explicitly hidden with win.hide().”

Assuming they update soon enough I suppose. I find using the browser window for Slack is easier, the main browsers I use let you pin tabs so it's even easier, plus I can put a darker theme on Slack, so sick of the bright white background.

I always recommend using the browser because you're likely to have one open anyway, so you might as well reuse that (and save resources) than run another one.

Are there any browsers which allow you to do your own electron-like wrapping of webapps? Would be nice to have your own native icon etc, but also be able to tune exactly what behaviour you want, for instance set per app caching levels, cookies, what happens when it goes to background, etc.

A good example is on mobile, where playing media on the web is a hassle because you never know what the background behaviour will be, whether it’ll carry on playing when you’re on another tab, or on another app, or with the screen off, or after five minutes. It seems to be a free for all now for the browsers, not much user control.

> Are there any browsers which allow you to do your own electron-like wrapping of webapps?

FluidApp[0] should work great and I bet there’s even a userscript already to handle desktop notifications.

[0] https://www.fluidapp.com

Chrome is actively working on this: https://developers.google.com/web/updates/2018/05/dpwa

(disclosure: I work on Chrome, but not on this)

Firefox used to support this but they nixed it (but hey, they gave us Pocket instead, yay! /s)

Seems to have a bugzilla ticket:

https://bugzilla.mozilla.org/show_bug.cgi?id=1407202

You can kinda disable gifs by going to preferences > Messages & Media and unchecking "Show images and files from linked websites". Doesn't get them all but it really helps.

Looks like the BrowserWindow events at the js api level are unchanged for the past two years.

Here's hoping something deeper was broken about them that now drastically changes top-level api behaviour!

Why is it taking 100% CPU to play gifs?

Chromium is notoriously slow at rendering GIFs. It used to be faster than Firefox, but years ago it went downhill. On a forum I visit, people would basically troll Chrome users by posting hundreds of animated smilies. On Firefox and Safari, there is little effect, while it chugs Chrome down to a halt.

maybe not 100% from doing a quick test, more like 30% nowadays but that can use up power quick still

FWIW I disabled animations in the slack settings and the difference is night and day.

It looks like a short list of new things, so maybe it makes sense to look at the first beta for v3:

https://electronjs.org/releases#3.0.0-beta.1

Thanks, this is the "real" changelog. I wish projects didn't waste these great PR opportunities. There should be a blog post written by a human for human consumption that explains why we should be excited.

Yes, a nice release blog post can be so much more than just a list of closed tickets.

I think the WordPress team usually does a good job, e.g. https://wordpress.org/news/2017/11/tipton/

As someone who doesn’t follow Electron even that is worthless to me.

Is there a significant speed/memory usage change? Is the install smaller? Some new features that people want?

I don’t know. And I’m not going to read the names of dozens of tickets to try to find out.

As someone who doesn't follow or even like electron from the sounds of it, why do you expect anything about their release log to be worth anything to you?

I like knowing what’s going on. I’m know I’m using a few electron apps that would benefit from performance enhancements.

But some open source projects (like this apparently) announcennew releases in such a way that only Biden intimately familiar with the project can tell what changed.

And it makes it very hard to start following the project.

> Is there a significant speed/memory usage change? Is the install smaller? Some new features that people want?

No, it still packages two different runtime environments, one of which is a browser, which, in turn, is basically an OS.

I know it’s not going to be native speed. Every. But I thought maybe it was 10% faster or something due to an updated JS engine.

(Just a guess at a possible feature, not meant to be true)

Well, they updated to a new version of V8. So that's about 8 months worth of JS optimizations and new language features right there. The change log doesn't really do a good job of highlighting that though, it just says "Upgraded from v8 6.1.534.41 to 6.6.346.32."

I figured it would include the latest version, but 6.1 to 6.6 is meaningless numbers to me. In a list of this style it makes sense, I just wish this was an announcement that said ‘we changed/added X, Y, and Z. V8 has been updated to a version with a faster GC. MacOS looks more native. And (other cool change)”.

Just a little paragraph like that would be great.

I'm working on shipping a new release of my document annotation platform on Electron 3.0

https://github.com/burtonator/polar-bookshelf

We've been releasing with the 3.0 betas for about a month now and haven't had any issues. It's been pretty stable.

Actually more stable than the 2.x series as it has a number of bug fixes that weren't in the 2.0.0 ... really glad this platform is still moving forward aggressively.

There are also 4.0 beta builds up which I haven't played with yet.

I have eagerly waited for this release, as it uses Chrome 66. Previous stable version used Chrome 61, which lacked some nice additions to JS, most notably for me - the complete Intl API support.

Oh look, finally you are getting some API that has existed on proper frameworks for more than a decade.

yes, it's pretty nice to get new stuff :D

Would you also like a lollipop? You can get one at the kids JS "dev" table.

Posting uncivilly will get you banned here, so please don't do this again.

https://news.ycombinator.com/newsguidelines.html

Will electron apps finally stop canceling OS X shutdown / restart (before quitting themselves)? Atom, Slack, and others each prevent shutdown one at a time.

They should, yes. That bug was actually fixed in one of the 2.0.0 betas (https://electronjs.org/releases#2.0.0-beta.1) – those apps may just be slow to catch up.

From February? That is quite old as far as web apps go

I'm excited, I need to dig though to see if any of the chrome updates fixed accessibility issues. The press release doesn't link the the PDF support issue which is a little worrying.

I think the fix is: https://github.com/electron/electron/pull/13760

Out of curiosity, assuming that Node 10.8 (or the latest version we're on) doesn't break anything from 10.2, and also assuming that the Node abstraction layer protects developers from underlying V8 ABI changes; why would Electron release a new version with dated versions of Node and V8?

Is it because of a release cycle?

Currently 'npm i -D electron@latest' is still installing electron@2.0.10 but 3.0 can be installed with 'npm i -D electron@3.0'.

Reply on news.ycombinator.com