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.
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.
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).
> the alternative? [...] install a native app which aren't nearly as well sandboxed right now (Windows, Mac, Linux).
err, the sandboxing works because web APIs don't already expose things which are suggested to be exposed here. Exposing them will break that "sandbox", to a certain (major) degree, atleast.
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.
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.
UWP is sandboxed, Mac App Store apps are sandboxed, Mac apps from outside the store can opt-in to sandboxing, flatpaks are sandboxed, snaps are sandboxed.
In terms of maturity, all of these techniques are probably more mature than any WebUSB/Browser hardware access thing/abysmal-of-the-day.
Reading your comment on a Chromebook that hasn't failed me once including all the others i have had makes me scratch my head. If anything this, to me, seems the most secure approach compared to what's out there. Doesn't it make to you? A secure, lean Linux hosting a lean UI layer that sandboxes web and native apps.
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.
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.
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.
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.
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.
there are workarounds, for usb device over wifi there is this: https://github.com/cnlohr/espusb
if you are hardcore enough it is possible to add usb host support too
So in short, Google proves once again to _never_ take a bet on their technology.