Re: Alex Russell on Polyfills and some other thoughts...

On Nov 17, 2012 10:09 AM, "Marcos Caceres" <marcosscaceres@gmail.com> wrote:
>
> 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
>
>

That would pretty nice, though I think we should probably discuss the
implications of that... a prollyfill probably shouldn't make any
assumptions in the native space because it isn't forward compatible.  I
expect this is one of the primary things that needs discussion:  I prefer
the proposed api go into a prefixed or data- or x- form so that it is
parallel with the proposal, so if it evolves to the point where it becomes
native there is no risk of the unexpected.

Brian Kardell :: @bkardell :: hitchjs.com