In today’s episode, I talk about how to use platform features across various browsers.
Today, I’m talking about how to use the platform when platform features aren’t evenly distributed. Let’s dig in.
So one of the often repeated phrases among Lean Web evangelists like me is to use the platform whenever possible. I actually talked about this a few episodes back. It’s one of the core principles of the Lean Web.
And browsers are much better at implementing features in a cross-compatible way. Again, this used to be a huge issue like a decade or two ago. But that doesn’t mean platform features are evenly distributed. Different browser vendors prioritize different things.
As a result, some modern features end up available, but not for everyone. So how do you deal with that?
Option one is to use polyfills.
A polyfill is a term coined by Remy Sharp for a snippet of code that adds support for browser features to browsers that don’t offer them natively. When you can polyfill, well, you can sometimes polyfill CSS features.
The polyfill code checks if the browser has native support for the feature, and if not, creates it and implements it to the browser spec for you. For example, a polyfill for the array prototype for each method, which is now universally supported, might work a little bit like this. It would have an if check.
So if there is no array prototype for each method, it will create an array prototype for each method, set it equal to a function, and then in that function, accept a callback, where inside the callback, it’s going to loop over each element in the array and then run the callback method on it.
Now, the best thing about polyfills is that they’re designed to be deleted. Once browser support catches up, you can delete the polyfill without having to refactor any of your code.
Option two is transpiling.
But some things like temperate literals or a template literals rather, or let and const, there’s no way to polyfill those. For that, you need transpilation.
You would write your code the way you normally would. And the transpiler would spit out any instance of let or const would get replaced with var. If you had a template literal, it would break that into chunks and use string concatenation to combine those together.
These days, transpilers have a much smaller role in web development, in my opinion. But depending on the project, they can still have their place.
Option three is progressive enhancement.
For features that are non-critical, progressive enhancement is a great approach. I use this a lot for CSS features. So if the modern CSS isn’t supported and it not working won’t result in a broken site, I will progressively enhance it.
A dated example of this would be a modern layout with something like CSS Grid or Flexbox. You could use them to create a layout, and then if they’re not supported, the user just gets a simple single page column layout instead.
It’s not fancy, but it still works.
For a while, I treated details and summary elements as progressive enhancement as well. If the browser didn’t support them, the user would still get all of the content with a heading, though not a semantic heading element above it as the default. It wasn’t as pretty, but it was still perfectly usable.
So which approach should you use?
That’s it for today. I’ll see you next time. Cheers.