Re: Is polyfilling future web APIs a good idea?

On Aug 6, 2015 11:05 PM, "Glen Huang" <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> wrote:
> >
> > On Thu, Aug 6, 2015 at 6:50 PM, Glen Huang <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
>