Edwin

Posted on May 24, 2022 • Edited on Jun 25, 2022

Internet Explorer retires on June 15 - what can developers do?

#webdev #browser #javascript #ie11

Microsoft will finally stop supporting Internet Explorer 11 on June 15, 2022. That is ~~3 weeks from now~~ RIGHT NOW!

If a Windows 10 or Windows 11 user tries to open IE after this date, the Edge browser will launch instead (or the user will be taken to the download page for Edge).

There is an IE11 compatibility mode to support legacy apps, but it may not work exactly the same. This legacy mode is supported until 2029, so we won't be completely rid of Internet Explorer for some time. However, if you are a developer that is building modern web apps, I think it's better to drop support for Internet Explorer completely.

In this article, I will explain what the problems of supporting Internet Explorer are and how you can move to a better alternative.

What's the problem with IE11?

According to Microsoft itself, IE is not a browser but a compatibility solution for legacy apps. New browser features are not supported by it, which means new apps do not work out of the box in IE. By using IE, you are effectively going back in time to experience the web as if it were 2013 (the most recent updates being only security patches).

The global market share (desktop - April '22) of IE is as low as 0.4%, compared to 64% for Chrome, 10% for Edge, 10% for Safari and 7.9% for Firefox. So who is still using it? Mostly users of legacy applications, people who work at companies with strict browser policies and... Japan, apparently.

From a technical perspective, developers that need to support IE cannot make full use of new browser features in their apps that work out of the box in evergreen browsers such as Chrome, Firefox and Microsoft's newest Edge browser.

IE11 only works with an older version of JavaScript, namely ECMAScript 5 (ES5). Developers can use tools like Babel so they can still write modern JavaScript (ES6 and beyond), which gets translated back to ES5 so it works in every browser. This "transpilation" inevitably creates overhead in the resulting code bundle. Furthermore, some third party JavaScript libraries may only be available in ES6, so an app developer has to make additional effort to ensure those libraries are transpiled as well.

Other frameworks and tools are also abandoning IE11: Webpack 5 bundles for ES6 by default, React 18 and CRA dropped support, to name a few. If you want to stay up to date, that means you will need to make the decision at some point.

Dropping support for a browser means that you potentially lose revenue of its users. A bigger problem, however, is that supporting IE11 causes a degraded performance for all other browsers. It will also lock your app out of innovative new features such as Progressive Web App features (unless you apply graceful degradation).

Unsupported features in IE11

This page compares supported browser features between IE11 and Edge version 100. The length of this list is staggering, to be honest. Some notable features:

DOM manipulation methods
Full CSS Flex and CSS Grid support
CSS sticky
CSS filters
Input types for date and time and color
Service Workers and most other PWA related features
Fetch
Custom elements
Resize observer

Missing JS language features I personally use almost every day:

Transpilation example

Consider the following piece of code where I showcase some ES6 features:

const doStuff = async () => {
  const foo = "bar";
  let qux = `${foo} with extra ${foo}`;

  return await new Promise((resolve) => {
    resolve(qux);
  });
};

This code doesn't do anything useful, but if you press F12 in a modern browser to open your developer tools and paste it in the console, it will run just fine.

Now watch the result if we transpile this code using Babel to something that IE11 understands. If you scroll down to line 11 in the frame on the right you will see something that looks like our original function. All the cruft above it is required to make it run in old browsers.

var doStuff = /*#__PURE__*/function () {
  var _ref = _asyncToGenerator( /*#__PURE__*/_regeneratorRuntime().mark(function _callee() {
    var foo, qux;
    return _regeneratorRuntime().wrap(function _callee$(_context) {
      while (1) {
        switch (_context.prev = _context.next) {
          case 0:
            foo = "bar";
            qux = "".concat(foo, " with extra ").concat(foo);
            _context.next = 5;
            return new Promise(function (resolve) {
              resolve("baz");
            });

          case 5:
            return _context.abrupt("return", _context.sent);

          case 6:
          case "end":
            return _context.stop();
        }
      }
    }, _callee);
  }));

  return function doStuff() {
    return _ref.apply(this, arguments);
  };
}();

This example showcases how building for IE11 negatively impacts your bundle size, build time, total byte size sent over the network, parse time and page load time! More about transpilation bloat in this article.

Benefits of dropping IE11 in your web app

Use modern browser features (such as the ones listed above) out of the box.
No need to support IE11 quirks. Ugly hacks to make edge cases work on IE11 can be removed, which leads to cleaner code that is easier to maintain.
The JavaScript code that is served by your app in production can be optimized for modern standards, which means transpilers such as Babel have less features to polyfill. This can potentially reduce the size of your code bundle by as much as 30%!
Simplify your testing and quality assurance process.

How to phase out IE11

As a developer, you can lead the discussion about whether or not to support IE11 with technical arguments mentioned above. Make dropping IE11 support a company goal! Put it on a roadmap! This is not just a development issue, other departments should also contribute and inform customers about the plan. As with most things in life: communication is key!

Communicate the deadline for dropping IE support to your customers, so they can prepare if needed. Switching to different browser may not be an issue for them at all. The not so tech-savvy users may not be aware they are still using an outdated browser. Companies may have an outdated browser policy which only allows IE11 for legacy reasons (or no policy at all).
Show a banner at the top of your app to warn the user if it detects IE11 usage.
If possible, gather browser usage statistics for your app.
Document any features of your app that require IE11 support on your Wiki/Confluence/README. Are these features still relevant or can they be refactored to modern JavaScript?
Write a knowledge base article about the browsers your app supports and how users can switch to a safe alternative.

How to drop IE11 support from your web app

The following steps explain how to optimize your project to drop IE11 support. Sometimes we need to tell our build tools that they don't need to transpile code for older browsers. The production bundle will no longer include patches for missing features, which will save you some precious bytes.

Use browserslist

If you are developing a web application, you are most likely using technologies such as Babel with the preset-env plugin and Webpack to bundle your code. You can set a browserslist (docs) property in package.json (or .browserslistrc file) to set the browsers you want to target:

"browserslist": {
     ">0.2%",
      "not dead",
      "not IE 11"
   }
}

