On defering to native implementations

[triblondon]

From @domenic:

I don't think this is a good idea. It ensures that your site behaves differently between old browsers and new. Maybe this should be phrased as "you may" not an implicit "you must". Perhaps "only in cases where it is known that the native implementation provides substantial advantages, and you are willing to accept the consequences of the site behaving differently depending on whether an older or newer browser is executing the code" or similar.

Brian:

with a 'legit' polyfill, that is, something as originally defined and not in any way speculative - something that has already multiple interoperable implementations, this is fine, right? I 100% agree with your concerns for anything that is not that case, but I'd like to clarify?

Domenic:

I have never seen a polyfill, 'legit' or not, which behaves observably the same as the spec it's based on in every case. So this recommendation is the TAG recommending that people introduce non-deterministic cross-browser inconsistencies into their sites, which is very unfortunate, even if "that's how everyone's already done it".

It's a tradeoff with severe negatives and in general very few positives on the side of delegating to the native implementation. Either the polyfill different from the native implementation, in which case you definitely don't want such cross-browser divergence; or it's very close to the native version, in which case you should just use the polyfill since it doesn't matter and then you avoid edge-case incompatibilities.

This tradeoff is why I suggested rewording it to include a strong "only in cases where..." warning.

[triblondon]

I think it's instructive to look at the debate going on over in https://github.com/w3ctag/polyfills/issues/6 between library authors who are talking about shipping polyfills with libraries. In most cases, a library author wants to make sure their library 'just works' in as many cases as possible to promote adoption and avoid negative sentiment. Though opinions differ about whether to bundle polyfills or not, everyone seems to agree on using native implementations where they exist.

There's also fairly broad acceptance that polyfills often don't fill for every part of the spec (eg picturefill author Scott Jehl here), and sometimes deviate either intentionally because of lack of resources or interest in comprehensiveness, intentionally because implementation in JS is impossible or impractical, or unintentionally.

I am stuck for how to resolve this point to everyone's satisfaction, and I fear that @domenic is not going to end up happy here. But we'll consider massaging the language to make clear that non-spec-compliant polyfills that defer to spec-compliant native implementations can be the root cause of problems.

[triblondon]

Travis: after tipping point, name can't change so polyfill authors have responsibility. Before that, deferring is dangerous. Yves: It seems that only browser vendors are claiming the right to break things David: Domenic seems to be arguing that polyfills should not exist at all. It is appropriate to defer, but only after tipping point.

[domenic]

David: Domenic seems to be arguing that polyfills should not exist at all. It is appropriate to defer, but only after tipping point.

I don't understand how you can interpret what I'm saying that way. Polyfills are great and should definitely exist! They just shouldn't defer to the native implementation.

[dbaron]

By "not exist", I guess I meant "not be a distinct concept", that is, if polyfills don't defer to native implementations, it's not clear to me how they're a separate concept from "library". (Or is your distinction that it's "library that prototypes what might be a new Web feature"?)

[domenic]

Yes, last I checked that was how the document defined polyfill.

[domenic]

There's also the factor that they usually squat on spec-sanctioned names on shared global objects or prototypes, whereas most libraries do not. We're just debating whether they should conditionally squat there (leading to determinism), or do so unconditionally (for safety).

[dbaron]

I think the key point of the finding is that there are two phases:

The first is when you shouldn't squat on names that would be likely to be used by a spec, and you shouldn't attempt to defer to native implementations. In this phase it's something that might be a future Web feature.

The second is when it's OK to squat on the name because it already has some interop, but you should defer to the implementations that provide that interop. In this phase you're filling in the implementation to make the feature work in old browsers when it exists in newer ones.

... and that the two characteristics (ok to squat on names, should defer to native) switch at the same time (the tipping point).

[domenic]

Yes, I understand the finding's concept of a tipping point. But what I'm arguing is that that has no bearing on whether or not it's appropriate to defer to native implementations.

