RFC: Internet Explorer 11 support deprecation and removal

[IgorMinar]

TL;DR

The Angular team is deprecating support for Internet Explorer 11 in Angular v12 (to be released in May 2021 and supported through November 2022), and plans to remove support for this browser in Angular v13 (late 2021).

Why?

The worldwide usage of Internet Explorer 11 (IE11) has been steadily declining for years, and is currently at 0.73% according to StatCounter and 1.70% according to NetMarketShare, meaning that a very small fraction of the overall world population uses this browser and benefits from our effort to support it.

At the same time, IE11 is the last non-evergreen browser that Angular currently supports, and due to the feature gap between IE11 and evergreen browsers, it is becoming increasingly difficult to provide modern features in Angular while also preserving IE11 compatibility.

Since some of the core functionality of the framework, Material components, and CLI must work on IE11, supporting this legacy browser has resulted in complexity, compromises, or even in our inability to offer solutions that would take advantage of modern web APIs.

Community feedback

We'd like the community to weigh in on the timeline of removal of IE11 support.

Angular v12 is planned to be the last version of Angular that supports IE11, this version will be:

• released in May 2021
• actively supported through November 2021, and
• supported under LTS through November 2022

See Angular's support policy & schedule for more information about differences between active and LTS support, and other support policy info.

This timeline seeks to balance when the benefits of IE11 removal will materialize with the need to ensure ecosystem stability and support. If however the community feels strongly that we should move ahead on a more aggressive timeline, or if there are reasons to delay the actual removal further, we'd like to hear from you. Please provide the arguments and use cases in comments below.

This RFC will close on May 10, 2021.

The benefits

Angular is an evergreen platform, meaning that it stays up to date with the evolving Web ecosystem. By removing support for legacy browsers we can focus our efforts on providing modern solutions and better support to developers and users.

There are several groups of stakeholders that will benefit from the removal of IE11 support:

• Application users

  • the apps will be smaller and load faster thanks to the removal of IE11-specific code
  • the use of modern Web APIs will result in further UX improvements

• Application authors and stakeholders

  • will benefit from improved APIs and build infrastructure
  • will reduce the risks and liabilities due to known security issues and limitations of IE11
  • can lean on our decision as an argument when talking to application stakeholders about IE11 support (if they still support it)

• Library authors

  • can lean on our decision and drop IE11 support in their libraries as well (if they still support it)

