|Open||Catrope||T272104 Allow modules to opt-in to ES6 syntax support|
|Open||None||T272882 Upgrade ResourceLoader's JS Minifier to support ES6|
- Mentioned In
- T248761: [modern Vector only] Move indicators underneath firstHeading
T272104: Allow modules to opt-in to ES6 syntax support
T269273: Support ECMAScript 2015+ on ResourceLoader
T262946: Bump Firefox version in basic support to 3.6 or newer
T134068: Bump browser compatibility for Safari 5 and 6 from Modern to Basic.
T237688: Raise MW JS requirement to include ES6 Promise (drop IE11, Safari 5-6, and Android 4.1-4.3)
T211168: Prevent memory leaks from the nextState() function
T188937: Replace jQuery.Deferred.done/fail/always()
- Mentioned Here
- T266866: Bump basic supported browsers (grade C) to require TLS 1.2 for MediaWiki core and Wikimedia infrastructure alike
T147199: Removing support for DES-CBC3-SHA TLS cipher (drops IE8-on-XP support)
T232563: Drop IE6 and IE7 basic compatibility and security support
T237688: Raise MW JS requirement to include ES6 Promise (drop IE11, Safari 5-6, and Android 4.1-4.3)
T102318: Convert startup blacklist to feature test
T121517: Drop support for Opera 12 at some point
T141344: Remove JSON polyfill
T187869: Drop Grade A support for IE10
T136203: Drop Grade C support for IE8
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 that the new built-ins weren't all implemented at the same time. We're technically still waiting for the first browser to fully implement it. Kangax's tables indicate we're getting close, though:
- Current Firefox and Chrome implement 97% of the ES6 spec,
- Current Edge implements 93% of ES6,
- Safari 9 implemented 53%, but Safari 10+ shows 99% of ES6 spec implemented,
- IE 11 implemented ~11% of the ES6 spec.
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.
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.
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 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.
I am curious about the current status of this task. Currently, the overall IE traffic is around 1.3%, and desktop IE traffic is around 3.7% (based on analytics). Maybe it is a good time to consider starting to drop IE 11, so we can move on to ES6 considering how low the traffic right now.
Chromium-based Edge still does support Windows 7 and Windows 8 right now, and anyone who still using IE 11 should start the switch now (either voluntarily, or forced as Microsoft has pulled the plug)
Meanwhile… two years later. Let's take another look.
ES6 spec compliance
Completion of browsers implementing the ES6 specification ("ES2015"), per Kangax's tables:
- browser name (oldest-latest version with the same completion percentage)
- Firefox 68-82: 98% spec compliant
- Edge 17-18 (EdgeHTML): 96% spec compliant
- Edge 79-84 (Chromium): 98% spec compliant
- Opera 63-70: 98% spec compliant
- Chrome 77-85: 98% spec compliant
- Mobile Safari iOS 11-13: 98-99% spec compliant
- Safari 12-14: 99-100% spec compliant
- IE 11: 11% spec compliant
And some additional numbers from opening that page in older browsers via BrowserStack:
- Safari 9: 53% spec compliant
- Safari 10.1: 98% spec compliant
- Mobile Safari iOS 9: 53% spec compliant
- Mobile Safari iOS 10.0: 98% spec compliant
- Android 4.4 (evergreen, Chrome 80): 98% spec compliant
- Android 4.3 ("Browser" like Chrome 68): 98% spec compliant
And from my Nokia 8110 4G:
- KaiOS 2 ("Browser" is Firefox 48-ish): 91% spec compliant
See also The ES6 Conundrum by Christian Heilmann about talks about some of these differences and the challenge in dealing with them. Also note that Chromium-based browsers don't always have feature parity. V8 and Blink features are often behind feature flags that Microsoft, Opera, and Google may set differently in their distributions. But.. by now they are in sync at least for ES6/V8 features. I suppose we can accept 96% of the spec actually commonly implemented as the subset we'll guruantee. Configuring linters for this might be challenging though, that's certainly something to keep in mind. It's also likely that any parts still missing are intentionally omitted and may end up removed from the spec in future editions.
Page view breakdown
If we take T266866 for granted, then we'd be talking about discontinuing Grade A support for the following:
|browser||version drop||% of Oct-Nov 2020 pageview traffic to drop within desktop or mobile (of 22B page views)|
|Safari||Require Safari 10.1. Drop Safari 9||<0.1% (Unknown)|
|Mobile Safari||Require iOS 10. Drop iOS 9||0.22% (~20 million page views)|
|IE 11||Drop entirely, require Edge.||2.7% (~250 million page views)|
|Android||unchanged||- (possibly some percentage of stale Chrome versions)|
Page views by country (Oct 1-30, from Turnilo: https://w.wiki/nAB):
|browser||Total||#1 country||#2 country||#3 country||#4 country||#5 country||remainder|
|Mobile Safari 9||23.4M pageviews||USA 5.0M||UK: 2.9M||Japan: 1.9M||Germany: 1.5M||France: 1.3M||Other countries: 10.8M|
|IE 11||383.2M pageviews||Iran: 123.8M||Japan: 80.5M||Pakistan: 57.5M||USA: 23.8M||Germany: 22.6M||Other countries: 90M|
Given this is about Modern (Grade A) and not Basic access (Grade C), its worth looking at things that are unique to Grade A, such as search suggestions and edits.
Querying Turnilo for event_editattemptstep (https://w.wiki/nA5):
|Total||965,000 edits in 30D |
|Mobile Safari 9||850 (0.08%)|
|Safari 9||621 (0.06%)|
|IE 11||8,800 (0.9%)|
 This accounts only for edits that involve event instrumentation. This covers all first-party editors, including when JS is not supported (counted on the PHP side). Edits through the API, though, are not accounted for by this instrumentation. This means JS-assisted edits from gadgets such as HotCat are not covered. And non-browser edits from bots using the API are also not counted here. Based on Grafana: Save Timing there are about 42M/months edits in total, of which 8M/month through index.php (https://w.wiki/nAF). So... clearly quite a lot not accounted for it seems.
@Krinkle quick note, re: above. When you filter out bots and spiders, using the "agent" dimension and filter it to users, the IE11 percentages are actually significantly lower. Which is good! https://w.wiki/oqf. When you open it up to top 1000 versions, possible in Superset, the overall % for IE11 last quarter seems to be: .93% (superset link)
I see. The per-country data above came from Turnilo, where I forgot the agent type indeed. Note that the rest of the figures did not come from Turnilo. Specifically, the 2.7% figure is from analytics.wm.o, which I re-confirmed last month with Analytics does filter out bots and spiders, using only "user" agent type data. Note that I am using the desktop site breakdown. For IE11, that subtotal does not including mobile web, mobile apps, or other/virtual views. The same dashboard for "All sites" reports IE11 usage as 1.1% for Oct-Nov.
Querying Turnilo for the same Oct-Nov range, with "user" agent type, over all desktop+mobile+app methods, reports IE usage as 1.25%, and IE11 as 1.05% (84% of 1.25%, https://w.wiki/oqp, https://w.wiki/oq$) which seems close enough to the 1.1% figure on analytics.wm.o. (I assume we can get it to match exactly if we use the same start-end days, I could not find what these are on analytics.wm.o).
This link yields an error for me: index -1 is out of bounds for axis 0 with size 0. I haven't used Superset for this information before and couldn't get it to work. Assuming last quarter is July-Sept, Turnilo data for "user" agent type over period reports IE as 1.38% and IE11 as 1.25% (https://w.wiki/oqy).
- IE 11 is used by people for about 200M page views a month, representing 2.7% of desktop web, or 1.1% of mobile+desktop+app (https://w.wiki/or5, https://w.wiki/or6).
- If dropped from the Modern JS (Grade A) today, it would be the largest drop of its kind in our history.
- The Vue.js Taskforce recommended we begin "now" with phasing it out for new investments and developments. Underlying tooling, and JS delivery mechanisms, and existing features would still support it. Then sometime next year, we would consider raising the Grade A universal capability-test to ES6 (which IE11 does not support), and then remove any remaining support layers from our code bases.
@Krinkle Thanks for clarifying. The platform breakout explains the discrepancy we had. Sorry the superset link didn't work--it works for me, so might be an auth issue with Superset.
On my end, IIE11 matters, but I'm also trying to take into account the cumulative total of unsupported browsers, which is where those earlier conversations come into play. This isn't just about slices of a pie, of course. Its about recognizing that folks on these more limited browsers arguably also have limited access to knowledge. For this reason, we had an entire team work on an app for an OS that contributes 5.5M PVs a month. I am leaning towards further advocating the recommendation of the task force, but want to make sure I understand the implication.
We will continue to support Microsoft Edge on Windows 7 and Windows Server 2008 R2 until July 15, 2021. These operating systems are out of support and Microsoft recommends you move to a supported operating system such as Windows 10.
Previously, Google planned to end support for Windows 7 on that same period. Thankfully, it's been extended to January 2022.
I think Win 7 users don't have incentives to switch from IE11 to Edge. Chromium engine runs on both Chrome and Edge. I think most Win 7 have already been accustomed to Chrome. If Microsoft won't extend support for Edge on Win 7 further than Google's plan, then Win 7 users would find switching from IE11 to Edge pointless.
When Google's support for Chrome on Win 7 ends, and users shall stick with Win 7 by 2022, shall the Win 7 users switch back from Chrome to IE11, or shall they continue to use Chrome despite Google's (extended) plan? (EDIT: Struck per @Tacsipacsi )
//relevant portion of my comment on T75714:
More productive use of our time, I think, however would be spent on the future of the web and not its past, such as using ES6 natively and raising our browser support accordingly.
This is not only something that would benefit the project itself, but It would open up the doors for hords of enthusiastic and skilled JS/ES devs who might be interested in contributing to this cause, but are effectively unable to do so because of the archaic conditions. I would love to do work related to scripts and gadgets, but the effort required is insane for me. I recently made a simple script to hide a few boxes that were bothering me; what would usually take me around 5 minutes to do ended up taking over 1 hour.... I started out working with JS/ES a bit over 2 years ago, and have been using TypeScript exclusively for about 1 year. I have zero experience with working in a world without Intellisense and easy to use automation. And looking at the popularity of JS/ES and TypeScript in OSS, I can't be the only one who was discouraged by this to contribute to the project.
It should also be noted how ES6+ syntax tends to have a tiny bit better performance (most notably in the V8 engine), and how it can considerably reduce effort needed for code maintenance and debugging with the TypeScript Language Service and all the tools that rely on it.