Page MenuHomePhabricator

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

Assigned To
None
Authored By
Nirmos
Oct 17 2017, 9:06 AM
Tokens
"Like" token, awarded by xSavitar."Like" token, awarded by Michael."Like" token, awarded by Ladsgroup."Like" token, awarded by SlickKilmister."Like" token, awarded by DannyS712."Like" token, awarded by Liuxinyu970226."Like" token, awarded by gabriel-wmde.

Description

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.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Krinkle changed the task status from Stalled to Open.May 13 2019, 8:24 PM
Krinkle moved this task from Blocked (old) to Backlog: Future Goals on the Performance-Team board.

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: Update JavaScript syntax checker for gadgets and user-scripts for ES6 first (which isn't marked as a blocker)? That feels like a really icky thing to lint for.

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.

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.

@VulpesVulpes825: For the records, T232563 mentioned 1% as a potential threshold but numbers were <0.2% when taking action. Similar number in T147199.

@VulpesVulpes825: For the records, T232563 mentioned 1% as a potential threshold but numbers were <0.2% when taking action. Similar number in T147199.

Let’s hope the recent announcement for Microsoft could speed up the sunset for IE 11 and Legacy Microsoft Edge, as not able to support ES6 and have to consider ES5 compatibility hinder development and performance of all kinds of stuff.

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

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)

In T178356#4467921, @Krinkle wrote in August 2018:

[…] few past decisions of similar nature:

  • 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

[…]

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. […]

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:

browserversion drop% of Oct-Nov 2020 pageview traffic to drop within desktop or mobile (of 22B page views)
Firefoxunchanged
Chromeunchanged-
SafariRequire Safari 10.1. Drop Safari 9<0.1% (Unknown)
Mobile SafariRequire iOS 10. Drop iOS 90.22% (~20 million page views)
IE 11Drop entirely, require Edge.2.7% (~250 million page views)
Androidunchanged- (possibly some percentage of stale Chrome versions)

Page views by country (Oct 1-30, from Turnilo: https://w.wiki/nAB):

browserTotal#1 country#2 country#3 country#4 country#5 countryremainder
Mobile Safari 923.4M pageviewsUSA 5.0MUK: 2.9MJapan: 1.9MGermany: 1.5MFrance: 1.3MOther countries: 10.8M
Safari 9
IE 11383.2M pageviewsIran: 123.8MJapan: 80.5MPakistan: 57.5MUSA: 23.8MGermany: 22.6MOther countries: 90M
Editing breakdown

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

Total965,000 edits in 30D [1]
Mobile Safari 9850 (0.08%)
Safari 9621 (0.06%)
IE 118,800 (0.9%)

[1] 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)

[…] Page view breakdown: IE 11 % of Oct-Nov 2020 pageview traffic to drop within desktop 2.7% (~250 million page views)

[…] Page views by country (Oct 1-30, from Turnilo: https://w.wiki/nAB). [… ] IE 11: Iran: 123.8M, Japan: 80.5M, Pakistan: 57.5M, USA: 23.8M

[…] 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 […] overall % for IE11 last quarter seems to be: 0.93%

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

When you open it up to top 1000 versions, possible in Superset, the overall % for IE11 last quarter seems to be: 0.93% (superset link)

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

In short:

  • 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.

If the RL can distinguish ES6+ codes and ES5 codes, I think we have another possible alternative: Not loading ES6+ codes only, on IE.

@Krinkle In response to a table chart on T178356#6632565, Microsoft said the support for Edge on Windows 7 will end on at least July 2021:

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:
As long as old browsers are considered so that the webpage doesn't break and has basic functionality, is it really necessary to spend so much effort in trying to give them ALL the same features? At this point, is it really any different from someone who disabled JavaScript in their browser? Everyone has the ability to get an up-to-date browser, they are really making their own bed and should carry the consequences themselves.

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.

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

If you check the "show obsolete platforms" checkbox on kangax's es6 tables, you'll see that it claims that Android 4.4 is 5% compliant, and Android 4.4.3 is 7% compliant.

Jdlrobson raised the priority of this task from Low to Needs Triage.Jan 22 2021, 12:38 AM

Priority seems incorrect so resetting.

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?

Why would they switch back? At that point, IE11-on-Win7 will have already been unsupported for two years. Internet Explorer, as a Windows component, follows the underlying OS’s lifecycle, so IE11’s support on Win7 ended on the Win7 EOL date.

Krinkle triaged this task as Medium priority.Jan 27 2021, 5:13 AM

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.

While I know traffic is not the only source of decision but currently IE is 0.9% of our traffic now: https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser

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.

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.

Not only do we know the heuristics, it’s already in core as of b267f7a (native Promise support, RegExp.prototype.flags support and Unicode support in variable names).

I left a comment on Talk:Compatibility about non-IE11 browsers and Vue 3 as well as access to WebAssembly.

Since IE11 support officially ends in November 2021 [1], might that be a good deadline for us to work toward?

I would hope we're not going to try to run JavaScript on a browser which is not getting security updates.

Also dropping this in here. The traffic should not be our only consideration here. We can still offer the sum of all knowledge without JavaScript.
https://css-tricks.com/a-business-case-for-dropping-internet-explorer/

[1] https://www.msn.com/en-us/entertainment/gaming/internet-explorer-support-officially-ends-this-november/ar-BB18a6Vz

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,

Since IE11 support officially ends in November 2021 [1]

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.

FYI: We get around 34484 errors every 12hr period. 8510 (24%), of those errors come from SamsungBrowser/7.2 Chrome/59.0.3071.125 due a well documented bug . 11291 of those errors come from ES5 browsers. Working on this task will remove 32% of all our JavaScript errors.

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.

8510 (24%), of those errors come from SamsungBrowser […] due a well documented bug . 11291 of those errors come from ES5 browsers. Working on this task will remove 32% of all our JavaScript errors.

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?

Lastly, I think it's important to acknowledge that these third-party client errors generally don't and can't affect the user experience that our code provides. Samsung could have shipped mw.track('error.uncaught', new Error('hello')); and it would be similar in impact, right? Both the browser and our own platform generally ensure robust JavaScript execution such that it is protected from uncaught errors in other call stacks.

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

Right.. which means from a product perspective we can't even guarantee that our IE11 users are having a good experience with JavaScript, so browser share should not be the only consideration here for making this decision.