6 ms·

This is going to be really annoying since hardware access from HTML5 is still very rough and not even standardized. Stuff like talking to a serial port isn't e

by tdicola 10y ago

This is going to be really annoying since hardware access from HTML5 is still very rough and not even standardized. Stuff like talking to a serial port isn't even on the radar (so good luck programming a board like BBC micro:bit, Arduino, etc. without a native app), and efforts like WebUSB are still extremely early and not even a full standard. I feel like the product managers making this decision are completely oblivious to the major gaps between chrome app support & HTML5 support. This line in particular is basically a giant middle finger to folks in this situation: "Developers who can’t fully move their apps to the web can help us prioritize new APIs to fill the gaps left by Chrome apps." So in short, Google proves once again to _never_ take a bet on their technology.

jwmerrill 10y ago
The article mentions using Electron or NW.js if you want to continue building apps on web technologies that need deeper platform access. Is there a reason that those are worse options than Chrome apps?
- WayneBro 10y ago
  Each Electron/NW.js app will be packaged with a whole huge runtime. It's not all bad - there's more freedom with these.
- tdicola 10y ago
  It's possible but it's not an easy switch. And god help you if you have to mix native code with Electron. Getting a node-gyp toolchain spun up on Windows is a complete and total nightmare. Add Electron and its very specific version of Node into the mix (which totally confused node-gyp) and it's really awful.
  - xpaulbettsx 10y ago
    Nah, it's not that hard, not sure why you had so much trouble Source: Have written many many Electron node modules
  - comex 10y ago
    There's also the alternative of switching to a Chrome extension, no?
    - deno 10y ago
      Different sets of APIs[1]. For example Socket, USB are only App APIs. Though I guess they could roll app APIs into extensions… hopefully. Socket API especially.
  - mlsarecmg 10y ago
    It used to be hard, but when you have tried it last time? These days its as simple as hitting. npm install --global node-gyp npm install --global --production windows-build-tools
- ArmandGrillet 10y ago
  Only Chrome apps work on Chrome OS and developing a Chrome app is way easier: Chrome takes care of the back-end and Google offers an app store.
sowbug 10y ago
Did you place a bet on this technology? Tell us about it.
- tdicola 10y ago
  I didn't personally but there's stuff out there like chromeduino and Codebender that could be broken by this: https://chrome.google.com/webstore/detail/chromeduino/dmkincdpchiadkhhocmbpjljebfifgbl?hl=en-US https://chrome.google.com/webstore/detail/chromeduino/dmkinc... or https://chrome.google.com/webstore/detail/codebender-app/magknjdfniglanojbpadmpjlglepnlko?hl=en https://chrome.google.com/webstore/detail/codebender-app/mag...
- nraynaud 10y ago
  I did, I wanted a multi-platform GUI with USB access for my milling machine software.
  - rasz_pl 10y ago
    there are workarounds, for usb device over wifi there is this: https://github.com/cnlohr/espusb https://github.com/cnlohr/espusb if you are hardcore enough it is possible to add usb host support too
catdog 10y ago
Websites with hardware access? what could possibly go wrong? Browsers already are a overly complex security nightmare. Moreover the recent example of this stupid but rather simple battery API has shown us several, some more and some less obvious ways of how it can be abused. But sure Google will implement WebUSB and all sort of other shit they may imagine, the others will follow as always. In the end the browser will finally be the OS in your OS but worse and with a huge attack surface.
- seanwilson 10y ago
  What's the alternative? If an app needs such functionality to work and it cannot work within a browser, the user will have to install a native app which aren't nearly as well sandboxed right now (Windows, Mac, Linux).
  - catdog 10y ago
    Most importantly, as a user, don't install programs which can't be trusted because sandboxing is no magic bullet and will never be. In addition to that better redirect the work that would go into these browser features to improve the native sandboxing mechanisms of the operating systems.
    - seanwilson 10y ago
      > Most importantly, as a user, don't install programs which can't be trusted because sandboxing is no magic bullet and will never be. Perfect is the enemy of good! It's better than the alternative and that's all that matters.
      - catdog 10y ago
        Sure nothing is perfect and I did not say that we shouldn't improve sandboxing but I do not think that moving everything into the browser is the better alternative. The problem doesn't get easier only because it's in the browser and as a nice topping every random website is now free to try to break the sandbox.
ulber 10y ago
The BBC micro:bit happens to be a bad example, since the editors [1] are exactly web apps with no hardware access. The editors compile the code in the browser and provide the ARM binary as a .hex file that the user downloads onto the micro:bit, which is a USB mass storage device. [1]: https://www.microbit.co.uk/create-code https://www.microbit.co.uk/create-code
- tdicola 10y ago
  Yeah but not every board can do USB storage bootloader, and there are troubles with it like ignoring Mac OSX .DS_store files, etc. Been there, done that, USB mass storage bootloading kinda sucks. Also if you load stuff like MicroPython on the micro:bit you can't access its serial REPL from the web. That sucks, plain and simple.
