Polyfills and products

I was chatting about polyfills recently with Bruce and Remy—who coined the term:

A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will.

I mentioned that I think that one of the earliest examples of what we would today call a polyfill was the IE7 script by Dean Edwards.

Dean wrote this (amazing) piece of JavaScript back when Internet Explorer 6 was king of the hill and Microsoft had stopped development of their browser entirely. It was a pretty shitty time in browserland back then. While other browsers were steaming ahead with browser support, Dean’s script pulled IE6 up by its bootstraps and made it understand CSS2.1 features. Crucially, you didn’t have to write your CSS any differently for the IE7 script to work—the classic hallmark of a polyfill.

Scott has a great post over on the Filament Group blog asking To Picturefill, or not to Picturefill?. Therein, he raises the larger issue of when to use polyfills of any kind. After all, every polyfill you use is a little bit of a tax that the end user must pay with a download.

Polyfills typically come at a cost to users as well, since they require users to download and execute JavaScript in order to work. Sometimes, frequently even, that cost outweighs the benefits that the polyfill would bring. For that reason, the question of whether or not to use any polyfill should be taken seriously.

Scott takes a very thoughtful approach to using any polyfill, and I try to do the same. I feel that it’s important to have an exit strategy for every polyfill you decide to use. After all, the whole point of a polyfill is that it’s a stop-gap measure until a particular feature is more widely supported.

And that’s where I run into one of the issues of working at an agency. At Clearleft, our time working with a client usually lasts a few months. At the end of that time, we’ll have delivered whatever the client needs: sometimes that’s design work; sometimes its design and a front-end pattern library.

Every now and then we get to revisit a project—like with Code for America—but that’s the exception rather than the rule. We’ve had to get very, very good at handover precisely because we won’t be the ones maintaining the code that we deliver (though we always try to budget in time to revisit the developers who are working with the code to answer any questions they might have).

That makes it very tricky to include a polyfill in our deliverables. We’d need to figure out a way of also including a timeline for revisiting that polyfill and evaluating when it’s time to drop it. That’s not an impossible task, but it’s much, much easier if you’re a developer working on a product (as opposed to a developer working at an agency). If you’re going to be the same person working on the code in the future—as well as working on it right now—it gets a lot easier to plan for evaluating polyfill usage further down the line. Set a recurring item in your calendar and you should be all set.

It’s a similar situation with vendor prefixes. Vendor prefixes were never intended to be a long-lasting part of any style sheet. Like polyfills, they’re supposed to be used with an exit strategy in mind: when the time is right, remove the prefixed styles, leaving only the unprefixed standardised CSS. Again, that’s a lot easier to do if you’re working on a product and you know that you’ll be the one revisiting the CSS later on. That’s harder to do at an agency where you’re handing over CSS to someone else.

I’m quite reluctant to use any vendor prefixes at all—which is at should be; vendor prefixes should not be used lightly. Sometimes they’re unavoidable, but that shouldn’t stop us thinking about how to remove them at a later date.

I’m mostly just thinking out loud here. I guess my point is that certain front-end development techniques and technologies feel like they’re better suited to product work rather than agency work. Although I’m sure there are plenty of counter-examples out there too of tools that really fit the agency model and are less useful for working on the same product over a long period.

But even though the agency world and the product world are very different in lots of ways, both of them require us to think about the future. How will long will the code you’re writing today last? And do you have a plan for when it needs updating or replacing?

Have you published a response to this? :



# Shared by Jason Pamental on Friday, October 3rd, 2014 at 4:49pm

# Shared by Scott Jehl on Friday, October 3rd, 2014 at 4:49pm

# Shared by Todd Parker on Friday, October 3rd, 2014 at 5:48pm


# Liked by Mat Marquis on Friday, October 3rd, 2014 at 5:47pm

# Liked by Ethan Marcotte on Friday, October 3rd, 2014 at 5:47pm

# Liked by Matt Steele on Friday, October 3rd, 2014 at 6:02pm

# Liked by Scott Jehl on Friday, October 3rd, 2014 at 6:02pm

# Liked by Alex Morris on Friday, October 3rd, 2014 at 6:02pm

# Liked by Max Fenton ✰ on Friday, October 3rd, 2014 at 6:02pm

# Liked by Tom Leadbetter on Friday, October 3rd, 2014 at 6:14pm

# Liked by Anne Petersen on Friday, October 3rd, 2014 at 9:01pm

# Liked by Todd Parker on Friday, October 3rd, 2014 at 9:02pm

# Liked by James Drinkwater on Friday, October 3rd, 2014 at 9:12pm

# Liked by Marc Drummond on Saturday, October 4th, 2014 at 3:14am

# Liked by Matt Stow on Saturday, October 4th, 2014 at 1:12pm

# Liked by Jonathan Dallas on Sunday, October 5th, 2014 at 6:00pm

Previously on this day

7 years ago I wrote Scrollin’, scrollin’, scrollin’

Keep them updates scrollin’.

12 years ago I wrote España

Next stop: Asturias.

15 years ago I wrote Earth shattering

My brother-in-law lives and works in Seattle. That’s his workplace they’re talking about in this article in this Newsweek article about Starbucks.

16 years ago I wrote Liggin'n'giggin

I’m feeling a bit fragile today after a somewhat hedonistic night out.

18 years ago I wrote Tony comes to Brighton

Tony Blair was in Brighton today for the Labour party conference. Here’s the full text of his speech. It’s pretty stirring stuff although mentioning Europe right now smacks a little of opportunism. Overall, a good speech from a great speaker.

18 years ago I wrote The W3C Patent Policy

The World Wide Web Consortium has come under a lot of fire recently for burying a proposal that would allow its recommendations to be released under a fee-paying licence.