Defering to native implementations does not provide the desired interop, unless your polyfill is perfect (and I've never seen such a polyfill). Always-overwriting provides perfect interop.

[dbaron]

Multiple native implementations don't provide perfect interop either. If authors would rather (a) use the native implementations of the feature (often faster) and (b) have something that is a different imperfectly-interoperable target in implementations without a native implementation of the feature, it seems reasonable for them to have a JS implementation for (b), even though it provides an additional imperfectly-interoperable target.

[domenic]

If authors would rather (a) use the native implementations of the feature (often faster)

This is precisely why I suggest adding

Maybe this should be phrased as "you may" not an implicit "you must". Perhaps "only in cases where it is known that the native implementation provides substantial advantages, and you are willing to accept the consequences of the site behaving differently depending on whether an older or newer browser is executing the code" or similar.

[dbaron]

So with that, I'd be uncomfortable about providing something that stomps on the native feature's name but isn't necessarily interoperable with it. It seems like it encourages developers to expect a behavior that might not be compatible with the native implementations. So if that's what you want, I'd still prefer both characteristics still live in phase 1, and the name used is different from the native feature.

What about saying that it's still OK to do the phase 1 stuff even after the tipping point has been passed, if that's what you want to do?

[domenic]

I don't really understand. This is all about phase 2 behavior. In particular,

So with that, I'd be uncomfortable about providing something that stomps on the native feature's name but isn't necessarily interoperable with it.

This is the behavior of most polyfills in phase 2, despite the best (or sometimes just halfhearted) attempts of their authors.

. It seems like it encourages developers to expect a behavior that might not be compatible with the native implementations.

That would be a good expectation, since it's true for every polyfill I've ever encountered! (Even in phase 2)

[triblondon]

Domenic, isn't is the oft-stated intention of browser vendors, in particular the one you work for, to fix the web by working with the way the web is, not the way you want it to be? For example, you test new Chrome builds with perf comparisons of top 1000 sites, right? To see if a change you made had a good or bad effect on sites as they exist today. You don't expect all those site authors to make a change, as much as you might want them to.

If all polyfills were unconditionally applying themselves regardless of native support, then rolling out new features to the web like that would not have any immediate effect because early adopters would have shipped a polyfill which would override your (better) native implementation. I can't help feeling that in this situation Google might find a way to apply the feature anyway. Kind of like the way browser vendors lie in the User-Agent header to achieve better compatibility, you'd justify this with something like "but it makes the web better".

Another angle on this is that developers using polyfill.io (about 750m bundles per month currently) are getting polyfills that are essentially conditional on the server-side, ie polyfill.io maintainers decide which browsers to send them to. By your logic the whole concept of polyfill.io is bad, whereas I can't see how it can be a problem if a developer who doesn't have time or resources to test old browsers chucks in a polyfill.io request (because it's essentially free on new browsers) in the hope that it might improve the experience for users stuck on older clients (testimonals support the idea that this is in fact what happens).

So I can't agree that polyfills should only defer to native implementations in extremis - I think a compromise exists where polyfills are careful not to prematurely define behaviour that may be different natively (pre-tipping-point), but are able to conditionally fill in for behaviour that is well known and well supported in the latest clients (post-tipping-point) without suppressing the ability of those newer clients to take advantage of their superior implementations.

Yes, the polyfilled versions will not be the same, will not offer an exactly identical API. But when perfect is unachieveable Good Enough will do.

[domenic]

I don't think unfounded speculation about Google's future actions is helpful. And I do agree you have a conflict of interest in running polyfill.io; I am surprised you have not recused yourself from this entire discussion.

[triblondon]

If that's your view we're not going to come to agreement, unfortunately, because I can't see how I can possibly have a conflict of interest if you don't. Equally David, Travis, Dan, Alex... we all want to make the web better for everybody.

Maybe I'll try a different tack - can you bring anyone else to this thread who can support your viewpoint?

[domenic]

I'm sorry, I just can't really see the point in discussing this with someone who has in the past used the document to push his own service on others with explicit references to polyfill.io, and is clearly invested in making sure the paradigm of his service is supported. I agree we're not going to reach agreement if you think that's acceptable.

[annevk]

I don't really understand why @domenic's point of view is controversial. I'm pretty sure we've hit issues in the past precisely because of the point he makes (I believe with getElementsByClassName() "polyfills" were not returning live lists).

@dbaron seems to make the point that the polyfill has to be perfectly interoperable with the native implementation. Only then is it phase 2 material, but then @triblondon seems to disagree with that, but is then asking if anyone else supports @domenic's point of view? It seems @dbaron does, for one. And I do too.

[dbaron]

I'm not arguing that a polyfill has to be perfectly interoperable with the native implementations -- I'm arguing that interop has to be good enough for its users, just like interoperability of native implementations has to be good enough for their users.

[annevk]

How would you measure good enough? Browser implementations have to be really close to identical. Subtle differences turn into compatibility issues all the time. How would a polyfill developer know whether they met the bar?

[dbaron]

Because people choose to use their polyfill? Or perhaps because they fix the bugs their users report? (Polyfills are a bit different from native implementations because developers are choosing to use them.)

[tobie]

One of the things I was hoping we'd achieve with web-platform-tests at some point was to be able to run the test suites with different polyfills on each platform. I have no idea how difficult that would be to setup, but it would certainly help answer the question of "good enough."

[annevk]

@dbaron yes, they chose to use them and run them in their browser of choice, which may or may not implement it natively. And then the user has a different browser with the opposite of the developer's browser and you run into issues. We know from compatibility issues we hit that the quality assurance is just going to be way different.

@tobie that might work, but we're pretty far from that.

[mathiasbynens]

I’m guilty of authoring several “spec-compliant” polyfills in the past, but the arguments made here and in earlier discussions have convinced me.

By using a polyfill instead of a shim, you risk:

1. relying on non-standard behavior
   • if the polyfill happens to not match the spec
   • if the spec/proposal changes after release
   • if the spec/proposal is rejected/removed
2. decreasing code coverage / increasing debugging complexity
   • if the main browser you’re testing in has a native implementation, the polyfill does nothing, and you might not even notice problem 1
3. breaking the web
   • if an older, no longer spec-compliant, version of the polyfill has widespread usage, this might prevent browsers from shipping an updated native implementation

Why run the risk of all that when it can be so easily avoided? Use a shim / ponyfill / whatever people call it nowadays instead, and drop the shim once the spec has stabilized and is natively supported across the board.

[triblondon]

To clear up some possible ambiguity, in an earlier comment @dbaron noted that @domenic appears to object to Polyfills as a distinct concept. @domenic replied:

Polyfills are great and should definitely exist

This confusion arises because we are defining polyfills to be any emulation of a web platform feature, whether or not they defer to native, and this also fits the definition of a shim. As originally defined by Remy Sharp, a polyfill does defer to native (and of course back then there was no mention of prollyfills / notifills / speculative polyfills / ponyfills).

We've moved on from this, and today we need a more nuanced approach to try and guard against breaking the web. But it strikes me as rather an extreme view to say that, for example, if all browsers except one have shipped a feature (let's say web components for instance), you should ignore all those implementations and continue to use a shim in all browsers to emulate that feature's functionality. Then when support is finally universal, you pull the shim and rewrite your calls to use the feature natively. What if one browser never implements the feature?

Or are we saying that in this scenario you should feature-detect and then somehow shrinkwrap that detection state at deploy time, so that, for example, you will use the native feature in browser A, but will use the shim in browser B, even when browser B finally releases native support, until you modify your code once you've tested your site against browser B's implementation? If so, how does that work in practice?

Addressing @mathiasbynens's point, I think we can all agree that one thing the web guarantees is that everything which was at some point in time cool, will persist in the memory of the web forever. There are still thousands of websites that use Mootools, scriptaculous, jQuery 1.4.2 (a wonderful vintage!), and these sites won't be updated. They come from agencies, or from corporations that won't fund continuous maintenance of all their web projects. Shims won't be removed.

Personal example: The FT is one of the better companies for tracking and looking after our web properties, and we still can't tell you how many we actually have (we're working on it).