madeofpalk 10y ago
To be fair, did many people actually place a significant 'bet' on Chrome Web Apps? Even from the beginning that wouldnt sound like a very wise bet.
- espadrine 10y ago
  Just last December, Open Whisper Systems announced Signal Desktop, a Chrome Web App[0]. I am not sure how significant you would consider the Web to a messaging platform, but most of their competition has a Web app by now. [0]: https://whispersystems.org/blog/signal-desktop/ https://whispersystems.org/blog/signal-desktop/

by tdicola 10y ago

jwmerrill 10y ago

The article mentions using Electron or NW.js if you want to continue building apps on web technologies that need deeper platform access. Is there a reason that those are worse options than Chrome apps?

WayneBro 10y ago
Each Electron/NW.js app will be packaged with a whole huge runtime. It's not all bad - there's more freedom with these.
tdicola 10y ago
It's possible but it's not an easy switch. And god help you if you have to mix native code with Electron. Getting a node-gyp toolchain spun up on Windows is a complete and total nightmare. Add Electron and its very specific version of Node into the mix (which totally confused node-gyp) and it's really awful.
- xpaulbettsx 10y ago
  Nah, it's not that hard, not sure why you had so much trouble Source: Have written many many Electron node modules
- comex 10y ago
  There's also the alternative of switching to a Chrome extension, no?
  - deno 10y ago
    Different sets of APIs[1]. For example Socket, USB are only App APIs. Though I guess they could roll app APIs into extensions… hopefully. Socket API especially.
- mlsarecmg 10y ago
  It used to be hard, but when you have tried it last time? These days its as simple as hitting. npm install --global node-gyp npm install --global --production windows-build-tools
ArmandGrillet 10y ago
Only Chrome apps work on Chrome OS and developing a Chrome app is way easier: Chrome takes care of the back-end and Google offers an app store.

sowbug 10y ago

Did you place a bet on this technology? Tell us about it.

tdicola 10y ago
I didn't personally but there's stuff out there like chromeduino and Codebender that could be broken by this: https://chrome.google.com/webstore/detail/chromeduino/dmkincdpchiadkhhocmbpjljebfifgbl?hl=en-US https://chrome.google.com/webstore/detail/chromeduino/dmkinc... or https://chrome.google.com/webstore/detail/codebender-app/magknjdfniglanojbpadmpjlglepnlko?hl=en https://chrome.google.com/webstore/detail/codebender-app/mag...
nraynaud 10y ago
I did, I wanted a multi-platform GUI with USB access for my milling machine software.
- rasz_pl 10y ago
  there are workarounds, for usb device over wifi there is this: https://github.com/cnlohr/espusb https://github.com/cnlohr/espusb if you are hardcore enough it is possible to add usb host support too

catdog 10y ago

Websites with hardware access? what could possibly go wrong? Browsers already are a overly complex security nightmare. Moreover the recent example of this stupid but rather simple battery API has shown us several, some more and some less obvious ways of how it can be abused. But sure Google will implement WebUSB and all sort of other shit they may imagine, the others will follow as always. In the end the browser will finally be the OS in your OS but worse and with a huge attack surface.

seanwilson 10y ago
What's the alternative? If an app needs such functionality to work and it cannot work within a browser, the user will have to install a native app which aren't nearly as well sandboxed right now (Windows, Mac, Linux).
- catdog 10y ago
  Most importantly, as a user, don't install programs which can't be trusted because sandboxing is no magic bullet and will never be. In addition to that better redirect the work that would go into these browser features to improve the native sandboxing mechanisms of the operating systems.
  - seanwilson 10y ago
    > Most importantly, as a user, don't install programs which can't be trusted because sandboxing is no magic bullet and will never be. Perfect is the enemy of good! It's better than the alternative and that's all that matters.
    - catdog 10y ago
      Sure nothing is perfect and I did not say that we shouldn't improve sandboxing but I do not think that moving everything into the browser is the better alternative. The problem doesn't get easier only because it's in the browser and as a nice topping every random website is now free to try to break the sandbox.

ulber 10y ago

The BBC micro:bit happens to be a bad example, since the editors [1] are exactly web apps with no hardware access. The editors compile the code in the browser and provide the ARM binary as a .hex file that the user downloads onto the micro:bit, which is a USB mass storage device. [1]: https://www.microbit.co.uk/create-code https://www.microbit.co.uk/create-code

tdicola 10y ago
Yeah but not every board can do USB storage bootloader, and there are troubles with it like ignoring Mac OSX .DS_store files, etc. Been there, done that, USB mass storage bootloading kinda sucks. Also if you load stuff like MicroPython on the micro:bit you can't access its serial REPL from the web. That sucks, plain and simple.

madeofpalk 10y ago

To be fair, did many people actually place a significant 'bet' on Chrome Web Apps? Even from the beginning that wouldnt sound like a very wise bet.

espadrine 10y ago
Just last December, Open Whisper Systems announced Signal Desktop, a Chrome Web App[0]. I am not sure how significant you would consider the Web to a messaging platform, but most of their competition has a Web app by now. [0]: https://whispersystems.org/blog/signal-desktop/ https://whispersystems.org/blog/signal-desktop/