Celebration. Joy. Relief.
These are some of the words used to describe a web developer’s reaction to Microsoft’s announcement that some of their own apps and services will end support for Internet Explorer 11 in August 2021. While IE 11 is not officially sunsetted (it follows the same support cycle as the platforms with which it is included), it has taken a back seat to its replacement, Microsoft Edge, and is definitively on its way out.
And though precise measurement of browser usage is difficult, IE 11 likely represents approximately just 1 percent of the internet’s browsing traffic at the time of writing.
So, should your app or service continue to invest time in IE 11 support? The answer is every software engineer’s favorite: it depends.
Each app, business, and project will have a different answer and timeline for dropping legacy browser support. Below are some different aspects of this question as you consider dropping IE 11 for your app or web site.
Identifying who your users are and how they interact with your web property is paramount to making decisions regarding browser support. Are your users primarily from large corporations whose IT departments have strict policies in place that limit choice for web browsing software, or are your customers from small businesses where the latest tools and technologies are the norm?
How many of your current users interact with your app using IE 11? What job(s) does your software get done for your users? Answering these fundamental questions will lay the groundwork for a productive internal discussion on whether or not to drop IE 11 support.
Do you build a B2B SaaS offering with large but infrequent contracts, or are you building a hobby app in your free time outside of a regular job?
Is the technology itself the core value proposition of your app or does it simply enable your underlying business model?
In each of these cases, a shift in legacy technology support will have dramatic differences in how the project or business will be impacted. You need to involve all key stakeholders of the app and carefully weigh the benefits of developer experience against any potential reductions in revenue or other business implications.
Some large contracts include stipulations about legacy support timelines and service level agreements for bug fixes, among other things. If applicable, be sure to check with your company’s legal department to be sure that dropping IE 11 support would not constitute a breach of any contract.
Ultimately, all of the above exploratory questions lead to a final cost-benefit analysis on dropping vs. maintaining IE 11 support for your site or app. Answers to the above questions will help you rank, compare, and add to the following lists of example costs and benefits:
OK, so you’ve carefully considered all the possibilities and potential implications of dropping IE 11 support and have decided that the benefits outweigh the costs. What’s next?
There are a few different approaches that can help minimize any friction users might encounter.
At my company, Rivet, we supported IE 11 for the first year or so of the company’s life, and later decided to limit browser support to the latest two versions of the evergreen browsers (such as Chrome, Safari, Firefox, and Edge).
Rather than pull the plug completely, we carefully crafted a fallback experience for users who try to access our application with a legacy browser. To do this, we ship a separate bundle — a mini-app — that supports all browsers and shows an instructional message to the user prompting them to download a modern browser if they wish to access our application.
This added a little bit of complexity to our build and deploy processes, but has proven worth it; to simply show a blank page with a console full of errors would leave the user stranded and without a clear path on how to get unstuck.
Our CTO even visited the office of one of our largest customers. Upon arrival, he witnessed one of our users open up our app in IE 11, see the message, and then promptly switch over to Chrome to continue using the app. It was certainly a relatively smooth experience compared to the alternative, which perhaps would have been an awkward moment of confusion followed by “Yeah… you’ll want to try that again in Chrome or Firefox.”
If an automatic in-app message is not an option, there are other ways to ensure your users are as taken care of as possible:
Legacy browser support also doesn’t have to be an all-or-nothing endeavor. The spirit of backward compatibility and progressive enhancement runs deep into the web’s DNA.
Responsive web design is the practice of offering a different design for your site or app depending on the size or type of device your user is using to interact with it. This idea is extended beyond aesthetic considerations to include behaviors and functionality.
The idea of offering a different experience based on the capabilities of the user’s browser is as old as the web itself. You might, therefore, consider offering basic functionality to IE 11 users along with a prompt to upgrade to a modern, standards-based browser for more advanced features.
Ultimately, software is for humans, by humans, and is a way that we communicate with each other and make each other’s lives better.
There is a delicate balance between pursuing a comfortable developer experience — therefore, shortening the release cycle and allowing for more or higher-quality software to be shipped more quickly — and enabling as many types of users as possible to gain value from an app.
Dropping support for legacy browsers like IE 11 should be considered carefully and approached pragmatically and empathetically.
Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not
server-side
Learn more →
$ npm i --save logrocket
// Code:
import LogRocket from 'logrocket';
LogRocket.init('app/id');
// Add to your HTML:
<script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
<script>window.LogRocket && window.LogRocket.init('app/id');</script>
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Walk you through how to set up and use the Tailwind Typography plugin, also known as the @tailwindcss/typography or the prose plugin.
TypeScript adds static typing to JavaScript code, which helps reduce unpredictable behavior and bugs. In the past, TypeScript code couldn’t […]
Implement secure authentication and role-based authorization in Astro using JWT, SSR, and Astro middleware for protected routes.
Walk through how to use Google Fonts and locally installed fonts in your Tailwind projects to help you improve your project typography and design consistency.
2 Replies to "Should you drop support for Internet Explorer 11?"
All your blog posts should have dates. Example: This article on whether to drop support for IE is useless without a time context.
Hey T. The date at the top says Jan 18, 2021. Were you referencing a different date?