Re: Prollyfills and the global namespace / multi-fills

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

--tobie

Received on Wednesday, 3 July 2013 21:21:17 UTC