[webkit-dev] Is vendor-prefixing JavaScript APIs a waste of time?

[Adam Barth]

The IE blog has had a couple posts recently about new JavaScript APIs
that are vendor prefixed:

http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-1.aspx
http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-2.aspx

Here's one of their code examples:

----8<----
// Future-proof: when feature is fully standardized
if (window.requestAnimationFrame) window.requestAnimationFrame(draw);
// IE implementation
else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw);
// Firefox implementation
else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw);
// Chrome implementation
else if (window.webkitRequestAnimationFrame)
window.webkitRequestAnimationFrame(draw);
// Other browsers that do not yet support feature
else setTimeout(draw, PERIOD);
---->8----

There are a couple things to notice:

1) The requestAnimationFrame API has a vendor prefix in all of these
implementations, making this code ugly.
2) The vendor prefix isn't buying us anything because this code
assumes that the final, non-prefixed version of the API will work the
same way that the vendor prefixed version works!

If web developers are going to assume that future, non-prefixed
versions of the APIs work the same way as current prefixed versions of
the APIs anyway, we shouldn't bother with prefixed versions because
we're already locked in to the current behavior, even without the
prefix.

Adam