Page MenuHomePhabricator

Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015)
Open, LowPublic


Following T128115 which was resolved in April 2017, the next logical step would be to drop support for ES5 when the proportion of browsers in use that don't support ES6+ is low enough.

Event Timeline

Nirmos created this task.Oct 17 2017, 9:06 AM

I'm not sure on what condition a task should be stalled, so I'll happily let you and others decide that. I do note, though, that T136203 which I also created, isn't stalled. If this task should be stalled, maybe that task should also be stalled. They are quite similar.

Restricted Application added a project: Performance-Team. · View Herald TranscriptFeb 9 2018, 12:11 PM
Imarlier moved this task from Inbox to Radar on the Performance-Team board.Feb 12 2018, 9:21 PM
Imarlier edited projects, added Performance-Team (Radar); removed Performance-Team.
Krinkle renamed this task from Drop support for ES5 to Raise Grade A JavaScript requirement from ES5 to ES6.Jun 23 2018, 11:21 PM

@Nirmos @Krinkle Can the task description be expanded to include the conditions under which this can proceed (assuming that it cannot proceed at the moment)?

Krinkle added a comment.EditedAug 1 2018, 5:02 AM

The main condition is percentage of browser support. Exactly what percentage to wait for hasn't been decided, but here's a few past decisions of similar nature:

  • September 2014: Dropped support for IE7, ~1% – Wikitech, 116d1828. (mainly motivated by EOL and lack of TLS; Opera 12 with the same usage level at the time was specifically not dropped)
  • November 2015: Dropped support for IE8, ~0.55% pageview traffic. – T118303
  • November 2016: Dropped support for JSON polyfill, <0.1% pageview traffic (mainly Safari 4.x). – T141344#2818497
  • April 2017: Dropped support for ES3, ~0.59% pageview traffic (mainly IE9, Android 2). – T128115#3066522
    • For this change, we aimed at ~99.5% adoption before switching. We explicitly didn't switch at 98%.
  • November 2017: Dropped support for Opera 12, <0.1% pageview traffic (below threshold for public analytics, post-2015). – T121517
  • February 2018: Dropped support for IE10, 0.07% pageview traffic. – T187869

In April 2016, we also did a two-month analytics campaign to know the remaining percentage of page views from Grade A clients – T102318:

  • 95.43% of pageview traffic supported Grade A feature test (86.27% browsers we officially support, 9.16% unofficially works, aka "Grade X"; tends to be beta versions of browsers and browsers derived from supported ones, such as UC Browser and Yandex).
  • 4.58% of pageview traffic degraded as Grade C (mostly Opera Mini, and older versions of IE/Safari/Android).

Support for ES2015 (ES6) is not as easy to measure (yet) given the many new built-ins weren't implemented a the same time. We're technically still waiting for the first browser to fully implement it. Though, Kangax's tables indicate we're getting close:

  • Current Firefox and Chrome implement 97 to 98% of the spec,
  • Edge about 93 to 96%,
  • Safari 9 implemented 53%, but Safari 10+ shows 99% of the spec being implemented,
  • IE 11 implemented 11% only.

At this point, we should probably wait for IE11 traffic to drop more (last week: 7%), and for the remaining browsers to finish their implementation, and then for the now-current versions of non-evergreen browsers (Safari and Edge) to drop off a bit more.

When we get further along in this, we should remember that among contributors (compared to readers) browser usage biases more towards older browsers. One could argue that Grade A features are more important to editors than to readers (Grade C reading's pretty good, Grade C editing – not so much). See also T128115#3066697.

Krinkle renamed this task from Raise Grade A JavaScript requirement from ES5 to ES6 to Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015).Aug 1 2018, 5:02 AM
Legoktm changed the task status from Open to Stalled.Aug 1 2018, 5:05 AM
Krinkle changed the task status from Stalled to Open.May 13 2019, 8:24 PM

Haven't checked recently, but we might be getting close to dropping Grade A support for non-ES6 browsers. I don't think we're there yet, but we're close enough that this is worth keeping in mind during the 2020-2012 planning process (starting 1 year from now). So putting in that column for us to see at that time.

This would be "ES6 functions but not syntax", presumably, unless we fix T75714: ResourceLoader JavaScript parser should allow ES6 syntax features first (which isn't marked as a blocker)? That feels like a really icky thing to lint for.

TheDJ added a subscriber: TheDJ.Oct 24 2019, 2:29 PM
brion added a subscriber: brion.Nov 7 2019, 9:22 PM
Izno added a subscriber: Izno.Dec 13 2019, 6:25 AM

I left this comment on the Promises task; not sure if it might be better suited for here.

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

Note that T75714 is only about validation for user scripts. For the MediaWiki code we use ESLint.

ESLint has had separation between parsing and global whitelisting since very early on. We just haven't used it yet.

In terms of strict linting this would remain on ES5. Parsing and tokenising JavaScript code is not influenced by whether classes or methods exist.

In terms of whitelisted globals, we would continue to use the jquery and browser presets and add to this list the es6 preset. This effectively just whitelists Map, Set and Promise the same way /* global Map, Set, Promise */ would. We could have used something like this during our ES3-to-ES5 transition as well, where we used es5-shim. Except, we didn't have to then because ES5 didn't introduce new globals.

Alternatively, we might want to keep our repo-wide eslint configs strictly ES5 and not whitelist es6-shim globals there. Instead, the occasional nudge about them being undefined can be a useful reminder to add es6-shim to your dependencies, and then explicitly add /* global Promise */ to the top of any code needing it. This matches how we use them today. Eg. for moment, EasyDeflate and Uint8Array. I think that might be easier to reason about and perhaps less confusing as there would be no mention of "es6" in the ESLint config that way.