My suggested policy here is simply that there is a line (the "tipping point"), and when we cross it, deferring to native is the right thing to do. Can we agree that this is a reasonable principle and we just need to work on where to draw the line, or are you (@domenic, @annevk, @mathiasbynens et al) really arguing for the position of never deferring to native, ever? And if so how do you address the almost-but-not-quite-universal support scenario?

[triblondon]

One reference for the jQuery 1.4.2 point: https://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/

[annevk]

I think if the majority of people end up running the native code from day one, having JavaScript fill in for the remainder is unlikely to be problematic, assuming suitable feature detection leading to the JavaScript never to be run long term.

I'm mostly worried about early implementation bugs being cemented, renaming being impossible, etc.

[triblondon]

@annevk OK, so in principle, in some suitable cases, it is not just "OK" for polyfills to defer to native, but it is better if they do. Am I stating your view correctly?

[annevk]

I wouldn't really say better. It still might happen that due to this deployment users of user agents where the JavaScript runs end up with a broken site until the user agent ends up triggering the native code path, simply due to lack of continued testing in such user agents. But at least there's a way out.

[triblondon]

Can you provide an alternative that allows dependence on of a feature that does not enjoy universal support?

[annevk]

Hmm, you could not offer functionality in user agents that do not support it? Not sure where you want this to go.

