Infrequently Noted

"Just tell us the use cases" is a bit of a strawman, though I see where it comes from. "Document your use cases" is a different statement. I'm glad that this is now common enough for you to call it out as a failing; to me that represents progress over the 'Here's my theoretical feature that I am going to make this standards body legislate into existence" approach. Is part of the problem that extending browsers via native code plugins is now so far out of fashion that we don't have models for behaviour we want them to adopt? Without QuickTime and WindowsMedia to look at for video or Flash to look at for canvas, would they have happened?

I feel to be out of the context. What does the "pollyfill" term mean? Some sort of backward compatibility with previous api?

Well said, sir! An excellent article, and many excellent points. It's good to hear a voice on the outside echoing what the voice in my head has been screaming for years.

@Aliaksandr: It's somewhat the opposite, actually - it's like forward compatibility for old browsers. If you're using IE6, the only way to get nifty new APIs and HTML5/CSS3 features is to "fill" in the missing pieces with Javascripts that serve the same purpose. Remy Sharp put it well: http://remysharp.com/2010/10/08/what-is-a-polyfill/

...now trying to remember what I said at our meeting on appCache the other day, and see if I offended or enlightened...

Kevin: you end with a fascinating question. My guess is that "native" platforms are the new "plugins" in this respect. They're what'll keep those of us who care about the web up at night, worried that we'll be eclipsed and/or doomed to some platform backwater. Goodness knows that's the explicit strategy of every native platform -- it has to be -- and why I'm grateful that ChromeOS and B2G are out there still working towards the "the web is the inevitable model" end-game.

But the fact that native platforms aren't as all-up-in-your-business as plugins is an interesting thought. It might help create a blind spot in the competitive assessments of those of us who work on the web platform, encouraging us to take the "fallback system" view of the web and accept mediocrity too willingly.

With so much (healthy) competition, it's important for startups to be innovating at the sharp end. We've got to focus on the tiny bit of technology that's unique to our product and innovate around that. With such a small team (there's 2 of us), any time we spend doing stuff that's been done before effectively lessens our chances of differentiating our idea from the thousands of others being developed at the same time. I agree with you Alex on the two-tier system. Even those who have CS degrees need the basic stuff to get easier so we can concentrate on the hard bit of our app. We all waste time on the poly-fills in the same way that 5 years ago, we used to waste time on hacks for non-complaint browsers.

I try to avoid polyfills. They tend to hit the CPU of PCs running older browsers to the point of creating a poorer experience than simply leaving out a feature.

Regarding serving conditionally optimized JS or CSS, there is a business being built around this by companies like Strangeloop, Akamai and many others. Google site performance and most companies offering measurement tools also offer optimization.

I am all for including common functionality into the browser platform, native rather than plugins being optimal. Asking users to download a plugin? May as well go back to Flash then. Chrome frame is an exception which seems to be the best solution for Polyfill type forward compatibility. If MS would offer their own version of this with integration into security settings we could get corporate America into the modern age and allow for an evergreen experience there as well.

Thanks for your efforts. Keep fighting.