Re: Is polyfilling future web APIs a good idea?

On Mon, Aug 3, 2015 at 9:07 PM, Glen Huang <curvedmark@gmail.com> wrote:
> Brian,
>
> prollyfills seems pragmatic. But what about when the logic of an API changes, but not the name? The node.replaceWith() API for example is about to be revamped to cover some edge cases. If the prollyfills exposed node._replaceWith(), what should it do when the new node.replaceWith() comes? Expose node._replaceWith2()? This doesn't seem to scale.
>

Why would it need to?  Just like any library, you import a version and
deal with incompatibilities when you upgrade?


> But I do see the benefit of prefixing in prollyfills. node.replaceWith() used to be node.replace(). If we exposed _replace() earlier, we can swap the underlying function with node.replaceWith() when we release a new version, and old code immediately benefit from the new API. But over time, prollyfills are going to accumulate a lot obsolete APIs. Do you think we should use semver to introduce breaking changes? Or these obsolete APIs should always be there?
>

Yes, I think authors will opt in to an API and that API may contain
breaking changes or backcompat changes, I think that's up to people
implementing and maintaining to experiment with.  Too early to say
what will be more successful, but I don't forsee things growing
forever - at some point people remove polyfills too in practice... In
theory you could use something like FT-labs polyfill as a service to
make any browser 'normalized' but that gets really heavy if it isn't
targeted and goes back too far in practice.  No one is even writing
polyfills for IE6 anymore - most don't even go back to IE8.


> And if we are going this route, I think we need blessing from the WG. They have to promise they will never design an API that starts with the prefix we used.

We have that in web components already (no native element will be a
dasherized name - in most practical terms, attributes too), for all
things CSS (-vendor-foo just has no vendor and becomes --foo) and when
you're talking about DOM - yeah, we dont have one, but no DOM will
contain an leading underscore, I can just about promise that without
any agreements - but I agree it'd be great if we just had one.



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Received on Tuesday, 4 August 2015 03:05:44 UTC