[triblondon]

I want to use fetch. Am I supposed to make every fetch() call in my application fall back to XHR? Obviously, I'd abstract that. So I make a myFetch function. What does myFetch do? Well it obviously uses fetch if it exists, and if it doesn't, it uses XHR. I just wrote a polyfill.

Is that behaviour unreasonable? If so, what's the alternative, and how do you propose to stop developers doing it anyway?

Would you prefer that people just don't use fetch at all until it's in every single browser?

[annevk]

I don't think there's an easy answer to those questions. (Though trying to control what developers do does not seem like a good use of time.)

E.g., if you deploy myFetch and at some point the browser the developer team uses primarily supports fetch, they might start using the referrer feature to avoid leaking capability URLs. However, they end up forgetting that there's still one browser that doesn't support fetch, leaving the users of that browser in danger of getting their secrets compromised. If all you had was XMLHttpRequest you might end up designing around that instead, taking into account all users.

[mathiasbynens]

Detecting and using fetch as a private API as part of your myFetch abstraction is much less of a problem than const fetch = self.fetch || someFetchPolyfill (i.e. the classic polyfill pattern). The latter breaks (possibly in subtle, hard-to-notice ways) as soon as the polyfill differs from the native API. The only way the former could break is if fetch changes in such a way that it affects its usage within myFetch.

[domenic]

My suggested policy here is simply that there is a line (the "tipping point"), and when we cross it, deferring to native is the right thing to do. Can we agree that this is a reasonable principle and we just need to work on where to draw the line, or are you (@domenic, @annevk, @mathiasbynens et al) really arguing for the position of never deferring to native, ever? And if so how do you address the almost-but-not-quite-universal support scenario?

I am indeed arguing for never deferring to native, for reasons I've outlined. In the context of this document, that means strong warnings against deferring to native, outlining my reasons, not a prescription to never defer to native. Sometimes it seems like people haven't even read the OP.

I don't think the almost-but-not-quite-universal support scenario is interestingly different from half-support or no-support. All of my objections still apply.

Also strong +1 to the distinction @mathiasbynens is noting between myFetch and window.fetch =.

[triblondon]

This issue is about deferring to native, not aliasing to proposed names - can we stick to that? (Do open a separate issue if you like)