You can customize the query using this tool.

Remove redundant Babel plugins

Furthermore, some Babel plugins for ES6 language features can be removed from your project and from the babel configuration, if you were still using them. Check this list and remove them from your project.

Note: These plugins are all included in preset-env, so chances are small you were using them. Still worth checking though.

Specific tool examples

Most frameworks and tools will automatically use the browserslist configuration. Just because your framework says it does not support IE11 doesn't mean the code it produces is optimized for ES6. Sometimes you still need to set the browserslist yourself.

Here is the behaviour of some of those tools:

Create React App: generates a browserslist config for you, but you need adjust it to exclude IE11 (as above).
Next.js supports IE11, does not respect browserslist for JS (only CSS)! It seems you need a custom babel config and configure the preset-env targets option
Remix: no IE11 support, promises progressive enhancement
Angular: no IE11 support out of the box(?) 🎉
Svelte: ???
Vue 3: Configure browserslist as above. Also offers modern mode for differential serving.
Nuxt: need to build with the --modern option.
Ember 4: no IE11 support, set targets in ./config/targets.js using ember-cli
Webpack 5: You need to configure the browserslist as above.
Vite: targets ES6 by default and uses a browserslist query that does not target IE11 (so it works out of the box 🎉).

Progressive enhancement for modern browsers, fallback for IE

If you want to show at least something to IE users, instead of an empty, broken page, you could use the <script> tag with a nomodule attribute. This is only used by browsers that don't support JS modules, which happens to be IE!

<!-- Your ES6+ bundle for modern browsers -->
<script type="module" src="index.mjs"></script>

<!-- Fallback for IE -->
<script nomodule>
  console.error("No module support, could not load app");
  document.body.classList.add("has-old-js");
</script>

You could go down the path of creating one ES5 bundle for IE users and an ES6+ bundle for other browsers. This technique is called differential serving. But now that IE11 is no longer supported, you should really ask yourself if this is worth the effort.

Detect IE11 using JavaScript

Checking supported browser features:

!!window.MSInputMethodContext && !!document.documentMode

Checking the user agent:

navigator.userAgent.indexOf('MSIE') !== -1
|| navigator.appVersion.indexOf('Trident/') > -1

Conclusion

So should your app still support IE? Unless you are working on a legacy app for a customer with specific needs, the answer is probably not. Microsoft does not even support IE in its own Teams app. You should at least have a plan to move away from supporting IE and inform your customers about it.

Ask yourself: What is the cost of supporting IE11, in terms of time spent on maintenance, fixing obscure bugs, code complexity, technical debt, negative performance impact, exceptions in the build process and even testing?

It's time to move forward and start writing code for the modern web.