Should You Continue To Support Internet Explorer 8

As we close 2014 web developers, designers, architects and stake holders need to make an important decision, should you continue to support Internet Explorer 8? Before I answer let's explore what is and should be happening over the next year.

In August Microsoft announced the end of life for Internet Explorer 8 as January 12, 2016. As I pen this article that day is 13 months away. This is good news for the web developer because now we can confidently build against the latest standards, or can we?

What Internet Explorer Will Be Supported?

After January 12, 2016 The following Internet Explorer versions will be supported on the different operating systems:

  • Windows Vista SP2 - Internet Explorer 9
  • Windows Server 2008 SP2 - Internet Explorer 9
  • Windows 7 SP1 - Internet Explorer 11
  • Windows Server 2008 R2 SP1 - Internet Explorer 11
  • Windows 8.1 - Internet Explorer 11
  • Windows Server 2012 - Internet Explorer 10
  • Windows Server 2012 R2 - Internet Explorer 11

What this means is unless you are upgraded to Internet Explorer 11 by the 1/12/16 date you will no longer receive critical updates, including security fixes. I say IE 11 because I know next to no one still uses Vista (less than 3% and falling), so the IE 9 version is negligible. I also know very little traffic comes from server operating systems, so the IE 10 for non-upgraded Server 12 is also negligible.

Will there still be hold outs? Of course, there always are. If you look at global market share XP still holds 10%, but the majority of the 10% is in China and underdeveloped countries. Should you worry about supporting them? Maybe, the descision depends on your business and a cost benefit analysis. If you do a lot of business in China then knock yourself out with support for very old browsers.

What Will Happen in 2015?