A lot of this sounds like "degrees of bad", and that is surprising to me especially since you are some of the leading lights in creating some of the web's features, and I would think want to see more and earlier adoption and feedback, not less. Here are some partial-support scenarios that came out of a conversation with @slightlyoff this morning:

• Universal support in current browsers already exists, but users are not using a current browser and so don't have that feature yet (eg the most popular browser for a major site I currently work on is overwhelmingly IE11, comprising around 41% of visits)
• Almost universal support but lacking in one browser that has given no public signals
• Many interoperable implementations exist and there is intent to ship from the remainder of implementors
• Stable implementation exists only in one browser, but with intent to ship from some others

So, I'm a developer, I want to use some new feature which is in one of the support states listed above. I can't simply not offer that feature in non-supporting clients, because it is designed as a replacement for an older technique (as is the case with fetch, for example, or promises), or is a low level feature like a String or Array method. What is the good solution? I see a lot of 'don't do this' in this thread but what would you suggest that people do do?

1. Avoid using the new feature until it has universal support. Use the old technique instead.
2. Avoid using the new feature until it has universal support. Use a shim with the same API but which ignores any native implementation so when universal support arrives (if ever) you can adopt it with minimal changes (though in many cases, you won't, because you're now working on something else)
3. Use a shim that defers to the native implementation if it exists

To progress this I think we need either to agree that there is some circumstance in which (3) is a sensible strategy (and then discuss what that circumstance is), or put on the table a hitherto undiscussed option (4) which would enable the adoption of features with non-universal support but without ever deferring to native.

Since (3) is how almost all polyfills work, isn't it worth understanding the motivations and incentives that led to that reality, and then either paving the cowpath or advocating a viable and attractive alternative? (which is....what?)

@domenic I can confirm I have read the OP. Many times. I am certainly trying hard not to waste anyone's time here, it is certainly as valuable as mine. Your view seems to have become more hardline in followup comments to the OP and that's what we are trying to bottom out here.

[domenic]

It's unclear whether you just haven't heard what I've said previously, but I'll try repeating it. (1)-(3) are not any of what I'm suggesting. I'm suggesting using the new feature as much as you want, but using the same implementation of it across all your target browsers---so the native one if your target browsers all support it, or the polyfill one if one of them does not. You call this "hitherto undiscussed" but then you claim to have read the OP, which discusses it, as do many other posts in this thread, so I don't really understand where you're coming from.

And again, you can violate this guideline that I'm suggesting---but you should do so, to quote the OP,

only in cases where it is known that the native implementation provides substantial advantages, and you are willing to accept the consequences of the site behaving differently depending on whether an older or newer browser is executing the code

This is as opposed to always violating the guideline for features over the "tipping point", which is what the current document recommends.

[triblondon]

[use] the new feature as much as you want, but [use] the same implementation of it across all your target browsers---so the native one if your target browsers all support it, or the polyfill one if one of them does not

I believe you are suggesting what I referred to as option 2. If one of my target browsers doesn't have the native feature, don't use it in any browser. Use an emulation if you want, and maybe swap it out later. Avoid any new native feature until it has "universal support", where we really should add "in browsers used by your target audience" (a useful clarification in this discussion). If there's a difference between this and what you're suggesting, can you point me at it?

It's really useful to characterise your position as 'always use the same implementation in all target browsers', subject to the 'in extremis'-type exception you provided in the OP. That seems to capture it succinctly.

I have heard/read everything said previously. Human communication is fallible, especially in text form, and sometimes the full intent is not understood immediately, even by someone who has the best intent. I'm happy to discuss and try to resolve that out of band if you like.

In any case, I think we now understand your concerns well enough to properly inform the discussion at next week's TAG F2F, so we'll leave it there for now, and this issue will be updated after the meeting (if not before).

[triblondon]

At the F2F in Boston, the TAG concluded that we endorse the position currently articulated in the finding. This is because:

