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.  

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

Having said that, as we've discussed, there is good practices and hygiene that can be applied to them: like wrapping them in such a way that, where possible, things like the global scope and window become configurable/overridable, and, as François suggested, console warnings. And worst case, use some kind of namespacing when possible (though I'm sure this will end in tears, as it always does).  

Responses to Tobie inline…  

On Wednesday, July 3, 2013 at 10:21 PM, Tobie Langel wrote:

> On Wednesday, July 3, 2013 at 9:46 PM, François REMY wrote:
> > > Ok, I can see where there could be potential clashes for
> > > unmaintained code. But I think this would be rare.
> >  
> >  
> >  
> > It's not rare at all. Most websites are unmaintained, and they hold the web  
> > platform back. Ask any implementor for stories where unmaintained websites  
> > slowed down the unprefixing or the introduction of new APIs because of  
> > conflicts, you'll see for yourself.
>  
> We had serious issues back in the days with PrototypeJS for document.getElementsByClassName, Function.prototype.bind, Array.prototype.reduce, Array.prototype.indexOf, Array.prototype.toJSON, String.prototype.toJSON, document.querySelectorAll, etc.
>  
> This is absolutely going to happen.
Was the problem that you were not able to tell if all those method's .toString() function returned "function valueOf() { [native code] }"? Or that those had been hijacked even though the browser did support the real deal?  
  
> > > I'm just thinking there is a differentiation to be made
> > > between a library and prollyfill (which is intended to
> > > inform a standardization process, for instance).
> >  
> >  
> >  
> > Prollyfills -can- inform standards bodies. But for that to be effecient,  
> > they have to be used on real websites. Sure it can be on demo websites, but  
> > as soon as it works, people will want to use it in production (why not?).
>  
>  
> Yeah, these will run in prod weeks after release. And then won't be touched for years.
Sure.  
>  
> >  
> > We've to make sure this prollyfilling approach does not harm the web by  
> > spreading old versions of specs on the global namespaces other scripts  
> > mistakenly take for a native implementation.
>  
>  
> A possible approach would be to agree on a way to mark prollyfills (seriously who came up with _that_ term?)
I read that "Alex Sexton coined the term “prollyfill” on Twitter" [1]… let's get him! :)  
> as such so that if things get awry (and they will) there's at least an easy way to distinguish them from native code, e.g.: have a prollyfill property with a version string.

Sure, but we should also request this functionality from the TC39 folks (there a few lurking here). That is, some reliable ways to check if something is a host object/function or not. We have the following to check the native brand (or whatever it's called now) of an instance:

Object.prototype.toString.apply(V)

There may be other more sophisticated tricks coming in ES6 to reliably check if a function is natively implemented (or not). But I don't know - might not even be possible.  

[1] http://briankardell.wordpress.com/2012/11/17/w3c-extensible-web-community-group/

Received on Thursday, 4 July 2013 00:58:30 UTC