[0]:https://github.com/w3ctag/design-reviews/issues/467
Edit: added citation.
Searching for supporting things just now, I found some thing that seem similar:
https://stackoverflow.com/questions/1294586/browser-detectio...
I do think in special cases you should use the user agent to send proper code, but most businesses probably don't need this today.
With https://caniuse.com/ and a good knowledge of the shape of your traffic, it no longer seems critical for .05% of users some how on IE 6 still that visit your site to have all the eye candy.
Now if you're a government site I think you should be taking the time to ensure as many people as possible can access your site bug free, but that could mean just make sure it is dead simple. If you're a large business where .05% of traffic is a few million $ of lost revenue, yeah go a head hire those engineers.
For the rest of us just let the eye candy fail, get the site to work and forget about it.
I think in our case a lot of our decisions are based on two success criteria:
1. We want our developers to be able to use language features (like Promises, Maps, and Iterators) that make development easier.
2. We need to pick a solution that offers the best performance in the browser. We run an e-commerce marketplace; we pay for every additional byte we send over the wire in our conversion metrics, whether it's in the short term or the long term.
It's not really reasonable for us to only write JavaScript that works for the lowest-common-denominator of our traffic (we still support IE11!) but at the same time, we also can't drop support for them. So, we have to partition our traffic in order to allow modern browsers to skip the polyfills they don't need, while supporting the older browsers that need them. There really isn't a better way to do this than serer-side parsing of the user agent string. Identifying features in the browser means that we have to incur another round-trip, which delays the execution of any of our other JavaScript and hurts usability metrics like Time To Interactive[0]. I have to plug Polyfill.io[1] here; their service is open-source and works extremely well.
And as far as whether this is an anti-pattern or not, it's something that works really well for us. We've implemented both a general polyfill and a user-agent-specific polyfill solution, and there were in fact small performance benefits in the latter, with no cost to conversion.
Plus, whether user-agent parsing is an anti-pattern or not, it's the state of the world. As I've already mentioned above, we don't gain much by avoiding this anti-pattern, so what's our motivation to change our implementation? As a challenge, I'd encourage you (or anyone reading this) to try spoofing your browser's user agent to be IE11. You'd be surprised how little of the internet works, even on sites that claim to support IE11.
