Page MenuHomePhabricator

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

Assigned To
Authored By
Oct 17 2017, 9:06 AM
Referenced Files
"Like" token, awarded by Jayprakash12345."Like" token, awarded by Sunpriat2."Like" token, awarded by MusikAnimal."Like" token, awarded by Volker_E."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.



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

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

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.


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

Page views

Update just before the Design System Team Vue.js Developer Summit and its question on shared components library support for IE11 T286947:
IE11 is used by people for about 302M page views in 01 May-01 Aug, representing 0.66% of mobile+desktop+app in total of 45.3B ( Taken 3 months into calculation as access stats tend to differ in Northern hemisphere Summer.

When the time comes to hard-require ES6 in the startup module, we can also evaluate whether some of the forced downgrades to Basic are still needed.

The following are non-proxy/non-remote browsers that are excluded mainly due to bugs or missing APIs:

Change 723331 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] resourceloader: Document reasons for forced downgrades to Basic

Change 723331 merged by jenkins-bot:

[mediawiki/core@master] resourceloader: Document reasons for forced downgrades to Basic