• Angular team

  • We'll be able to remove special JS and CSS code paths, polyfills, build passes, and dev infrastructure that exists only because we support IE11.
  • Since IE11 is the last non-evergreen browser we support, we'll gain access to many new modern web APIs and features that have been around for years, but we couldn't use them due to IE11 support and limitations to polyfilling. These APIs include:
    • CSS Variables, Intersection Observers, CSS Grid (components/issues#7374)
    • Native version of EcmaScript APIs (e.g. regexp)
    • Web animation APIs
    • Proxies
    • etc

Background information

Microsoft support

IE11 was initially released almost 8 years ago, in 2013, and since that time, it has been receiving only bug and security fixes. It was superseded by Microsoft Edge, which unlike IE11 is an evergreen browser, which automatically receives feature updates including web platform API enhancements.

On August 17, 2020 Microsoft announced deprecation of IE11 support in Microsoft 365 apps and services, with the removal date set for August 17, 2021. Microsoft Teams already removed support for IE11 on November 30, 2020.

Web API feature gap

The difference in Web APIs & features supported by IE11 compared to evergreen (modern) browsers is too vast to list in this RFC, and can instead be reviewed at caniuse.org.

Browser usage

source: statcounter.com

source: netmarketshare.com

[pavankjadda]

The world-wide usage of Internet Explorer 11 (IE11) has been steadily declining for years, and is currently at 0.73% according to StatCounter and 1.70% according to NetMarketShare, meaning that very small fraction of the overall world population uses this browser and benefits from our effort to support it.

For this exact reason, we shipped first version of the project without IE 11 support. I would agree with you since Microsoft only supports Edge Chromium(for end users)

[penfold]

Really glad to see the proactive move away from IE11.

We registered with MS so that anyone visiting us with IE11 automatically redirect in to Edge.

https://docs.microsoft.com/en-us/microsoft-edge/web-platform/ie-to-microsoft-edge-redirection#request-an-update-to-the-ie-compatibility-list

[MaxArt2501]

I think IE usage should be deprecated as soon as Microsoft pulls the plug for its support for consumers, and removed soon after (next version, maybe?).
If someone needs to still support Internet Explorer, they could either provide the needed polyfills or use an older version of Angular.

Time to (finally) move on.

[e-oz]

Please consider this option: users who need IE11 support have an option to include tones of polyfills, but it will allow their apps to work.

Some companies require IE11 support because of “thin clients” they use. They don't care what will be the size of the application since app is for internal use. Leaving them with the outdated framework is not an option - it will not pass a security audit.

So with the “download tones of your polyfills” option, they would still have the ability to use Angular.

[paulparas]

Good decision, we spend most of our UI development time in fixing that one small control which works in chrome but not in IE & then we spend a lot of our precious time in applying hacks to make it work in IE.

Clients want us to use latest angular version with IE support just in case someone uses IE. Glad, now they have to chose either latest angular version or IE support. I think timeline is perfect and may even have been earlier as I don't know why someone would use IE in 2021 when they have chromium based edge or chrome. I have a top end i7 laptop and IE still fails to load fast.

If its just because some people are used to IE and don't want to try anything else , then they need to be forced to use other browsers as otherwise they would keep using IE for another 100 years.

[IgorMinar]

So with the “download tones of your polyfills” option, they would still have the ability to use Angular.

@e-oz there thank you for your feedback. Angular does all of this today and offers differential loading to minimize penalty for modern browsers. But even with this approach there is many web APIs we wish we could use but simply can't because they would be incompatible with IE11.

There are real limitations to what can be polyfilled in production-ready (secure, reliable, and performant) way. The same applies to transpilation. And for some APIs its better not to use them at all than to put in place a complex and slow build pipeline that would make things compatible.

[mhartington]

We have long since dropped IE11 support in Ionic and support this as well.

[yharaskrik]

I support this wholly and as quickly as possible. I realize there may be some uses cases that require ie11 but we have to move on and allow angular to evolve as a framework.

[mlc-mlapis]

Who says, We need IE because ... or It's too expensive to migrate from IE to... ignore the fact that those others pay all expenses (time, money, ...) instead of them, and it has been going on for a long time, and it's not possible to continue by the same way.

[sgravrock]

Selfishly I'd like to see this go ahead, because it's one of the things that probably has to happen before Jasmine can drop IE support.

When my clients ask for IE support it's because they need browser upgrades in their organization to be infrequent and planned, and they haven't figured out where else to get that. Dropping IE might be more palatable to those organizations if more than one Firefox ESR version is supported.

[alisaduncan]

This feels like a reasonable and generous timeframe to me.

The B2B app I work on has ~1.7% IE11 users we're working to message transitioning. Being able to point to Microsoft apps and significant dev frameworks like Angular dropping support will help lend credibility to the data we present in our transition messages.

I appreciate the Angular team asking for input from the community on these major decisions!

[jonparker]

I have previously worked with a company that built an internal enterprise app that only worked in an older version of Chrome. This meant they had to install the specific version of Chrome on employees' machines.
The reverse is also true. If IE11 compatibility is dropped then enterprises will come up with workarounds such as a side-by-side install of two browsers. There may be some work to modernize the integration of apps (e.g. provide a solution on how to redirect from an app that only supports IE to an app running in Edge/Chrome) but this is better than the extra work the community is doing to keep supporting IE11.

[andlewis]

Kill it with fire.

[lacolaco]

Although it is a bit irregular, I think there is an option to extend the v12 LTS until the end of December 2022.
AngularJS supports IE11 and is maintained until the end of this year; the migration to Angular is expected to continue until the very last minute (or until early next year if they don't make it). We can also expect it to be difficult for them to upgrade directly from AngularJS to the latest Angular version.
I think that having v12 maintenance for at least 1 year after the end of AngularJS support is a deadline that can be balanced when considering the whole Angular ecosystem.

[IgorMinar]

Kill it with fire.

There is no need for violence. 😊

[IgorMinar]

I think that having v12 maintenance for at least 1 year after the end of AngularJS support is a deadline that can be balanced when considering the whole Angular ecosystem.

@lacolaco that would add more than a year if LTS to v12 which is a significant commitment, but we will consider it.

Can you help me understand the connection between AngularJS upgrades and IE11. In my experience they are two distinct problem spaces which sometimes overlap in some enterprises with a lot of legacy apps and clients.

If an enterprise has a fleet of IE11 clients, I'd hope that they would be working on updating the fleet in parallel to AngularJS upgrade. Upgrading to Angular is not meant to provide "indefinite" IE11 support.

Maybe I'm missing something?

[wilmarques]

I totally agree with this decision.

But I have a big problem.
I work at a bank and we have some apps that are used by some companies.

Sometimes those companies don't have time/money/reason or even the desire to ditch IE, so we just have to stick with it.
I agree that the number of users are declining, but sometimes a client is big enough to hold an entire business.

I'll definitely use this as an argument:

can lean on our decision as an argument when talking to application stakeholders about IE11 support (if they still support it)

It may end up well. But if not, we will have to move away from Angular on some specific apps.

Let's see what happens.

[lacolaco]

@IgorMinar My thought is, the LTS version which is living at the end of AngularJS should have the same IE11 support because LTS-to-LTS migration should be supported.

Angular v12 is planned to be the last version of Angular that supports IE11, this version will be:

released in May 2021
actively supported through November 2021, and
supported under LTS through November 2022

In the timeline, December 2022 is a gap. In this period AngularJS is living but Angular doesn't support IE11. LTS-to-LTS migration won't be safe.

Sorry, it's my mistake. AngularJS EOL is Dec 2021. No problem for LTS-to-LTS migration :)

[IgorMinar]

Let's see what happens.

@wileymarques please let us know how it goes. One reason for this RFC is to spark these kinds of conversations. Removing IE11 support is just a matter of time regardless of the framework/application, and starting the conversation now will avoid surprises in the future.

[wilmarques]

Removing IE11 support is just a matter of time regardless of the framework/application.

@IgorMinar, indeed! I totally agree with you.

I'll try to get a response as soon as I can!

[adisreyaj]

I guess its the right time to do this. This has to be eventually done. +1 to what @IgorMinar said.

[pavankjadda]

I totally agree with this decision.

But I have a big problem.
I work at a bank and we have some apps that are used by some companies.

Sometimes those companies don't have time/money/reason or even the desire to ditch IE, so we just have to stick with it.
I agree that the number of users are declining, but sometimes a client is big enough to hold an entire business.

I'll definitely use this as an argument:

can lean on our decision as an argument when talking to application stakeholders about IE11 support (if they still support it)

It may end up well. But if not, we will have to move away from Angular on some specific apps.

Let's see what happens.

What would happen when Microsoft ditches IE 11 support?

[IgorMinar]

What would happen when Microsoft ditches IE 11 support?

They already have for MS Teams and will soon for MS 365 which represents most of their web products. Dropping support for the browser itself is likely complicated because of how the support for the browser is tied to the support for the OS and therefore won't formally happen for many more years. It's not reasonable for the web ecosystem to wait that long.

[SanderElias]

@IgorMinar It's about time. I dropped IE support for my customers when it was at version 8. Mostly for 2 reasons.

1. extra development time (costs, this was usually enough to convince them)
2. security. IE is a known security risk.

@wileymarques I have had this discussion before. By now, the discussion is settled. Especially when you are a bank ;)
let me explain in 1 word. liability.
Ok, let me extend on that a bit. A bank allowing their customers to use IE is telling their customers it is ok security-wise. I don't have to explain it is not and at the time of this writing, this is common knowledge.
I'm pretty sure someone that got hacked (while using IE) will sue a bank pretty soon. I'm not a lawyer, but I'm pretty convinced they do have an actual case.

It is about time IE gets dropped for the hot potato it is ;)

