Alex Russell on Polyfills and some other thoughts...

Hi All,  
I found this talk by Alex really relevant to this group.  

https://vimeo.com/53373706

I tend to agree with him that we should proceed and frame what we do with caution, in as far that widespread proliferation of polyfills is not a good thing. However, in terms of framing, I like prollyfills in that it allows us to potentially experiment with tomorrow's stuff today. This brings up some important architectural questions (i.e., avoiding a prollyfill becoming a polyfill).  

Having said that, I've been thinking about the problem of prolly-fillin' APIs for a while - in particular, I'm interested in having a 1 to 1 match between HTML5 algorithms and prollyfills. Consider this one I'm working on at the moment:  

https://github.com/ResponsiveImagesCG/picture-refimp/blob/master/srcsetfill.js

In that, see the HTML object in which I'm adding the relevant algorithms from HTML5 (e.g., splitStringOnSpaces, parseNonNegInt, parseInteger). These algorithms may or may not behave in the same way as akin ECMAScript algorithms, so they provide as true as possible conforming implementation to HTML5 (and specifications that build on top of it). So, when implementing a polyfill for an element, a developer can just hook into those functions, as they are the ones that are relied upon in the HTML5 spec.  

Ideally, from APIs what I would like to see is a magical framework that does the following: given a Web IDL fragment and a set of corresponding values, the framework spits out Javascript code that implements a given interface for you.

So, given Web IDL:  

interface Foo(){
  readonly attribute bar;  
  string foofoo();  
}  

The developer would then implement foofoo() and "bar" in a manner like this:

{foofoo: function(){
…whatever the spec says to do
},
attributes:[{bar: function(){
… whatever needs to be done to determine bar
}} ]
}  

And then just wires together all the WebIDL error handing around that.  

Thoughts?  

     

--  
Marcos Caceres
http://datadriven.com.au

Received on Saturday, 17 November 2012 15:08:58 UTC