Re: Prollyfills and the global namespace / multi-fills

> 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. Prototype 
implementations may use "non-standards stuff", "local servers" or "plugins" 
like in http://html5labs.interoperabilitybridges.com/.


> 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.

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. 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."

Received on Thursday, 4 July 2013 08:39:23 UTC