• Whilst using polyfills that defer to native implementations can certainly cause sites to break when a browser ships the feature natively, this is in practice mostly a problem pre-tipping point. Post-tipping-point, the website developer will usually have native implementations against which to test their code. If the app’s code works with existing interoperable native implementations, it can be assumed with low risk that it will also work with future native implementations.
• Developers commonly do not revisit sites that have shipped. The need for browsers to support other vendors' prefixes came directly from the fact that developers did not update their sites when best practice and support levels changed. Any suggestion that shims will be removed seems over-optimistic.
• There is a significant risk that some target browsers will never support the feature, or that the lag between multiple interoperable implementations and full support may extend to a decade or more (especially when target devices include browsers embedded in TVs or other IOT devices)
• Some polyfills act by patching a bug in a native implementation. This can only work if polyfills can interact with native implementations.
• Native features have access to accessibility APIs that may not be available to polyfills. We should encourage switching to native as early as possible to improve and safeguard the accessibility of the web.

Thanks for raising the issue and I’m sorry that we’ve taken a contrary view on this one.

/cc TAG members present at the F2F: @torgo @slightlyoff @dbaron @travisleithead @hadleybeeman @triblondon @ylafon

[domenic]

I am prepared to accept that this document goes a different way (and thus, as I said in the OP, makes it a bad reference for web developers, which I am prepared to make people aware of). But the stated reasons don't make any sense to me:

Whilst using polyfills that defer to native implementations can certainly cause sites to break when a browser ships the feature natively, this is in practice mostly a problem pre-tipping point. Post-tipping-point, the website developer will usually have native implementations against which to test their code. If the app’s code works with existing interoperable native implementations, it can be assumed with low risk that it will also work with future native implementations.

This does not have any bearing on whether their code will work the same across old browsers and new ones, which is my concern. It's only talking about working the same between new versions and newer ones.

Developers commonly do not revisit sites that have shipped. The need for browsers to support other vendors' prefixes came directly from the fact that developers did not update their sites when best practice and support levels changed. Any suggestion that shims will be removed seems over-optimistic.

The need for browsers to support other vendors' prefixes is unrelated to the question of whether polyfills should delegate or not. Polyfills specifically should not delegate to native implementations (prefixed or not), so the question does not come up.

I don't know why you are talking about removing polyfills as that is not related to my point about whether or not polyfills should delegate to native implementations.

There is a significant risk that some target browsers will never support the feature, or that the lag between multiple interoperable implementations and full support may extend to a decade or more (especially when target devices include browsers embedded in TVs or other IOT devices)

This is true but argues for my point, not against it. If you keep using the polyfill then it does not matter when or if target browsers ever implement the feature.

Some polyfills act by patching a bug in a native implementation. This can only work if polyfills can interact with native implementations.

Interacting with native implementations is fine. Delegating to them is not.

Native features have access to accessibility APIs that may not be available to polyfills. We should encourage switching to native as early as possible to improve and safeguard the accessibility of the web.

Can you name a single such feature that people are polyfilling, for which it is impossible to polyfill the accessibility aspects? My experience is the opposite. For example, <dialog> polyfills often have better a11y than Chrome's <dialog> implementation.

[slightlyoff]

Just so we're clear: there isn't a single native implementation of a feature, there are as many implementations as the developer wishes to support. In that frame, the polyfill implementation is just one more -- possibly buggy, just like the native versions -- target for the developer to straddle. This is just life on the web where we balance multiple constraints. I'm not sure that arguing for more script when we're drowning in it already is a positive path forward. Obviously, these are both marginal arguments: at the margin, a polyfill can be so broken or different that you should do what @domenic suggests. Similarly, native impls can be so divergent that sticking with a polyfill effectively forever is a good idea. More often, native impls are good enough and developers aren't stressing the small differences such that all options are equivalent and dropping overhead is a net benefit.

I support this finding suggesting to developers that they should make this decision in a way that doesn't endanger the overall experience of the web for most users at the cost of (often small) additional potential behavioral divergence.

[bkardell]

@domenic I'm having trouble understanding your specific concern...

At some point, it's just a standard, right? To take something close to your heart, let's say Promises. All modern browsers support promises and they are a standard. If I am working on my blog and doing some async work, I'm totally using standard Promises, and I should, right? I mean, if not, what was the point? But.. because of various policies there are a number of users who may visit my blog with Safari 7 (me for example), or IE 11 - and there will be stuff like this for a long time. If I began a new blog today, are you suggesting that just writing for native and conditionally using a polyfill based on feature detection or something would be the wrong thing to do? I have a hard time imagining that, so I think I am misunderstanding. Or, maybe... are you suggesting that that choice should not be made by the polyfill but explicitly by an author in the sense that the polyfill itself should not attempt say 'if there is native, just use that', rather you just include or don't?

[domenic]

If I am working on my blog and doing some async work, I'm totally using standard Promises, and I should, right? I mean, if not, what was the point?

The point is to ship working, deterministic code to your users, not to use standards for the sake of using standards.

If I began a new blog today, are you suggesting that just writing for native and conditionally using a polyfill based on feature detection or something would be the wrong thing to do?

Yes, that is 100% what I am saying. If you are shipping the polyfill anyway, you should ship it to all browsers so that they behave the same, instead of the conditional delegation pattern.

[bkardell]

Yes, that is 100% what I am saying. If you are shipping the polyfill anyway, you should ship it to all browsers so that they behave the same, instead of the conditional delegation pattern.

But, in this case (the ones we are talking about), the non-promise-supporting browsers that I care about are a known finite set, they already happened, they are in the past. How, at that point, is this not just a matter of it being "one more implementation to test"? I mean, as we know, browser implementations (especially the early ones) are not infrequently wonky in some browser or other.

I'm really trying to understand.. Like, I get the basic sentiment, but it seems really unintuitive how this isn't taking that argument too broadly.

Would this approach just create a different, potentially worse problem? Like, one where you can't get anyone to use features at all until they are 'done' which is problematic without at least thousands of people banging on them. Consider if every website on earth was still shipping a promises polyfill to all browsers because, can you afford to screw over people like me who are on a perfectly good, fast mac running a slightly outdated OSX? One day, as people start removing the polyfill, we'll find the differences that you're worried about and then what? Is that better? Do we change the specs and all the native implementations to match the polyfill?

Does this not just risk the case of the most popular polyfill 'wagging the dog' after we have already gotten to agreement and implementation? That is, we need people to use stuff, but if the only way that anyone can actually reliably use it in practice is via polyfill that won't happen... As you say, you'll always use the polyfill.

[domenic]

This really feels like going in circles, so apologies if I don't take too much time to help you understand. I'll try to answer some of the more direct questions that seem to be a product of confusion...

Consider if every website on earth was still shipping a promises polyfill to all browsers because, can you afford to screw over people like me who are on a perfectly good, fast mac running a slightly outdated OSX?

What is "screwing over" those people? They're getting the great experience delivered by the polyfill.

One day, as people start removing the polyfill, we'll find the differences that you're worried about and then what? Is that better? Do we change the specs and all the native implementations to match the polyfill?

No, of course not. Why would we?

[bkardell]

I'm not trying to be obtuse, I'm sorry if you feel it's not worth your time. I really do want to understand your point. If another venue is preferable, you know how to reach me.

If you re-read that I am sure you will see the operative word "because". What you are saying, it seems to me, is that until literally everyone can use promises natively, effectively no one should - they should ship the polyfill to everyone. Not doing so would screw over someone like me.

What this means, it seems to me, is that there would be effectively 0 use of actual native promises until everyone had them implemented and deployed as nearly everywhere as anyone would care about (2020?).

No, of course not. Why would we?

If you read the scenario, it seems to create a situation where the polyfill is squatting and creating that problem instead. One where there are tons of existing uses of a feature that don't match the native before the native starts getting use.

[hax]

The layered apis which @domenic is working on includes a "standardized" polyfill mechanism as my understanding. So I guess domenic has changed his mind?