[naveedahmed1]

Great decision! The timeline seems quite reasonable. We recently dropped support for IE on Mustakbil.com.

After reading comment from @penfold , we've also registered our website with Microsoft's IE compatibility list, so that anyone visiting our website with IE11 is automatically redirected in to Edge.

[laiseng]

yes!!!!!!!!!!! finally, been waiting to erase my painful memory of IE11 hacks and workaround

[d-koppenhagen]

Once the IE support is removed, will there be a switch in the ListKeyManager implementation from event.keyCode to event.code of the CDK? As currently IDEs will provide a deprecated issue like this:

See also closed issue here: angular/components#12672

[itea-dev]

Why not remove official support for IE early in v12, instead of waiting until v13?

Companies interested in IE can keep using version 11 which still has more than 1 year of support.

[kaito3desuyo]

I hate IE as much as you do, and I agree with the community policy of removing IE support.

Unfortunately, the usage rate of IE is still high in Japanese public organizations (about 30-40% by experience), and it is used within the intranet, so "security reasons" do not motivate the renewal of devices and browsers. Some organizations even have a security policy of "using IE11".

And even more unfortunately, I and my team are developing an app in Angular for use on that intranet...

I think the immediate solution here is to "do not update from Angular v11".
It would be nice to have the ability to optionally specify the version instead of always installing the latest version (corresponding to the Angular CLI version) with the "ng update" command.