When making your decisions you need to consider what the world should look like 12 months from now. This is a list of actionable items that should happen next year, 2015:

  • IE 8 usage trends are going down. [IE 11 leads followed by 8](
  • IE 8 will not be supported in 13 months, usage will necessarily go down over the next 12 months.
  • Microsoft must make an organized effort to get enterprises off IE 8 over the next year.
  • Internet Explorer 8 Market share has been falling for some time

These all point to the same thing, Internet Explorer 8 will die a rapid death over the next year. My personal belief is you will see IE 8 almost completely die in the developed world and hang around more in the undeveloped world and China. I base this on Internet Explorer 6 and Windows XP death marches. Unlike those two platforms, Internet Explorer 8's death march should be rapid. I also think Microsoft has learned valuable lessons in its efforts to purge customers from Internet Explorer 6 and Windows XP. These lessons will help them encourage upgrades. I also believe Enterprise Mode is a great feature enterprises can confidently use for legacy applications. This means enterprises will not incur extra expenses upgrading existing applications like they did migrating from Internet Explorer 6 to 8.

One factor many developers fail to consider is security. Internet Explorer 8 is just not as secure as 11 and will never be as secure. This alone is a strong reason enterprise IT departments will upgrade Internet Explorer. With the many high profile hacks that have occurred lately, like Sony, businesses will gladly upgrade so they can be a little safer.

Enterprise Mode Provides the a Safe Haven for Legacy Line of Business Applications

In April Microsoft released a new feature, Enterprise Mode. I have written about Internet Explorer Enterprise Mode a few times and will be focusing on Enterprise Mode more over the next year. Enterprise Mode is designed to enable enterprises to safely upgrade their corporate browser policy without fear they need to invest in expensive application upgrades. Granted those legacy applications do need updating, it is not as urgent because Enterprise Mode exists. This is the key to killing Internet Explorer 8. Businesses can upgrade with confidence knowing their infrastructure is safer, legacy applications can execute faster, yet still work using 2008 standards.

What Are the Costs?

All applications have their own persona and because of this require different efforts to maintain and upgrade. When you build a modern application you need to make your best effort to estimate how much it will cost to make the application work on an old platform like Internet Explorer 8. Again you need to consider Internet Explorer 8 was created and released before the 2008 mortgage crisis. At that time jQuery ruled the world and HTML5 was barely a thing. One of the few features supported in Internet Explorer 8 critical to modern application architecture is Web Storage. New semantic elements, CSS3 and many key APIs were not supported by any browser in the Spring of 2008. The way web software was architected was different.

It was a different time and web development has progressed quite a bit. You can build web applications using 2008 best practices today. You cannot effectively build modern, single page applications using 2014 best practices and techniques for a 2008 platform (browser). Sure you can clamp in polyfils and partially enable many features. These polyfils cannot match the stability and performance native API support offers. This means customers are not receiving a good experience and development teams invest more time supporting modern features using these polyfils. No one is happy in the end.

As part of your cost benefit analysis you need to consider how much it is going to cost to support older browsers, including how long will it take to create support for those platforms. If you need 3 months to develop, test and deploy you are going to receive 9-12 months of usefulness. Also consider the audience size will be trending downward all year long. If you have 10% IE 8 usage today, 3 months from now that might be 6 or 7%, 6 months down the road less than 5%. It is a race against time and potential revenue.

Instead you should consider providing a simple version of your web application, in classic web site form. This solves two problems, providing a functional experience for legacy browsers and a search engine spider friendly version. This is known as a 'core site'.

What Is A Core Site?

In my book, High Performance Single Page Web Applications, I go into detail about implementing a core site. The term I first heard coined by Andy Hume at a 2013 Smashing Conference. In Andy Hume's talk on real-life responsive design he goes through lessons The Guardian learned building a modern web application used by browsers of all types. A core site is a low fidelity version of a modern web application. I like to think about it as the standard definition version of a high definition or 4k video. It works, but the experience is no where near as rich.

I have some rules for my core sites, next to no JavaScript, minimal CSS, all markup is rendered on the server. Wait that sounds like a 2006 era web site. Yes, because it is. This does not mean you need to make a second web site. It does mean you need to do feature detection early in the rendering process and redirect the user to the core site. This can be paired with some server side sniffing, but it is not required. The following is a standard code snippet I execute at the top of my markup now:

<script> var ef = "?_escaped_fragment_="; if (!('querySelector' in document)   -- !('localStorage' in window)   -- !('addEventListener' in window)  -- !('matchMedia' in window)) {  if (window.location.href.indexOf("#!") > 0) {   window.location.href = window.location.href.replace("#!", ef);  } else {   if (window.location.href.indexOf(ef) < 0) {    window.location.href = window.location.href + ef;   }  } } else {  if (window.location.href.indexOf(ef) >= 0) {   window.location.href = window.location.href.replace(ef, "#!");  } }</script>

I know there are 3-4 modern APIs I can detect support and if any of those APIs are not supported I redirect them to the core site. If you want you can switch compatibility mode to Internet Explorer 9 or below right now and this blog will look much different. It functions, but it is nothing fancy.

I know from analyzing my traffic there are fewer than 5% of my visitors using an outdated browser. I know my effort to support these visitors is not time and money well spent. I also know the traffic these older browsers represent is trending down and will be negligible in about a year. Again if you read my book there are two chapters on server-side responsibilities where I discuss techniques to enable core site support while applying a minimal amount of effort. In short you need a way to render on the server what you would normally render in the browser using an API and AJAX techniques. But a core site serves a second, important purpose, search engines.

Providing A Search Engine Compliant Legacy Site

Modern web applications utilize a thick layer of JavaScript, AJAX and render content dynamically. This makes it hard for search engine spiders to properly index the rich user experiences. Fortunately Google has provided an SEO specification for us to follow. There are two key things the specification calls for, a core site and the use of the queryString.

I wont go into the details here, but if you go back and review the code snippet above you will see the redirect mechanism takes the hash fragment or spa route, and adds that value to the queryString. The queryString parameter is escapedfragment, "?escapedfragment=". Now the page's modern route is passed to the server. I have written a helper ASP.NET MVC library called SPAHelper, to make life easier for developers to implement the server-side core site support in ASP.NET MVC. I am currently working on a node/express and ASP.NET vNext versions.

What are Other Options?

A common scenario I encounter with clients is being tasked with creating a modern version of their existing application. Their application supports legacy browsers and uses classic web architecture. In short this is a core site that works. With a little effort it can be used to satisfy the requirement for older browsers and even search engine compliance. This is a very cost effective solution to leverage. Not only does it make it easy to implement a core site, it breaths more life into an existing code base. I call this a win win scenario.

The last option is to do nothing. You can always use your existing web site, don't leverage modern platform features. 'If it ain't broke' sort of mentality. Of course by doing this you are opening yourself to an easy defeat by competition. Eventually you will encounter competition in your marketplace and by not investing in your application you may not be able to adequately adapt to compete. Most of you are thinking this applies to just online commerce, but you would be wrong. Line of business applications need to adapt too.

Line of business applications define your process, they affect your people and ultimately produce your product. These three pieces are the foundation of any good business and they affect each other. If your application never improves the product it produces can never improve. If you do not measure product quality and improve your process your business says stagnate, at best. Remember entropy affects software just as it does the physical world around us. If your application never improves your employees will not enjoy using the application. When your employees are not happy your product quality suffers. When your product quality suffers your business declines.

Many businesses run on legacy applications every day, we all see many retailers, medical and government offices using green screens. The experience is often poor, but they press on. Ultimately entropy takes over and the business closes due to lack of effort. Business too lazy to improve always go under.


To answer the question, should you support Internet Explorer 8, the answer is no not directly. You should provide a low fidelity fallback. If you need search engine placement you need a core site. This site serves a dual purpose by providing an experience for out dated browsers. If you have an existing site, the keep it running, for now. If you have a line of business application and you need to update it, do it right. Remember existing applications generally work in modern browsers. Sometimes you need Internet Explorer 8, use Internet Explorer Enterprise Mode for these applications. You can have the best of both worlds, but other than search engine compliance you should not continue building applications for obsolete browsers. Internet Explorer 8 will be all but dead this time next year and does not deserve your money. Invest in the future, not the past.

Share This Article With Your Friends!

{ "@context": "", "@type": "NewsArticle", "mainEntityOfPage": { "@type": "WebPage", "@id": "" }, "headline": "Should You Continue To Support Internet Explorer 8", "alternativeHeadline": "Should You Continue To Support Internet Explorer 8 - ", "image": { "@type": "ImageObject", "url": "", "width": 267, "height": 800 }, "datePublished": "2014-12-08T12:57:43.512Z", "dateModified": "2017-10-29T12:43:24.113Z", "description": "As we close 2014 web developers, designers, architects and stake holders need to make an important decision, should you continue to support Internet Explorer 8?", "author": { "@type": "Person", "name": "Chris Love" }, "publisher": { "@type": "Organization", "name": "Love2Dev", "logo": { "@type": "ImageObject", "url": "", "width": 409, "height": 75 } } } try { var scripts = ["js/b7fa3de28fba29fa709c75cf81f4324f.min.js", "js/ac5f096ea7e04bc4a2be471a007ea464.min.js", "js/ca47b9e458c783fca7191198c74bbbd5.min.js", "js/90f6b648c4625b3e4b8525553ab5deed.min.js"], src, pendingScripts = [], firstScript = document.scripts[0]; if (typeof Object.assign != 'function') { scripts.unshift("js/libs/polyfil/object.assign.js"); } if (typeof Promise === "undefined" || Promise.toString().indexOf("[native code]") === -1) { scripts.unshift("js/libs/polyfil/es6-promise.min.js"); } if (typeof fetch === "undefined" || fetch.toString().indexOf("[native code]") === -1) { scripts.unshift("js/libs/polyfil/fetch.js"); } if (typeof IntersectionObserver === "undefined" || IntersectionObserver.toString().indexOf("[native code]") === -1) { scripts.unshift("js/libs/polyfil/intersection-observer.js"); } // Watch scripts load in IE function stateChange() { // Execute as many scripts in order as we can var pendingScript; while (pendingScripts[0] && pendingScripts[0].readyState == 'loaded') { pendingScript = pendingScripts.shift(); // avoid future loading events from this script (eg, if src changes) pendingScript.onreadystatechange = null; // can't just appendChild, old IE bug if element isn't closed firstScript.parentNode.insertBefore(pendingScript, firstScript); } console.log("scripts should be loaded now"); } // loop through our script urls while (src = scripts.shift()) { if ('async' in firstScript) { // modern browsers script = document.createElement('script'); script.src = src; script.async = false; document.body.appendChild(script); } else if (firstScript.readyState) { // IE<10 create="" a="" script="" and="" add="" it="" to="" our="" todo="" pile="" pendingscripts.push(script);="" listen="" for="" state="" changes="" script.onreadystatechange="stateChange;" must="" set="" src="" after="" adding="" onreadystatechange="" listener="" else="" we’ll="" miss="" the="" loaded="" event="" cached="" scripts="" script.src="src;" }="" {="" fall="" back="" defer document.write(''); } } } catch (error) { alert(error); }