Re: Prollyfills and the global namespace / multi-fills

On Thursday, July 4, 2013 at 9:39 AM, François REMY wrote:

> > Generally speaking: I'm no longer going to call the things I work on  
> > prollyfills -
> > going to call the things I work on something else: they are "prototype
> > reference implementations" of real specifications explicitly meant to  
> > inform
> > the standardization process (verify spec prose and WebIDL, produce/verify
> > test suites, and allow interested people to take an API for a test  
> > drive) - and
> > not necessarily to be used for anything else.
>  
>  
> Originally, I used a different name for them too. I think the main  
> difference between a prollyfill and a prototype implementation is the  
> ability to actually use the prototype on a real website.  

Making them capable of being used for production can be a good defining feature/differentiator. I would be in favor of making that part of the definition.  
> Prototype  
> implementations may use "non-standards stuff", "local servers" or "plugins"  
> like in http://html5labs.interoperabilitybridges.com/.

Yep. Those are the things I'm interested in building… next time, I should apply at Microsoft :)  
> > I thought those were prollyfills, but turns out I was wrong - but that's a  
> > good
> > thing. I personally see tremendous value in "proto-ref-imps" (oh yeah!  
> > that's
> > totally gonna catch on:)) - and encourage others in also building them  
> > align
> > with these prollyfill things (whatever those are).
>  
>  
>  
> Some specs (like CSS Regions, WebCrypto, ...) allow prollyfilling, some  
> others don't. Hardware-tied specs are rarely allowing that since you don't  
> have access to the device before.

Where there is a will, there is always a way :)  
> I'm totally with you that the fact a spec can't be prollyfilled is not a  
> good excuse not to build a JavaScript prototype: as you said, this is an  
> experience you can learn a lot from, I'm totally convinced of that.

The API surface (i.e., the WebIDL) can always be coded, even if you don't get access to the underlying system. That's what I'm mostly interested in.   
> But, as  
> you note, it should be clear to people this is not something they can use in  
> production. In the interoperability bridge team, they use this disclaimer:  
> "Note that as with all previous releases of HTML5 labs, this is an  
> unsupported component with an indefinite lifetime. This should be used for  
> evaluation purposes only and should not be used for production level  
> applications."

I will add something similar to my prototypes, just to be safe. We should probably do the same with Promise.js?  

This thread was quite productive and clarified quite a few things, so thanks for enduring the back and forth!

Received on Thursday, 4 July 2013 09:58:48 UTC