|Resolved||Catrope||T272104 Allow modules to opt-in to ES6 syntax support|
|Resolved||Catrope||T272882 Upgrade ResourceLoader JS minifier to support ES6|
|Resolved||Catrope||T277085 Add support for ES6 client code to eslint-config-wikimedia|
- Mentioned In
- T283726: Align ResourceLoader's 'startup.js' feature check with updated modern browser list
T229239: Refresh target browser support for MW, dropping less-used browsers from Grade A to Grade C
T273592: Migrate WMDE vuejs projects to vue3
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
- rMWb267f7aa9075: resourceloader: Allow modules to mark themselves as ES6-only
T266866: Remove "Basic" support (Grade C) for browsers without TLS 1.2+ (MediaWiki core and WMF infra)
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
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.
As a note about IE, I would be careful about making decisions based on traffic from the past year. When I was looking at the data for IE recently, I saw a cycle that looked like it was based on whether school was in.
And school has very much not been in this year.
Technical question: Do we know what our heuristic for browser support will look like when we drop IE11 (e.g. is it a feature detection test)?. I ask because we are logging a lot of JS errors from older versions of Firefox and I am wondering whether the heuristic will (or could) exclude these.
Since IE11 support officially ends in November 2021 , might that be a good deadline for us to work toward?
Note this news means some Microsoft online services will drop IE11 support (like what we will do in the future); the browser will still exist and continue to maintained until (if I remember correctly) support of Server 2019 ends in 2029.
As far as I recall, Microsoft states that they will support IE as long as they support the underlying operating system, for example Windows 10. They also state that they will support Windows 10 forever (or, to be a bit more realistic, for an unspecified amount of time). This means that we can count on IE remaining officially supported longer than we want it to, and we’ll need to stop supporting it before its official support ends.
By the way,
This article was written in August 2020, so “this November” means November 2020, not 2021 (and if you read the Microsoft Tech Community article, it’s clear that this date refers to the Teams support, not overall support).
Thanks all. I misread the security updates. I think the article I read was a little misinformed. Please discount my comment about security updates.
Microsoft 365 apps and services will no longer support IE 11 starting August 17, 2021.
I couldn't see any errors for IE11 in our error logs, which is incredibly unlikely, which makes me think our error logging doesn't even work there, meaning the number of errors could be even higher for these older browsers.
But would it solve user-facing problems, or help us identifying other problems? Past experience would suggest not. These are at a comfortably low frequency in our logs that we can and should ignore. Why is it significant that a browser or specific issue represents some portion of the background noise during standby days? Nothing is happening right now. It could be 100% and still not matter, right?
Speaking of percentages, where are we on forming an SLO for client errors? I'm aware an alert was enabled at an arbitrary threshold at an absolute number we happen to be near, but that's not an SLO. We need something more scalable, with buy in from stakeholders, as a proportion of what is not failing (eg. page loads, browsing sessions). Taking the above 11291 ES5-browser events and comparing it to page views by "users" from mobile+desktop web on en.wikipedia.org (and generously counting all edits, non-pageview actions, and other instrumented wikis as if they were errors), these would be <0.009% or <1:11,000 page loads (based on (11291/(7634510656/31/2))*100 or 7634510656/31/2/11291).
Do we think issues like the Samsung one are more likely to happen on older browsers? Perhaps the most popular browsers would not ship these, or quickly fix them. But at our scale I don't think we can avoid some set of clients adding noise. We could say the same about Belgium, or Opera clients, and say cutting them off will reduce X% of noise. What is the value proposition?
Sorry to derail with the Samsung comment. The main thing I wanted to raise was from a product perspective regardless of browser share errors are likely happening on these clients and we should consider user experience as well as browser share. Especially given IE11 doesn't seem to have error logging of any form.
IE11 doesn't implement Beacon API. The new event platform required this from the start, and is a no-op on clients without it. This helped improve the EL client to be more stable and flexible (e.g. finally allowing click instrumentation since non-beacon requests would either be have to be blocking, or immediately aborted).