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

On Saturday, 17 November 2012 at 15:25, François REMY wrote:

> | 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).
>  
> My thought is that this is more the responsability of the other WGs to make  
> sure they transform "wanna-be-popular" prolyfills into native  
> implementations as soon as possible, not really the one of the prolyfill  
> author. According to you, what should a prolyfill author do to make sure  
> this doens't become the case?

I don't know yet. That's what I'm hoping we will find out :)    
> | I'm interested in having a 1 to 1 match between HTML5
> | algorithms and prollyfills. 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.
>  
> Agree. A good prolyfill should try to follow the spec. However, implementing  
> an ever-chaning spec is never without risk, you can't erase that fact.

Right, but that's the nature of this business. It's why open source development and and active community is so crucial. Point being, it's can be a self correcting problem as long as people care enough to:  

1. follow the spec (and participate in its development).
2. users of technology have a way to file bugs and communicate.
3. bugs get fixed and updates reach the people using the technology.  
     
> | 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.
>  
> A sort of code generator, you mean? I'm fond of code generators :D
Yes, exactly.   
> I would love to work on that! I don't think it's gonna be difficult, what's  
> will be more difficult will the "framework" as you call it (ie: the  
> functions required to make the real implementation effective and close to  
> the standards). The kind of things like we discussed last week (like "throw  
> a new DOMException").  

Agree, this comes back to my question of architecture: the architecture is larger than the software architecture, it's also about the social architecture that enables something like this to work.   

Received on Saturday, 17 November 2012 16:38:45 UTC