💡 IDEA: JavaScript Compatibility as a Service

Sometimes I wonder how many hours of frustration and billions of dollars has been spent over the history of web development on making code that works in one browser support another browser. With tools like Babel to transpile modern language features down to an older language that works on ancient browsers, young devs these days have no idea how good they have it.

It occurred to me that it kind of sucks that even the newer browsers have to download the larger, older javascript versions of the bundles, laden with polyfills. What if they didn't? What if you could build bundles for many different browsers, and then had some Express middleware or Nginx rule that would serve the right bundle depending on the client's User-Agent header? That would be awesome!

I am a happily paying customer of CloudFlare. I love that all my javascript bundles are automatically cached on servers around the world to make them load faster for my users.

What if? 🤔

What if there was a service that would allow me to put a bundle of the most bleeding edge, unminified, Prettier-ified, modern JavaScript on my server, and have my brower's request be rerouted to a service that would read my User-Agent header, and serve a minified, uglified, transpiled bundle specifically tailored to my browser version, cached at my local CDN node?

Introducing...

Nah, I'm just kidding. I haven't built this. I have too many other startup irons already in the fire. I'm just throwing it out there as a "Wouldn't it be cool?" product idea, but I promise I'll be a customer if you build it.

It seems like it would be easiest for someone with the infrastructure in place already, like CloudFlare or DigitalOcean, to implement, but I bet a leaner company could handle it with a moderate cloud storage plan.

A few things to consider

• You'd need to have to be very confident in your User-Agent-to-browser-feature mapping. You can't make many mistakes there.
• Ideally you would automatically detect what esoteric features, e.g. Symbol or for...of, are being used in the code to know if you need a polyfill or not, but you could also do feature checkboxes on a settings screen.
• You might also consider pulling the code from a Github branch. 🤷‍♀️
• Doing all bundle versions lazily (on first request) might not be the optimal solution; it would require some thinking and testing.
• You could maybe provide source maps to people that had an auth cookie for your website.
• Might be a good idea to have a "dev mode" that puts in some error tracking code, like Rollbar or New Relic do, to detect edge cases when your User-Agent-to-browser-feature mapping wasn't up to snuff.

Conclusion

The minimum step in this direction would be an open source library for the Express middleware with a detailed description of how to tailor existing build tools to output browser-specific bundles - like this, but as a published lib. I'd also be grateful to learn of something like that. If you know of one, or have just finished building it after being inspired by this article, @ me on Twitter.

And if you don't want to build this and get filthy rich, but think it might make everyone's experience better on the web, maybe share this until it finds someone who does want to build it.

Updates

• @Raathigesh on Twitter pointed me towards Polyfill.io, a service from The Financial Times, that "reads the User-Agent header of each request and returns polyfills that are suitable for the requesting browser." And it's open source, too! 👍