If this service becomes common, then I will be given broken webpages seemingly at random. The other option, a polyfill covering specific features and served to all clients, regardless of user agent, doesn't suffer from that.
If this service becomes common, then I will be given broken webpages seemingly at random. The other option, a polyfill covering specific features and served to all clients, regardless of user agent, doesn't suffer from that.
I'm more worried about supporting older users on old machines who barely know the difference between Internet Explorer and the internet than in supporting someone who knows exactly what a UA is and how to spoof it.
Basically they're crafting the UA to appear like Chrome or Firefox.
If a lot of the pages you view end up broken, you would just change the way you lie about your user agent so that it's more prominent to you so you don't forget.
Your complaint is like complaining that if you set your browser's "language preference"* to only contain Dutch, you will end up getting served pages in Dutch.
Why is that different? You ask for Dutch only because supposedly you can understand it, and you ask for a presentation against a particular browser/version because supposedly you're rendering in it. Seems fine to me!
Otherwise, we might as well only serve pages in Esperanto - you know, the universal language standard.
* "(or, more appropriately, that of its user) along with every HTTP request being made in the form of the Accept-Language header that is part of the HTTP/1.1 RFC"
Do a significant percentage of users spoof their agent?
The point of this service is that its not requiring the user to know what feature to look for. They'll polyfill anything thats needed. To do feature detection to the level they're trying to serve you'd have to check EVERY API that needs polyfilled on an in-use browser. Full feature detection also involves looking for apis that exist but don't follow the spec. Checking every single API possible on every browser would not be quick and simple. User agents allow them to settle on a list of known needed polyfills without any code needed for the user beyond a simple script tag.
There are definitely tradeoffs to their approach but I can't say "I don't see any reason" why you wouldn't feature detect for this.
https://cdn.polyfill.io/v1/polyfill.js?features=Array.protot...
Docs about this can be found here: https://cdn.polyfill.io/v1/docs/api
It would be cool if they allowed you to disable this feature, and just use feature detection and always load the code for the requested item.
There are good reasons why you cannot make a good choice of polyfill prior to knowing the browser family and version, primarily due to polyfill variants (more details in the Hacks post).
Yeah, properly serving that 0.01% demographic would be hard...
/s