mui
[RFC] Completely remove IE 11 support
Internet Explorer 11 market share is rapidly decreasing.
Soon or latter, we should be able to drop it. Removing the support for this browser, will enable us to remove some code (32 edge cases). It would also enable us the usage of CSS variables. I would like to experiment on CSS variables support for the theme before that. It could be a great alternative to style functions and dynamic themes.
Regarding the timing, should we do it in 2019, 2020, 2021 or later?
Just for reference, end of support for IE11 is May 11, 2021 (Windows 10 EOS, excluding LTS versions). https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet
I'm adding the v5 milestone. Let's check again the market share in 1 year from now.
Just for reference, end of support for IE11 is May 11, 2021 (Windows 10 EOS, excluding LTS versions). https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet
This deadline is moved up every 6 months by another 6 months and as long as IE11 remains part of Windows it will be supported. The current deadline is actually January 2029 (January 2024 if you want to ignore businesses).
The current deadline is actually January 2029
That's why I said excluding LTS. If companies wish to pay for LTS for Windows 10 (ergo IE 11), they're welcome to pay for LTS for Material-UI. 😄
As the gap grows between the evergreen browsers and IE11 the pressure will increase to abandon IE11 so the rate at which IE11 is being dropped should accelerate. I'm seeing conservative Enterprises adopt policies whereby users have access to IE11 for legacy apps but use Chrome for everything else.
I think it should also be taken into account that the changes being discussed now (for v4) won't be released for X months, at which time new products will start to be based on it, which will be released and begin their active lifecycle another Y months later. And even then, projects that still need to support IE can keep using v3.
I think the bootstrap people had the problem that they didn't think they could depend on flexbox for their v4, but as their development slowly moved forward, the browser market also moved forward, so they had to revisit that important decision.
@GitTom I agree with your analysis. We have been planning the breaking changes of v4 for a long time. Executing them shouldn't take more than 1-2 months. People should be able to upgrade easily. We will try to provide some nice new feature to encourage people to perform the upgrade. It's the only thing that might delay the v4 release. For instance, we could rework our styling / theming solution.
For our users (which are almost all corporate users, but from a large number of different companies) over the last 6 months, IE 11 is still the most popular browser.
- 47% IE 11
- 35% Chrome
- 6% Edge
- 6% Safari
- 3% Firefox
It has only been very recently that we have been able to drop support for IE 8-10.
I would like to at least see Chrome clearly eclipse IE 11 usage within corporate environments before dropping support for it.
For comparison, in the 6 months ending a year ago we had 51% IE 11 and 31% Chrome.
Here's a blog post on the Microsoft tech site by one of their 'cybersecurity' experts (posted a couple days ago)...
The perils of using Internet Explorer as your default browser [microsoft.com]
It reminds people that IE should only be used for compatibility with legacy apps. For that purpose it will be around forever, but those apps are not relevant to this discussion.
And I have found that user who have IE for legacy apps and Chrome for everything else need reminding to switch back to Chrome - they get into IE for some internal apps that require it and forget (or don't know to) switch back.
@ryancogswell That is not to question the importance of your users (or the relevance of your opinion given that you contribute to material-ui and I don't) but stats from an individual vendor/company/user don't really serve the purpose that stats are meant to. Someone could chime in and tell us that their users were almost 100% Chrome - these numbers all have to be placed within a larger context. IE is a small part of the market and with MS actively warning people away from it and other apps dropping support for it I think that the percentage of users who only have IE will be tiny by the time products based on the next version of material-ui are actually in front of them.
@GitTom So far, my contributions have been pretty trivial, so I wouldn't put too much weight on my "contributor" label. I understand that my numbers are not representative of the internet as a whole, but the source of the data for the chart says "18% are corporate sites" and I think my data may be closer to representing more typical corporate browser usage. At the very least, typical corporate IE 11 usage is going to be way more than the 5% in the chart. Ending support for IE 11 could be a showstopper for a whole class of apps that deal primarily with corporate customers and need to avoid the headaches of not supporting the default browser of many of the users.
these numbers all have to be placed within a larger context.
I disagree with that. For me the "global usage" argument is incomplete. You have to consider other dimensions here e.g. demographics of your app. It may look fine to loose 5% of customers but are you ok with loosing 90% of elderly people or corporate users? What amount of money spend these 5% on your product? It is not obvious that 5% of your users = 5% of your app value.
All of these things need to be examined on a per app basis. I'm not sure we should make that choice. 1% of our bundle for 5% may be OK. 5% of the bundle for 5% of our users may be not.
Maybe we can extract some of those fixes into a separate package that applies polyfills/(monkey)patches to our components. Then app devs need to explicitly decide if they want to support IE 11 or not.
For example we have some components where we have to write different code because Array.prototype.find is not supported in IE 11. We might as well suggest a polyfill here. It makes no difference whether we write that code down explicitly or have it in the bundle implicitly via polyfill. One could argue that the latter one is better because it helps code de-duplication and reduces the risk of bugs in your custom code.
I certainly have no problem with requiring polyfills for those of us who still need to support IE 11. Our app already has quite a few (including find).
Sure code transforms is definitely an argument. We can't provide an easy solution via polyfill. However we do currently have an /es build that targets the latest es spec. It's a more advanced optimization but I'm happy with that solution. I want to revisit that build for v4 anyway and that would be a good opportunity to extend the docs for that build.
@oliviertassinari does that mean that it is possible that JSS won't be required anymore in the future? Asking because I prefer css-modules for styling and the only advantage I can see JSS has is that it allows theme changes at runtime, but with css variables you could achieve exactly the same.
(I know I can use css modules now, but JSS is still required anyway for built-in styles)
@klis87 We have an ongoing effort to minimize the styling solution overhead. We will invest time on the problem.
Just wanted to chime in that we also only recently dropped IE8 and will likely be supporting IE11 for quite a while.
If you've never worked in an enterprise environment, it might be easy to miss how, unlike every other browser, global usage stats don't really tell an accurate story regarding IE. Enterprise computers might take years or even decades to upgrade, users might not be able to install their own programs so have no possibility of seeking an alternative, and Microsoft currently doesn't offer a browser for even slightly older OSes like Windows 8 (this is supposed be rectified with the Edge rebuild).
More importantly, it's worth noting that even if actual usage numbers of your app are low not just globally but even in enterprises, the fact that salespeople can say IE11 is supported is often a requirement for making the sale. And that will probably remain true long after global IE11 usage drops below 1%.
It's also worth remembering that for many people, these enterprise customers are exactly where the money is.
Obviously I understand IE11 support is annoying...that's why I use something like MUI! :) Polyfills of course are easy to add and already being used on our apps, so if using those help make mui easier to work on go for it! Or if there was a package like '@material-ui/iehacks' to import. If it's really an issue for some reason, maybe some widgets don't get updates and the last supported version is frozen at '@material-ui/ie/Dialog` or something.
Thanks for your work on MUI! I appreciate the great tool. Also, worst case we can just keep using an old version of MUI so it's not the end of the world if the benefits of dropping IE are really actually worth it.
@nperichSYKES Thank you for the feedback. We will take it into account.
One thing to consider about dropping IE11 support is that it would disproportionally target screen reader users. While global usage might be < 2% it is around 23% for screen reader users according to https://webaim.org/projects/screenreadersurvey7/#primary. Usage is declining there as well but still way higher compared to global stats. This is an example to what I was referring to in https://github.com/mui-org/material-ui/issues/14420#issuecomment-463106939: Global usage stats are not the full picture and might even be misleading.
I'm more and more leaning towards creating new bundle that targets evergreen browsers. IE11 support remains the same but a slimmer bundle is available (could be used with module/nomodule approach) which means IE11 support is opt-out.
@GitTom I'm not aware of a more recent study though results for 2019 are scheduled to be released this month: https://webaim.org/projects/screenreadersurvey8/
Newest results are in: https://webaim.org/projects/screenreadersurvey8/#browsercombos
Key takeaways:
- primary screen reader is used with IE 11 for 11% of the respondents
- most of these use it with JAWS
It seems very likely to me that this is also closer to how corporate IE 11 usage looks like since they are more likely to provide a paid screen reader to their employees and software updates in a corporate/public sector environment can take a lot longer.
I would re-purpose our /es build to act as a "module" build (targets evergreen browsers) and the default build to act as a "nomodule" build at least as long as react itself supports IE 11. module and nomodule builds explained
@eps1lon If I understand correctly, the advantage of a re-purpose of the /es folder is to remove the need for a Babel handling of node_modules to target "module" browsers?
I think that it would be interesting to have a table that shows the bundle size necessary to target the IE11 platform (our current default distribution), the "module" browsers (proposal) and the size of the current /es folder. It has the potential to be a good tradeoff.
I like the idea of supporting IE 11 as long as React does.
No just remove /es since I don't think it serves a particular purpose other than being the source for a module build. We would provide this out of the box. Transpiling the /es build down targetting evergreen browser should add little overhead.
I'm sorry, I don't understand the whole proposal. We would rename the /es folder to something like /modules and target older browsers? Sounds fair.
Should we quantify this limited overhead? I don't expect it to be important either, but it might be worth double-checking.
Here's an update on the stats I see for our app. Our app is used almost exclusively within corporate environments. Below is the breakdown of our customers' browser usage in the last 6 months:
- 44% Chrome (40% Windows, 2.6% Mac, 1% Android)
- 41% IE 11
- 7% Edge
- 5% Safari
- 2% Firefox
This is the first time that Chrome has topped IE 11 in our stats, but the IE 11 users still account for a significant percentage of users over the last 6 months from over 200 different companies.
The idea of supporting IE 11 as long as React supports it sounds nice, but I suspect this will not be practical. React still supports IE 9 and 10 with polyfills. It could be several years before they drop IE 11 support.
A more realistic goal may be to support IE 11 at least 6 months to a year beyond the official release (as opposed to preview/beta releases) of Chromium-based Edge. This would mean for sure supporting it for version 5, but perhaps not for version 6.
As long as it doesn't happen too soon (i.e. not in the next year), I would actually be thankful for Material-UI ending IE 11 support since it would give us a strong rationale for ending our own IE 11 support and the maintenance/testing headaches that accompany it.
UPDATE Chromium-based Edge was released on January 15, 2020. With that release, there is a non-IE Microsoft browser available for older Windows versions (e.g. Edge can now be installed on Windows 7). Between Sept 30, 2019 (when I first posted this comment) and Feb 10, 2020, our customers' IE 11 usage for the previous 6 months has dropped from 41% to 36%.
Many comments here are arguing in favor of keeping IE11 in order to maintain support for business, so I'd like to offer up a counter perspective.
Draconian/underfunded/lazy IT departments are enabled by so many libraries bending over backwards to support them, for free. If, instead, libraries started dropping support, these IT departments would face increasing pressure to update their networks. Additionally, by dropping support, libraries transfer that burden to those IT departments, and removes the overhead from all of the developers who do not care about them.
Chrome, and especially Firefox, support older operating systems pretty well, so these IT policies are decreasingly excusable, especially from a security perspective.
I am more sensitive to the screen-reader demographic, as this group is often cash-constrained, and has a more difficult time making this switch. However, as shown earlier in the thread, NVDA usage is rising fast (which is free), and IE11 usage in this demographic is falling fast.
There is an additional, so-far unspoken for demographic that have needs in opposition to IE11 support: the computing-resource constrained. E.g., users that may have a newer (but low-end) device supporting modern browsers, but with major bandwidth, processing, or memory constraints. Supporting IE11 means keeping in polyfills and other inferior implementations to their detriment when browser native implementations may be much more CPU or memory efficient. I suspect that, for many more developers, this is a bigger demographic than the previous two combined, and is a similarly important equal-access demographic as screen-reader users - who may be simultaneously in this demographic as well.
With that in mind, at what point it is reasonable to expect users to meet developers halfway? Secondly, what is reasonable for library-contributors to maintain vs library-consumers who target the out-of-date IT department demographic?
Perhaps a more broad question for this issue would be: What criteria should the library have for supporting, or dropping support for a platform? E.g., "Support all browsers with at least x% global usage AND y% screen reader usage".
If, instead, libraries started dropping support, these IT departments would face increasing pressure to update their networks.
There are actual people using the software provided by the IT department. Non-tech people don't want to switch to another browser. They oftentimes don't even know what a browser is. They just want access to the internet.
That being said we'll probably make "modern bundles" the default in v5 and ship a legacy bundle with it. I don't think we will change our IE 11 support model beyond that.
There is a side of the story that we haven't heard of much: the Chinese market. I have heard that they have a stronger IE and UC browser usage. Ant Design in v4 (the next version that will soon be stable) drops IE 9 and IE 10 support.
Draconian/underfunded/lazy IT departments are enabled by so many libraries bending over backwards to support them, for free. If, instead, libraries started dropping support, these IT departments would face increasing pressure to update their networks.
You might be missing that there is an intermediary here – the software developers who are dependent on libraries such as Material-UI, but whose customer are the afore-mentioned IE11 using monsters (more on that later). If one of the barriers to sale is "must support IE11", then not having IE11 support is business limiting at best. Who we are supporting is no IT departments stuck in the dark ages, but developers who have committed to Material-UI, yet have customers who are, for whatever reason, committed to IE11.
So, why don't these draconian/underfunded/lazy IT departments stop mandating IE11 / find the money to upgrade to Windows 10 / get off their lazy backsides and get on with it?
Because like all things, it isn't quite that simple.
Let's start with this premise: You're a large enterprise with thousands, or tens of thousand of employees who collectively use numerous web based applications and portals – proprietary, third party, and SaaS. Oh, and you've already upgraded to Windows 10 (and everything needed to support it).
Unfortunately the desktop team doesn't get to control the choice of applications, nor their development or replacement cycles; and the historical data that they contain can't just be thrown away for business, legal, or regulatory compliance reasons. Some of these applications only work with IE11. Sucks to be you.
So what to do? Well you don't want to confuse users with two browsers, so, as long as the remaining applications support IE11, that's the default browser. (It's what users are used to anyway. Internet? The the big blue "e" with a swoosh, right?)
So with that in mind, if the business needs a new application, it had better support IE11.
Eventually a business need manifests itself for which the preferred solution only supports modern browsers. Yay! But now we have to educate users that Edge is for the new shiny, IE11 for the old cruddy, (and use whichever you prefer for the rest).
At some point, the number of applications that need a modern browser outweigh those that still need IE11. The scales have tipped, but IE11 lives on. And some of those pesky users have muscle memory like it's Arnie on steroids.
Some day, those legacy IE11 lovin' applications will all finally go away. Until then...
cc @ryancogswell