Why would someone use this when NW.js (formerly node-webkit) has essentially complete and native-from-using-Chromium (instead of libchromiumcontent) non-"polyfill" support for Chrome apps, and they consider it a supported platform feature as opposed to some third-party tack on (which isn't even trying to be fully compatible; as, in the README, this developer says he is refusing to implement chrome.socket to spec simply because he feels the API is "kinda crap")?
Not to disregard that NW.js might be a better choice in this case due to the API support.
But generally speaking, Electron:
- Is more tested in production (VS Code, Atom, [1])
- Has a larger and more active community
- Has (at least in the past) started using newer versions of Node and Chrome long before NW.js (Especially with Node when v4 came out this was a relevant drawback)
- Tested both the newest versions on Windows 10 right now, Electron used ~50mb less RAM, and less CPU. (Of course this isn't a very relevant test, more of an observation, these numbers could vary greatly between systems and platforms).
On the flip side, some reasons to use NW.js:
- "Source code protection", which gives a ~30% performance reduction. Electron devs has chosen not to implement this due to that drawback.
- Better support for transparent windows, at least in the past. (At the expense of disabling hardware acceleration).
Note that some of this information might be a few months out of date, mostly in regards to NW.js.
To address the "started using newer versions of Node and Chrome" point, since NW.js v0.13, on the day a new version of Chrome hits the stable channel, a new version of NW.js is released matching the Chrome version. At the time of those releases, NW.js ships the current stable version of Node. So as of late, NW.js has been ahead of Electron in being more up to date with Chrome and Node. There is also a corresponding beta version of NW.js that tracks the Chrome beta channel.
There are some useful Chrome Apps out there. I can think of Authy, Postman and Signal.
Oh, I remember Moxie claiming that they've built Signal as a Chrome app because Chrome has won the desktop: https://news.ycombinator.com/item?id=10665679 - I can't decide whether this is funny or sad.
It's both funny and sad. I just ignored the existence of the Chrome app, and am trying my best to ignore the fact that they thought it was such a great idea in the first place. To be fair, in that comment he wrote “browser” won the desktop not “Chrome”. But maybe that's probably even more farcical because “browser winning the desktop” means they should have made a regular web application, not a damn Chrome app. And the whole idea of making an app like Signal in a browser... let's say I'm just glad something like Tarsnap, for example, isn't run by Signal people.
I like Signal, and I depend on it, and wan't it to be successful, but oh boy are people running it full of misplaced hubris. A lot critique is dismissed just like in the thread you link: “we wan't to stop mass surveillance”. “But Moxie, change X makes Signal less useful/less secure for a lot of people who really need it!”, “We're glad you're an irrelevant geek, but we wan't to end mass surveillance”... Implying they're making Signal approachable to “masses”. But they aren't, partly because proper security will never (for various values of “never”) be approachable to disinterested masses, and partly because they pull some ideas on usability out of their ass.
I think the fact that the Signal protocol now forms the basis of WhatsApp and Duo/Allo is as significant a refutation of your argument as could be desired.
Feel free to keep using the wonderful pgp user interface.
It was a great boom for Linux and OSX that a developer could make a Chrome OS app and literally be cross-platform (of course with some downsides). Odd move by Google IMO. I'm guessing less devs will support only Chrome OS apps.
Wow. Google deprecating Chrome apps will hurt the Chromebook ecosystem, who will develop apps that can only be run on a Chromebook? What's up their sleeve here? Expanding the Play store to desktops?
I think the reasoning is less nefarious, Chrome apps never got that much love on other platforms, and I'm guessing they want to move towards Progressive Web Apps.
It's a shame, really as I actually appreciate chrome apps, considering I use OS X/macOS, Linux and Windows regularly, there's a handful of things I like carrying over with my logged in chrome.
Although there are, or at least were some definite holes in app support.. namely a stand-alone (as much as can be) mail client that supports pop/imap and smtp with tls support. There's a halfway decent SSH client, though getting your private key in can be cumbersome. Aside from that, I don't mind most of my apps being browser based. There are of course limitations, but the remote desktop and ssh apps cover most of that for me.
Thanks for the link, there is some good stuff there.
What is really puzzling though, if you believe their rationale for axing Chrome apps, is why they would need to carve out an exception for Chrome OS.
If Chrome apps have truly been superseded by browser and web standards then why are they still needed on Chrome OS? If they have extra functionality, then why remove them from the desktop? If they don't, then why keep them on Chrome OS?
They don't say that all Chrome apps have been truly superseded by web standards. Just that most have, and combined with the low usage numbers it isn't worth the maintenance effort anymore. In Chrome OS they are the main application format (I think?) and Google has active interest in maintaining it, so they stay there.
I dislike running a whole browser beside my Chrome browser. I think Chrome should be like the webview in Android 7.0 Nougat, an component/interface/platform you can use also for external programs but only completely external managed UI wise (no internal UI like for Chrome Apps).
I don't thinks so. I believe that that is a different use of the word "app". That flag means "open this website and make it look like a native app", the "Chrome Apps" are extensions that use a different set of APIs.
Disclaimer: I work at Google but don't have any insider knowledge of this.
