Skip to content

Drop support for Edge Legacy (EdgeHTML-based) in 4.0? #4568

Closed

Description

@mgol

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

  1. mgol commented on Dec 16, 2019

    @mgol
    MemberAuthor

    I created a draft PR so that it's easier to see what kind of changes we could introduce if we dropped EdgeHTML: #4573.

  2. added a commit that references this issue on Dec 16, 2019
    81a036a
  3. mgol commented on Dec 30, 2019

    @mgol
    MemberAuthor

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

    1. It is still the default browser in Windows 7 & 8.1.
    2. It is still included in Windows 10 & that won't change after the new Edge gets released.
    3. Due to its ActiveX support as well as IE dominance history there are still many environments that depend on IE 11 support. That's not the case for EdgeHTML. It's not only corporate environments! See e.g. South Korea stats for last month: https://gs.statcounter.com/browser-version-partially-combined-market-share/desktop/south-korea/#monthly-201911-201911-bar. While IE 11 usage is getting lower, it's still at 17.45%! That's enormous. Compare that with Edge 18's 4.36% and take into account that will most likely decrease significantly as soon as the new Edge gets released.

    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.

  4. mgol commented on Dec 31, 2019

    @mgol
    MemberAuthor

    Paging people who might be interested in voicing their opinion here: @jquery/core @Krinkle @arschmitz @fnagel

  5. Krinkle commented on Dec 31, 2019

    @Krinkle
    Member

    This may be of interest as well: analytics.wikimedia.org/dashboards/browsers

    Screenshot

    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.

  6. Krinkle commented on Dec 31, 2019

    @Krinkle
    Member

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

  7. fnagel commented on Jan 2, 2020

    @fnagel
    Member

    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?

    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

  8. mgol commented on Jan 2, 2020

    @mgol
    MemberAuthor

    @fnagel

    ~4% (almost 5 in some stats) worldwide usage is enough for me to say: let's keep it in the 4.0 release

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

    How much speed to we gain by removing?

    I described that in my original post. Do you have an additional question to what I wrote there?

    What else do we plan to remove in the 4.0 release?

    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.

  9. fnagel commented on Jan 2, 2020

    @fnagel
    Member

    Thanks for your fast reply!

    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.

    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!

    How much speed to we gain by removing?

    I described that in my original post. Do you have an additional question to what I wrote there?

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

    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.

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

  10. added a commit that references this issue on Jan 2, 2020
    e52a181
  11. mgol commented on Jan 2, 2020

    @mgol
    MemberAuthor

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

    Have a look at my draft PR removing EdgeHTML support: #4573. Some improvements:

    1. Look at removals containing support. and also at the test in src/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 the isIE check, saving on a support test run which slightly improves performance, especially the first time a particular API runs (it also improves final jQuery size).
    2. In one place in src/selector.js we had to apply an unload handler for IE & Edge but a support test was impossible so we did it for all browsers; if we drop EdgeHTML, we can check for isIE and 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.

  12. mgol commented on Jan 2, 2020

    @mgol
    MemberAuthor

    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.

  13. arschmitz commented on Jan 2, 2020

    @arschmitz
    Member

    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.

  14. 13 remaining items

  15. added a commit that references this issue on Sep 20, 2020
    b5a70a2
  16. mgol commented on Sep 21, 2020

    @mgol
    MemberAuthor

    I'd like to reopen the discussion. I analyzed recent market share data and here are my conclusions:

    1. In the past few weeks here's how Edge Legacy (all versions: 12-18) market share within desktop browsers looks like[1]; it's going down quickly and it's already way below 1%.:
    2. If we check just Edge 18 (the only version we still officially support) and look at the overall market share in the past 4 weeks, without singling out just desktop browsers then the share is only 0.38%.
    3. Wikimedia data that @Krinkle linked above shows the following stats for Edge Legacy:
      • last 4 weeks: 1.05%
      • last 3 weeks: 1.01%
      • last 2 weeks: 0.95%
      • last 1 week: 0.90%

    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.

  17. reopened this on Sep 21, 2020
  18. added
    Discuss in MeetingReserved for Issues and PRs that anyone would like to discuss in the weekly meeting.
    on Sep 21, 2020
  19. added a commit that references this issue on Sep 21, 2020
    38e2f08
  20. mgol commented on Sep 21, 2020

    @mgol
    MemberAuthor

    PR: #4792

  21. removed
    Discuss in MeetingReserved for Issues and PRs that anyone would like to discuss in the weekly meeting.
    on Sep 21, 2020
  22. added this to the 4.0.0 milestone on Sep 21, 2020
  23. self-assigned this
    on Sep 21, 2020
  24. added 2 commits that reference this issue on Sep 22, 2020
    cad8a28
    0cbf1e2
  25. added a commit that references this issue on Sep 22, 2020
    e35fb62
  26. locked as resolved and limited conversation to collaborators on Sep 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions