I can already see issues like people who bought new old stock who can no longer do anything with them.
The best case scenario is they release a toolkit to flash your own firmware so people can hack on the now completely otherwise useless controllers.
It means they can delete the code from the monorepo.
Eventually the framework it's running will be deprecated and someone will clean it up.
Every thing deployed at Google has all kinds of frameworks and shared libraries and tooling. There are many policies in place to get insure they get newer versions of shared code, such as:
https://opensource.google/documentation/reference/thirdparty...
And to maintain these kinds of things, it isn't uncommon for unfunded mandates to be pushed on people that own various tools, such as this one.
Meaning, even to keep a website up at Google, there will be some maintenance burden. Also, I could imagine Chrome pushing some update that would make all of the usb pairing stuff that they do here break at some point, and they will have to do work to keep it working.
I think the real question is why bother doing it with this website? The controller has a USB port on it and I imagine can talk over USB. It would be far better to just have some application which can flash over USB instead of needing some Google-hosted website. Just give me an executable that people can toss on a torrent or whatever. I appreciate they did something to make these controllers useful to people, but it seems like they really didn't pick the best path to achieve that.
I imagine they probably painted themselves into a corner and the firmware update process is so locked down and will only talk to approved Google endpoints over an HTTPS request or something like that and that's the ultimate reason why they went that route. But really I feel that kind of shows a failure to imagine the hardware life after the service.
To me, they could put it on github and serve it on github pages. I suspect though that there's a bunch of non-open source libraries being used and getting into a condition that could be open sourced is person power they don't want to spend when they have an infinite list of things to work on.
Everything being a website isn't necessarily a good thing.
The underlying tech is powered by the WebSerial protocol. We basically already have the executable you're asking for. As long as Google supplies the firmware blob (and js source, though this can probably just be ripped from the current web page), anyone will be able to put up a server, and anyone with a modern browser will be able to visit the site and update -- without having to install anything locally.
Given that a 'native' app would probably be some bloated Electron abomination, I was actually pleasantly surprised that Google chose to solve the firmware update problem the way they did; it worked flawlessly for me on Linux which is seldom the case when it comes to these things.
And sure, when talking about an OS that's often made a point at cutting off support for old binaries it's not good. You're ignoring the fact I can still run a lot of 30+ year old software on modern Linux and often modern Windows with ease.
As is also mentioned in the article, the author reverse engineered the site, and create a python script capable to performing the flashing process via standard OS APIs.
Really the flashing site isn’t really “a site”. It’s a hosted executable written in JS that pretty much runs entirely locally, apart from the bit where it downloads the new firmware to be flashed. It should be possible to extract the JS itself, plus firmware blobs, and run that completely offline for as long as browsers support WebUSB. Or you do what the author did and create a Python equivalent.
That can be solved by developing a flasher in a framework more stable than Javascript and web browsers, like OP did.
Companies been increasingly using the "we can't do X because Y" justification when they themselves are responsible for Y.
https://twitter.com/killedbygoogle/status/173591315266219646...