[indraraj26]

I would suggest create one additional package, @angular/ie-11-support

it should load before bootstrap (main.ts)

there are banks/upi solution which still uses IE11, it is really painful to explain them.

[IgorMinar]

I would suggest create one additional package, @angular/ie-11-support

@indraraj26 this would essentially mean polyfilling the missing APIs, which is what we do today but that only works for a subset of APIs we'd like to use. For example it's not possible to polyfill CSS custom properties in this way.

[IgorMinar]

It would be nice to have the ability to optionally specify the version instead of always installing the latest version (corresponding to the Angular CLI version) with the "ng update" command.

@kaito3desuyo you can use this trick: npx @angular/cli@11 new my-angular-v11-app

[spock123]

We specifically do not support any IE version at all. We never had any issues with that - removing support greatly simplifies and improves our solution.

/update
Actually I lied, we do "support" IE: we detect IE and tell the users to upgrade /s

[ghost]

I think the timeline of dropping IE 11 support can be more aggressive since those who still need IE 11 support can stay on Angular 11 as it's stable and performant enough and will be supported in almost 1 year.

Considering the benefits of dropping IE 11 support, we can drop IE 11 support in Angular 12 immediately instead of waiting for Angular 13.

[IgorMinar]

Just a quick summary of the discussion and a reminder that the RFC closes next Monday.

So far it seems that vast majority of the people that got involved in the discussion support the deprecation and removal timeline as proposed. There are two additional smaller groups of people — those that would like us to outright remove IE11 support in v12, and those that would like to see an extension of the support period.

Several commenters asked if we could offer polyfills and additional transpilation — this is something we already heavily do and that's how the current IE11 support works, but there are real limitations to what we can do with this approach and we feel strongly that these limitations are holding the entire Angular ecosystem back and prevent all of us taking advantage of using modern Web APIs.

In #41840 (comment) @SanderElias reminded us that there are real security threats and risks affecting any businesses that still rely on IE11 and these concerns outweigh concerns about teams eventually using unsupported version of Angular.

If you have additional comments or things that we missed, please let us know. Thank you!

[s-gbz]

I am really glad the Angular team is taking a step into a modern, IE free web 🚀 🔥 !
I also do agree with suggestions as @waynon s (tackle the process even faster) since the only users of IE are "old fashioned" companies that rarely update their systems anyway (my humble experience). They have found workarounds for IE and probably will find further if necessary.

This is probably not the most objective or persuasive argument, but HEY, we all know there's truth in it 😄 😇

[eemt]

One follow up comment. For those who believe they "need IE support for legacy applications." Microsoft has provided a path forward: Edge/legacy mode. If that doesn't work, that's Microsoft's responsibility to address. It shouldn't hold up everyone else.

[hrishikesh-shukla]

I totally support the move that is being taken up and timeline also seems perfect. I don't know who is using IE in 2021. Great decision.

[bjfu-projects]

I do think we can remove support for IE 11 in Angular v12.
😘😘😘

[IgorMinar]

This RFC is now closed, thank you everyone for participating.

Since my last summary of the discussion we heard from several developers that they'd like IE11 support removed in v12. Judging by the number of reactions, it seems that this group of community members is still in minority compared to those that would prefer to go with the originally proposed timeline.

In reality the difference between dropping IE11 in v12 and v13 at this point in time is negligible. The master/main branch will be open for breaking changes targeting v13 in 2-3 months, so that's when we we'll able to start making IE11 incompatible changes. 2-3 months is insignificant in the long term perspective, and not worth creating the extra inconveniences for developers and teams that still support IE11.

So to summarize, the originally proposed timeline is the one with the most support, this means that IE11 support will be deprecated in v Angular v12 (to be released in May 2021 and supported through November 2022), and IE11 support removal will occur in Angular v13 (late 2021).

Thank you again everyone for sharing your thoughts with us and helping us make the decision.

[Stargator]

@IgorMinar thanks for opening this. I wished I had seen it before the ng 12 release, but I'm happy that the team engaged in this discussion.

[pavankjadda]

Microsoft finally retiring Internet Explorer 11 on June 15,2022

https://blogs.windows.com/windowsexperience/2021/05/19/the-future-of-internet-explorer-on-windows-10-is-in-microsoft-edge/

[michaelrobertson-fico-com]

Fully support this decision. Frankly it's difficult to understand the tenacity with which some organizations have clung to this relic. There have been much better options for a very long time. Our stack includes Bootstrap and we were supportive of BS5's decision to drop IE11 support. It's great to have clarity from our framework of choice.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}