Note that a Promise polyfill can be loaded at the cost of a few kb of compat code, but there's so many other reasons to want to deprecate IE 11 and to move to newer JS versions and most of the other things can't be polyfilled so easily.

Comparing our current Grade A to basic support for an early Promise spec:

• IE11.
• Safari 5 – Safari 7.x.
• iOS 6 – iOS 7.
• Android 4.1 – Android 4.3.
• Opera 15 – Opera 18. (This one we can probably ignore, should probably be changed to "current - 1 only" to match Chromium).

As first step toward this we can probably ship an es6-promise module of some kind with a simple skipFunction, like we did for previous shims before we required them. This means we don't pay any significant cost for adoption. Only a few bytes of metadata in the startup module, which would be similar to the cost of shipping an additional feature-test.

This allows exploring use cases right away, find out if there are bugs in native versions that might make us expand our feature test for more specific features of Promise if an early version might not be good enough for our needs, and then after a stats collection of support we can raise Grade A. For previous runs of this, see T102318, T128115, T141344 etc.

Note that Promise was specified as part of ES6. And we have a nearly identical task for that already at T178356: Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015).

In T237688#5645973, @Krinkle wrote:

Note that Promise was specified as part of ES6. And we have a nearly identical task for that already at T178356: Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015).

I consider T178356 to be properly blocked by T75714 (i.e. I don't expect it done before 2030 at current rates of movement).

Yeah, we planned it the same way for ES5 for a while. However in the end we split them, and I think that was a good call to make. Using es5-shim allowed us to early-adopt methods like Array#map and Array#forEach. After requiring it universally it meant we no longer had to register the polyfil, and could start making use of features that couldn't be polyfilled or were expensive to emulate, such as Object.create(null) and more complex incantations of Object.defineProperty.

We were also able to instantly make use of ES5 syntax in our software given that for that we only need to satisfy ESLint. The aforementioned JSParser only applies to validation of user scripts and gadgets, where today both shimmable and shammed ES5 methods can be used today, but not (all) of the syntax even today.

For ES6 we can follow the same path and it doesn't really change the story for user scripts in that they are still validated syntax-wise by an ES3 parser, but it doesn't affect eslint configuration or our software in general.

Change 549650 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] [WIP] Provide ES6-style Promises if not provided by the client

https://gerrit.wikimedia.org/r/549650

Are we already bikeshedding over which polyfill to use? If so, https://github.com/taylorhakes/promise-polyfill is much smaller than https://github.com/stefanpenner/es6-promise.

In T237688#5647080, @Schnark wrote:

Are we already bikeshedding over which polyfill to use? If so, https://github.com/taylorhakes/promise-polyfill is much smaller than https://github.com/stefanpenner/es6-promise.

WFM.

In T237688#5647080, @Schnark wrote:

Are we already bikeshedding over which polyfill to use? If so, https://github.com/taylorhakes/promise-polyfill is much smaller than https://github.com/stefanpenner/es6-promise.

The size difference is quite significant. Do we know why the other one is so much larger? Is it missing something?

In T237688#5648031, @Krinkle wrote:

In T237688#5647080, @Schnark wrote:

Are we already bikeshedding over which polyfill to use? If so, https://github.com/taylorhakes/promise-polyfill is much smaller than https://github.com/stefanpenner/es6-promise.

The size difference is quite significant. Do we know why the other one is so much larger? Is it missing something?

stefanpenner/es6-promise tries hard to find the best method of scheduling an async task, while taylorhakes/promise-polyfill just uses either setImmediate or setTimeout, but I doubt that this has such a significant impact on the size.
BTW, a much longer (but slightly dated) list of alternative implementations is at https://github.com/promises-aplus/promises-spec/blob/master/implementations.md#standalone.

IE11 is still some 3% of total views (7.6% of desktop) and is presently the only MS browser available on Win7 (mind you, an OS basically EOL in a month) and Win8. (Chromium Edge supports both but will be released more-or-less with the end of support for Win7; how it will end up on users's computers for Win7 when they won't be receiving updates, I do not know (voluntary download? for people using IE11...).)

Not sure if that should factor into the discussion (or how much it should - maybe it leads to a polyfill only for IE11). The other browsers listed to be dropped to basic seem to be in the sub-1% group, and some much less.

(Aside: I left a comment on the Compatibility talk page 2 years ago about how there doesn't seem to be a standard process or what objective criteria should be used to establish new minimum requirements. Does ad hoc / business case-driven work?)

Change 584021 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] [DNM] resourceloader: Require native Promise support in clients

https://gerrit.wikimedia.org/r/584021

Change 584031 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] resources: Provide an ES6-style Promises library with a skip function

https://gerrit.wikimedia.org/r/584031

Change 584031 merged by jenkins-bot:
[mediawiki/core@master] resources: Provide an ES6-style Promises library with a skip function

https://gerrit.wikimedia.org/r/584031

No need to support IE11, because the traffic is relatively small

In T237688#5738492, @Izno wrote:

IE11 is still some 3% of total views (7.6% of desktop) and is presently the only MS browser available on Win7 (mind you, an OS basically EOL in a month) and Win8. (Chromium Edge supports both but will be released more-or-less with the end of support for Win7; how it will end up on users's computers for Win7 when they won't be receiving updates, I do not know (voluntary download? for people using IE11...).)

Not sure if that should factor into the discussion (or how much it should - maybe it leads to a polyfill only for IE11). The other browsers listed to be dropped to basic seem to be in the sub-1% group, and some much less.

(Aside: I left a comment on the Compatibility talk page 2 years ago about how there doesn't seem to be a standard process or what objective criteria should be used to establish new minimum requirements. Does ad hoc / business case-driven work?)

• In fact, the Edge browser can still be used on Windows 7.

Suggesting to close this in favour of:

• T266866: Require TLS 1.2 (drop Safari 5-8, Android 4.x, Opera 15-18)
• T178356: Require ES6 (drop IE11, Safari 9)

Note that es6-promise can already be used with the polyfil that ships with MediaWiki core (RL loads the polyfill as-needed for older browsers).

We could merge this into T178356 I suppose; it was intentionally crafted to be a sub-set of that one, but if we're deciding never to ship RL with the requirement but without the polyfill until that one is done… Technically we should sub-stack and Decline, really.

This isn't actually a duplicate of the target…

Change 584021 abandoned by Krinkle:

[mediawiki/core@master] [DNM] resourceloader: Require native Promise support in clients

Reason:

Superseded by T178356

https://gerrit.wikimedia.org/r/584021

Change 549650 abandoned by Jforrester:

[mediawiki/core@master] [DNM] resourceloader: Ship the ES6 polyfills by default

Reason:

We raised requirements to ES6 instead.

https://gerrit.wikimedia.org/r/549650