Repository navigation
Description
Description
We've touch the topic a few time but I thought it'd be good to have any decision we make publicly available on GitHub.
Our browser support policy states we support "(Current - 1) and Current" versions of Edge. Right now it's Edge with EdgeHTML 17 & 18[1] but the new Chromium-based Edge version (v79[2]) is slated for a public release on January 15, 2020. Version 80 should follow a few weeks afterwards as they'd be following the Chromium release calendar. Technically speaking, that means jQuery will officially no longer support the legacy EdgeHTML-based Edge versions (as the two latest versions will be 79 & 80, both Chromium-based). However, I feel an engine switch is a big enough event that we should make any decisions about dropping support - even if technically we don't have to - more consciously. Therefore, I wanted to explain how I see the Edge situation after January 15, 2020.
The public release of the new Edge will probably not mean auto-updating everyone on Windows 10 to it but I expect the next Windows 10 "feature update" (which should be released around April/May 2020) will include it.
Microsoft still supports EdgeHTML 16, 17 & 18 on Enterprise & Education versions of Windows 10 so those OS lines may take a bit more to update (installing the Chromium-based Edge is supported in all of them, though). Microsoft will also still support EdgeHTML-based WebView in addition to the new Chromium-based one; there's no timeline to remove the old WebView. Some platforms, like Windows 10 on ARM or Xbox will not get the new Edge at the same time as most desktop Windows versions will.
Dropping EdgeHTML supports would bring us some advantages: it'd decrease the minified gzipped jQuery size by 230 bytes as of now and it'd allow us to restrict some workarounds needed by IE & Edge to just IE by a documentMode check. That fits nicely with other legacy workarounds removals in 4.0, making jQuery faster especially for modern browsers.
I'd keep testing jQuery 3.x with at least EdgeHTML 18 even though technically it will fall out of our supported browsers list soon.
[1]: For support purposes we use EdgeHTML versions rather than Edge app versions which are now at v44
[2]: Chromium-based Edge aligns its major version with Chromium, getting rid of current two separate versioning strategies for the app & its web engine
Link to test case
N/A
Activity
mgol commentedon Dec 16, 2019
I created a draft PR so that it's easier to see what kind of changes we could introduce if we dropped EdgeHTML: #4573.
Selector: Drop support for EdgeHTML (i.e. non-Chromium Microsoft Edge)
mgol commentedon Dec 30, 2019
@kytosai This issue is not about removing support for Edge (which we have no plans to do) but for EdgeHTML, i.e. the engine powering the legacy Edge versions that will be replaced by Chromium on January 15, 2020.
IE 11 support cannot be removed yet as:
Maybe we'll be able to drop IE support in a few years, if jQuery still exists by then. But that's too far a future to seriously consider it at the moment.
mgol commentedon Dec 31, 2019
Paging people who might be interested in voicing their opinion here: @jquery/core @Krinkle @arschmitz @fnagel
Krinkle commentedon Dec 31, 2019
This may be of interest as well: analytics.wikimedia.org/dashboards/browsers
Illustrated: Desktop traffic to Wikipedia and sister projects, by browser family and major version. From 15-22 Dec 2019. IE 11 makes up 8.1% globally, Edge 18 makes up 4.1% globally.
In context: stats.wikimedia.org says the desktop sites receive around 10B page views a month. The English Wikipedia specifically, receives 5B of those 10B desktop page views, from an estimated 260M desktop-device sessions.
Krinkle commentedon Dec 31, 2019
@mgol For Wikipedia, dropping legacy Edge for client-side enhancements (Grade A) would likely be fine if our traffic shows it being <1% of desktop globally.
We generally support individual browsers if they are used by at least 1% of readers globally. And our current Grade A matrix is generally a superset of these >=1% browsers (additional browsers added or removed based on consensus and available resources).
fnagel commentedon Jan 2, 2020
I never really tested my projects with Edge and no client ever asked for it but ~4% (almost 5 in some stats) worldwide usage is enough for me to say: let's keep it in the 4.0 release.
How much speed to we gain by removing?
What else do we plan to remove in the 4.0 release?
+1
mgol commentedon Jan 2, 2020
@fnagel
~4% is the current statistic. I suspect it will go down a lot once the Chromium-based Edge is released on January 15 as Microsoft is aiming at a pretty aggressive update schedule, even updating older Edge versions on older Windows 10 feature updates. And jQuery 4.0.0 will not get released soon, I think 6 months into the future is an optimistic estimate.
If we want to know for sure how the update goes, we can wait a month or two and see if usage of EdgeHTML-based versions of Edge drops significantly during that time or not.
I described that in my original post. Do you have an additional question to what I wrote there?
Nothing that we haven't removed already (though we can always decide to restrict that further if we think it makes sense). See #4299 & #3950. Also, I submitted a draft PR to update the jQuery browser support page at jquery/jquery.com#194 so you can have a look at our current plans.
fnagel commentedon Jan 2, 2020
Thanks for your fast reply!
You're right. Those numbers will most likely drop the next few month but how much? MS pushes those updates more aggressively but as their ecosystem does not adapt, lots of people and companies block updates (at least those feature updates).
Anyway, waiting a little longer to have better figures as base for a decision sounds like a good plan!
I only found this sentence regarding speed gains "That fits nicely with other legacy workarounds removals in 4.0, making jQuery faster especially for modern browsers.".
Thanks. Looking at those IE usage numbers (e.g. global IE 10 usage at 0.15% and IE 9 at 0.36%) I feel confirmed saying that Edge 18 should be supported a little longer (conditional how the usage numbers will change the next few month).
Selector: Drop support for EdgeHTML (i.e. non-Chromium Microsoft Edge)
mgol commentedon Jan 2, 2020
Have a look at my draft PR removing EdgeHTML support: #4573. Some improvements:
support.and also at the test insrc/selector/rbuggyQSA.js- these are support tests that we have to run right now as the bug exists in EdgeHTML as well; if we dropp it, we can just use theisIEcheck, saving on a support test run which slightly improves performance, especially the first time a particular API runs (it also improves final jQuery size).src/selector.jswe had to apply anunloadhandler for IE & Edge but a support test was impossible so we did it for all browsers; if we drop EdgeHTML, we can check forisIEand only attach the handler in IE.These are not extreme performance gains but it fits into our significant performance improvements in the selector module for jQuery 4.0 that were possible mainly by dropping lots of workarounds & support tests for legacy browsers.
mgol commentedon Jan 2, 2020
Also, note that some of the support tests removed in that PR are quite new; as people encounter more issues in IE that still exist in EdgeHTML, there's a potential of having more & more of them in the code.
arschmitz commentedon Jan 2, 2020
I personally would say its not possible to decide this right this second the current usage is much to high to drop and while i hope with the January and subsequent releases of edge that it will drop low enough that its fine to drop. No one can really say that right now.
13 remaining items
Core: Drop support for EdgeHTML (i.e. non-Chromium Microsoft Edge)
mgol commentedon Sep 21, 2020
I'd like to reopen the discussion. I analyzed recent market share data and here are my conclusions:
Based on the above data & the fact that any support for Edge Legacy from Microsoft, including security fixes ends on March 9, 2021, I think we should drop support for that browser in jQuery 4.0.
[1] I'm looking at weeks since usually the share is different during weekends so full weeks are less volatile than days or months.
Core: Drop support for EdgeHTML (i.e. non-Chromium Microsoft Edge)
mgol commentedon Sep 21, 2020
PR: #4792
Core: Drop support for EdgeHTML (i.e. non-Chromium Microsoft Edge)
Core: Drop support for EdgeHTML (i.e. non-Chromium Microsoft Edge)
Core: Drop support for Edge Legacy (i.e. non-Chromium Microsoft Edge)