Re: Is polyfilling future web APIs a good idea?

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

> But it's not deprecated in browsers that don't support it

Probably I still don't quite understand how prollyfill works.

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

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?

> 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

Received on Friday, 7 August 2015 03:05:47 UTC