Let's run through a story you may already be familiar with.
Being the quick-thinking, problem solver you are, you immediately start digging into work-arounds to still be able to use what you just vested your heart and soul into. Normally, this path leads us to what is often referred to as a polyfill. A polyfill, simply put - is a snippet of code that extends the browser to support what we expect for it to provide to us natively. So, how does this normally look? Below is a basic example of what we'd do to "plug" browsers that don't support
Pretty simple, right? When adding polyfills to your project, there's two ways this can be handled:
- Bundle them directly in your dependencies. If you're checking for native support before plugging, there's certainly nothing wrong with this. The "bloat" you add is all based on the number of polyfills and their complexity.
- Browser-specific files. If you're targeting specific browsers, then building bundles of polyfills is a great way to further control what is being served up to your visitors in smaller chunks.
For me, the above two options feel more like "choose your own poison" that really aren't that appealing at the end of the day. With either, you're left with another layer of manual upkeep. And let's face it, you may be able to use HTML comments for IE conditionals to target those browser versions, but especially in the product world, your site is used by a vast array of browsers with LOTS of deficiencies.
Now, let's move outside of your library and think about another library that you don't control that is also being used by an end-user. The developer of the other library came across a similar issue just as you have, did their research and implemented what they felt would get them them to the finish line. Wait a second, so we now have two polyfills for
requestAnimationFrame? How does that work? Well, here's where it starts to break down. If another library polyfills a specific function before yours is parsed, then that function will appear "native" to the browser at this point, meaning your polyfill is never read. What's the harm in that? Potentially - lots. You may have done your homework, but what if the function they included isn't really solving the problem? Or, what if it ultimately does the same thing, but accomplishes it in a very resource-intensive way?
As we start to dig deeper into this, layers upon layers of polyfills within an open-source community can be frustrating at times. How do you not only vet these polyfill solutions you depend on; sometimes unknowingly, but also make sure you don't have competing solutions from 3rd party vendors?
Remember the options we had above for manually including polyfills in our project? What if there was a resource that not only sent down community-vetted polyfills, but also only sent down the polyfills needed based on the browser that was visiting the site at that time? There is.
Polyfill.io is a service that (taken from their docs):
Now, at the end of the day, code is written by humans. Could the polyfills they send down not be as performant as others? Potentially. The great thing is, this is an ever-growing library that you can contribute to! Submit issues, ask questions and if you know of a better way to do things, then suggest it!
Moving forward, I'm removing the polyfills I used to bundle in each library and letting the user decide the browsers they want to support. If you'd like to use the awesome service I just mentioned - great! If not, that's cool too. You make the decision based on what you need. I'll certainly be including a link to Polyfill.io in each project README to better educate the community on this service and what it means moving forward.