Re: Prollyfills and the global namespace / multi-fills

(i'm getting the sinking feeling we have a fundamental disagreement about what a prollyfill is… but will follow that up when I respond to Tobie's email)


On Wednesday, July 3, 2013 at 8:46 PM, François REMY wrote:

> > > > Yes it is, it's supposed to exactly match (as much as it can in JS).
> > >  
> > >  
> > >  
> > >  
> > > Well, it matches the *current* spec. If someone use that code in  
> > > production,
> > > in a few time it will stop to match.
> >  
> >  
> >  
> > Why?
>  
> Because specs evolve...
A spec is evolving *because of* the polyfill - and so what? The prolly is just updated - prollies involve too.  The polyfill serves as the proof of concept and allows other prollyfills to be build (e.g., Telephony). Without Promise, I can't do my prollyfill.   
> The whole point of the warning I oultined is to  
> explicitely ask people not to implement the spec as-is because it's not  
> stable.

Specs are _never_ stable (even at Rec - it's why we have Living Standards now - to rid of the "stable" nonsense). The point of the prollyfill is to verify the spec, see how it feels to use, allow creation of a test suite, and hopefully gather a bit of feedback from some developers.  
> If we're doing it in JS, we're pretty much screwing the things  
> totally because when browsers will want to implement the spec for real, they  
> will break tons of websites using non-prefixed prolyfills. This is not an  
> hypothetical future, it already happened a lot.

Not if Websites do:

if(x in "window") before polyfilling. I.e., "responsible prollyfilling" - which is what we are trying to find a solution for.   

Also, you enter a contract when you use a prollyfill.  
  
> > > If the goal is to polyfill an existing REC/CR spec, it's okay not to use
> > > prefixes, because you can test your spec against test cases, and you can
> > > match existing implementations.
> >  
> >  
> >  
> > The whole point of the stuff I'm building is so to avoid
> > what is discussed in the manifesto: stop gawd awful
> > APIs from being put into the platform _way_ before
> > they get anywhere near CR (… even way before
> > Last Call).
>  
>  
>  
> Honestly, I don't see how prefixing the implementation would change anything  
> to that capability. However, I agree with Brian:

You can't run a test suite against the prollyfill that is prefixed. For example, "new Promise()" vs "new whomEver.Promise()".  
>  
> | Marcos, if you are feeling brave, pass in window.
> | If you are someone evaluating for the spec, use
> | window. For everyday use in situations I would
> | really like to use prollyfills - personally, I think
> | that is a dangerous thing to do.

That  can be said for any code. But will address Brian's email separately.   
> That's why we need modules, ie a way for people to choose themselves if they  
> want prefixing or not (and prefixing should be the default).

I'm happy to entertain the idea as it's cheap to enable. If there is a standard way to say "Gimme non-prefixed version", then we both get what we want.  
> > 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.

Sure, but this is the fundamental disagreement about terminology.  
> 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.

  
I've worked at two (Opera and now Moz), so I may know something about that.  

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

That's demostrable nonsense. None of the prollyfills I've created are used on any "real" websites, yet they've all have massive impacts on every spec I've prollyfilled. Would it be better (to inform design/usability issues) if they were used on more Websites? sure, of course. But 99% of the time prollyfills will not end up being used anywhere but to inform the standardization process. This is because prollyfills (that I work on) are things that the platform can't do today.  

For instance, I don't expect people to use Teleprolly because it requires you to physically hold a headset to a real phone to make a phone call. I also don't expect anyone to use adlib.js because it requires a proprietary plugin to be preinstalled. Other prollyfills I built required that Chrome's security policy be relaxed through a flag before they would work… so all these are hardly a threat to the Web. They are means of rapid prototyping: failing fast and hard, iterating quickly, and making a better spec.  
> Sure it can be on demo websites, but  
> as soon as it works, people will want to use it in production (why not?).  
> 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.

So this is a cascade effect problem - which is really the responsibility of the author. Libraries can also check the native brand, as it's unforgable with JavaScript objects.   

 Granted, prefixing could work, but it's also not free of side effects and its own range of issues (see http://tools.ietf.org/html/rfc6648 - which traces prefixing problems all the way back to 1975).

Received on Wednesday, 3 July 2013 23:32:51 UTC