6 ms·

Run Chrome apps in Electron

105 points by simonpure 10y ago

saurik 10y ago
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")?
- kzahel 10y ago
  Thanks for the tip. I didn't realize NW.js had full chrome.* API support. That's good news!
- kzahel 10y ago
  Also, he is not wrong, the chrome.socket API was pretty crap. But it was replaced with chrome.sockets API which is good.
- Dinius 10y ago
  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. [1]: http://electron.atom.io/#apps http://electron.atom.io/#apps
  - polpo 10y ago
    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.
  - niutech 10y ago
    Re: tested in production - NW.js has also a wealthy portfolio of apps: https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companies-using-nw.js https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companie...
paulddraper 10y ago
For background, Google is deprecating Chrome apps (desktop apps made with web tech) for non-Chrome OS platforms. Chrome Web Store listings will be gone in a year; they'll stop working another six months after that. http://blog.chromium.org/2016/08/from-chrome-apps-to-web.html http://blog.chromium.org/2016/08/from-chrome-apps-to-web.htm...
- tracker1 10y ago
  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.
- tux1968 10y ago
  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?
  - detaro 10y ago
    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.
- learningman 10y ago
  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?
asimuvPR 10y ago
I wonder if one could get ARC Welder apps to run with this. Ideas?
therealmarv 10y ago
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).
ghostintheshell 10y ago
woaw excellent
polpo 10y ago
A much better option than this is to just use NW.js [1], which supports all of the chrome.* APIs natively, without polyfills [2]. [1] http://nwjs.io http://nwjs.io [2] http://nwjs.io/blog/chrome-apps-support/ http://nwjs.io/blog/chrome-apps-support/
erelde 10y ago
I have some custom shortcuts going like those: chromium --app="https://www.worldwideweb.org" Will they also remove that flag?
- kevincox 10y ago
  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.
lindstorm 10y ago
Waiting for the USB API to be implemented

105 points by simonpure 10y ago

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")?

kzahel 10y ago
Thanks for the tip. I didn't realize NW.js had full chrome.* API support. That's good news!
kzahel 10y ago
Also, he is not wrong, the chrome.socket API was pretty crap. But it was replaced with chrome.sockets API which is good.
Dinius 10y ago
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. [1]: http://electron.atom.io/#apps http://electron.atom.io/#apps
- polpo 10y ago
  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.
- niutech 10y ago
  Re: tested in production - NW.js has also a wealthy portfolio of apps: https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companies-using-nw.js https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companie...

paulddraper 10y ago

For background, Google is deprecating Chrome apps (desktop apps made with web tech) for non-Chrome OS platforms. Chrome Web Store listings will be gone in a year; they'll stop working another six months after that. http://blog.chromium.org/2016/08/from-chrome-apps-to-web.html http://blog.chromium.org/2016/08/from-chrome-apps-to-web.htm...

tracker1 10y ago
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.
tux1968 10y ago
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?
- detaro 10y ago
  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.
learningman 10y ago
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?

asimuvPR 10y ago

I wonder if one could get ARC Welder apps to run with this. Ideas?

therealmarv 10y ago

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).

ghostintheshell 10y ago

woaw excellent

polpo 10y ago

A much better option than this is to just use NW.js [1], which supports all of the chrome.* APIs natively, without polyfills [2]. [1] http://nwjs.io http://nwjs.io [2] http://nwjs.io/blog/chrome-apps-support/ http://nwjs.io/blog/chrome-apps-support/

erelde 10y ago

I have some custom shortcuts going like those: chromium --app="https://www.worldwideweb.org" Will they also remove that flag?

kevincox 10y ago
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.

lindstorm 10y ago

Waiting for the USB API to be implemented