Re: Is polyfilling future web APIs a good idea?

Awesome. Now I think I understand the full picture you described.

When trying to offer a feature that is still being specced, prefix the specced APIs, and once the spec is stable, for browsers that don't ship these APIs, alias the prefixed ones by dropping the prefix. Is that correct?

> On Aug 10, 2015, at 9:33 PM, Brian Kardell <bkardell@gmail.com> wrote:
> 
> On Aug 6, 2015 11:05 PM, "Glen Huang" <curvedmark@gmail.com <mailto:curvedmark@gmail.com>> wrote:>
> 
> > > This assumes you'll match
> >
> > That's a good point. I agree for most APIs it's probably better to simply use polyfill code for all browsers. But some APIs have some extra benefits that might not be polyfillable. For example, the native version of web animations happen in a compositor thread, so google's web animations polyfill use native APIs when they exist and only provide polyfill when they don't.
> >
> Right, and if "ABC Co." shipped software a few years ago before that was available they probably used jQuery animations and if they haven't touched their site since then it still works - in fact, it very likely works much better because the trend for performance is always improving.  If they came back later and used the animations polyfill it takes advantage of some additional stuff on the compositor thread in some browsers.  If this is really a polyfill because it is a settled standard then as browsers implement they should automatically get the same boosts because we can ensure future interop - no harm no foul.  You couldn't though have a mix of all of those worlds - we couldn't have old jQuery code, reinvent how it's expressed/capable of on the way to standards and somehow automatically fill the old code - the best you can do there is improve general performance. If there are underlying tools in some browsers that help you solve a prolyfill better, you can use them in the same way - but you can't really prognosticate that that's exactly how it's going to come out the other end when the standard ships.
> 
> > > But it's not deprecated in browsers that don't support it
> >
> > Probably I still don't quite understand how prollyfill works.
> >
> 
> I don't feel like there are standard best practices worked out here - I'm giving you my own perspective as someone who has spent an inordinate amount of time thinking about this, I am not speaking for anyone else here - your mileage may vary - but I'm advocating it's worth developing some.
> 
> 
> > Let's say the prollyfill offered node._foo(), one browser shiped experimental node.foo(), users ignored that, and used our polyfilled version. Everyone was happy. Then other browsers are on board, this API becomes stable. Now, what should the prollyfill do?
> >
> > Should it still ship node._foo() and expect users to use that when most browsers ship node.foo() and this API has a precise definition?
> 
> > Or it should deprecate node._foo(), polyfill node.foo() for browsers still don't support it and encourage users to switch to node.foo()?
> 
> Of course when it is a standard, released and interop - it's a polyfill... For the polyfill maker I expect at that point they would simply lose the underscore and, perhaps to make it easy for authors they could just make _foo an alias of .foo (which was my example one liner)...  It's entirely up to authors whether they will even go back and update their code and imports and how they will do so -- their old code will continue to work just fine.  But a lot of authors will be happy to gain perf if there is no rewrite involved (ie, if they happened to use a version that is ultimately compatible with the final standard)  and there's not really a penalty in using an aliased name for a method, so that's the approach I would likely use or at least document.   
> 
> > Or it should do something else?
> >
> > I don't quite understand the oneliner you gave:
> >
> > HTMLElement.prototype.foo = HTMLElement.prototype._foo;
> >
> > Why would you want to overwrite a native API with polyfill? How does that work for users? Users can choose either native API or prollyfill's prefixed version and they will both use the polyfill?
> 
> You wouldn't want to overwrite a native API, I'm not suggesting that -- I'm suggesting that if you have a prollyfill implementation already which happens to match the final spec interoperably you can both keep your existing uses working and polyfill with the one-liner above for implementations that don't support it.  I guess I thought that much was implied, sorry for the confusion but - it's meant to be in an if or conditional of some kind.. Could be as simple as adding this to the end of your file at this point (ie, when it is actually a polyfill):
> 
> HTMLElement.prototype.foo = HTMLElement.prototype.foo || HTMLElement.prototype._foo;
> 
> The important part here is that ideas for _foo can compete because it is up to authors to decide what ._foo should look like because they import a specific definition.  It can evolve, updates can involve breakage, but it's up to the author to determine whether they are even going to update -- if the very first pass at ._foo worked for you, it'll keep working in production when you've moved on to some other contract -- it'll even keep working once there is a native .foo if that ever happens, but unless you go and specifically opt in an update, make sure there isn't API breakage - you won't get native benefits automatically, because we can't peer into a crystal ball and know that will be the fact.
> 
> 
> 
> >
> > > On Aug 7, 2015, at 7:07 AM, Brian Kardell <bkardell@gmail.com <mailto:bkardell@gmail.com>> wrote:
> > >
> > > On Thu, Aug 6, 2015 at 6:50 PM, Glen Huang <curvedmark@gmail.com <mailto:curvedmark@gmail.com>> wrote:
> > >> @William @Matthew
> > >>
> > >> Ah, thanks. Now I think prollyfill is prolly a good name. :)
> > >>
> > >> @Brian
> > >>
> > >> Actually, I had this pattern in mind:
> > >>
> > >> When no browsers ship the API:
> > >>
> > >> ```
> > >> if (HTMLElement.prototype.foo) {
> > >>  HTMLElement.prototype._foo = HTMLElement.prototype.foo;
> > >> } else {
> > >>  HTMLElement.prototype._foo = polyfill;
> > >> };
> > >> ```
> > >
> > > This assumes you'll match, which - again depending on how far you are
> > > might be a big bet... Personally, I wouldn't use that myself if
> > > writing something -- Seems a lot like  when people simply provided N
> > > versions of the same prefixed properties instead of just one, it has
> > > potential to go awry... No one can actually vary because they've done
> > > the equivalent of shipping the unprefixed thing inadvertently
> > > intending it to be an experiment, but it wasnt.
> > >
> > >>
> > >> When at least two browsers ship this API:
> > >>
> > >> ```
> > >> if (!HTMLElement.prototype.foo) {
> > >> HTMLElement.prototype.foo = polyfill;
> > >> }
> > >> HTMLElement.prototype._foo = function() {
> > >>  console.warn("deprecated");
> > >>  return this.foo();
> > >> };
> > >> ```
> > >
> > > But it's not deprecated in browsers that don't support it, it's a
> > > polyfill at that point and aside from the console.warn (which again,
> > > in this case seems incorrect in the message at least) it should be
> > > generally be identical to the oneliner I gave before - the prototype
> > > for _foo is the polyfill version.
> > >
> > >
> > >
> > > --
> > > Brian Kardell :: @briankardell :: hitchjs.com <http://hitchjs.com/>
> >