Let's embrace modern browsers in 2019

Anyone who's been working with frontend web development should know the pain of browser support. I never understood why people stick with older browsers and I might never find the answer. I'm sure many fellow developers have the same confusion. Apart from corporate machines, there is very little reason to stay on older browser versions. Modern browsers are both more secure and faster! Need more reason? You get all that for free and there are plenty to choose from, what more can we ask for? For us, developers, nothing about this makes any sense.

It is frustrating, but there is nothing we can do about it. Because our manager or Product Owner told us that we need to support "that version of x browser" (normally IE) because that is what the business wants. So here we go again, spending 20% of our effort developing a new feature then spend the other 80% making it work on browsers which even their own creator decided to drop support for a few years back.


I know plenty of people have been pushing for this online for years, but this year is better than any to actually make a difference (how little it may be).

Better developer experience

Let's get the bias out of the way first. Yes, I'm a developer, of course, I want to develop against fewer browsers and have an easy life. But how many people actually enjoy spending hours, days or even weeks debugging an issue on older browsers that may affect 0.1% of the customer?

Even though this is a valid point, maybe don't go to your boss with the only explanation. Let's look at a few more reasons that don't sound like a selfish ass.

Build a better product

I believe in full-stack development, so plenty of people have tried to convince me why I should focus on one thing. When I go on explaining my reasons, they always come back with the following phrase. I think it works much better here.

Jack of all trades, master of none

I have worked on projects where they wanted to support as many browsers as possible, sometimes up to 30 browsers & devices combinations. It is easy to make that decision to say yes we will support everything. Let's put development and maintenance effort aside, and just imagine the amount of testing required to ensure the quality of those browsers/devices.

I hear there are plenty of automation tools which can make it very easy to do these kinds of tests. There are, and I have used quite a few in the past. They are better than nothing, but they are not perfect either. Not only are UI tests a lot slower to run on the cloud, but they also only support a core list of browsers/devices.

Before any production releases, some teams prefer to sanity check everything. Do you know how long it would take to manually sanity check 30 browser/device combinations?

Spreading the team's effort this thin, and causing a lot of frustration in a lot of situations is plain unnecessary. If the business makes 50% of the revenue on IE10, then I say go ahead and support it. But sometimes it is worth taking a look at the big picture. Spending 10% or even 20% of the resource to support 1% of the customer is not a rare thing business decides to do. If this is happening in your team, it is worth bringing this up and at least discuss it.

On the other side, now imagine all you have to do is support 5 browsers (latest versions). The team would have so much more focus to build a better product. Instead of having a backlog full of bugs on different browsers, and creating a half-baked product. Wouldn't it feel better to see a backlog of features and no bugs?

Honestly it is time

Most applications written nowadays are still converted and polyfill to ES5 standard. Do you know when ES5 spec was released? 2009! That is 10 years ago!

Okay, I need to calm down. I'm not saying today onwards everyone should be publishing app written in ES2018, that is a tad extreme. But is ES2015 (ES6) really that much to ask? Don't trust me when I say it is fine to write and publish apps in ES2015? Let's look at the facts!

Check out this awesome tool created by kangax. It shows a full breakdown of the supported of different browsers. Let's assume that our intended user is using the modern browsers, the lowest support % is Edge at 96%.

Yes, we are not at 100% yet. You really want to use those missing features, then release your code in ES6 and polyfill that 4 % of ES2015 features. I personally think it is just easier not to use those features, but hey, the choice is yours.

Handle old browser visits

What if a user on an older browser comes to my site? Would they just see a broken page? Surely that can't be good, there's a brand name to live up to! Good, let's see what we can do here.

There is this site called outdatedbrowser.com. Go and take a look, it is a beautiful site. This is free, responsive and available in many languages. It only appears when people browse your site on the older browser and tell the user that they should consider download one of the listed modern browsers to continue using your site.

browser modern

With this as a fallback, your modern browser users will experience a faster site and the older browser users will be greeted with a nice looking fallback site as well. I think the first step towards a more modern web is to have as many sites showing this as possible. When a user keeps seeing this page, they will understand how fast behind they are and will want to download one of those nice looking modern browsers. If not, then sooner or later they will be forced to if they want to see the content on these sites.

If we keep tailoring for the small percentage of people, we might be still using ES5 after another 10 years. For some people, some tough love is needed. But remember, by upgrading they are also more secure and better protected online as well.

Fight for a better web

I also think the first thing any developer should say after seeing the list of supported browsers (and maybe devices) is "can I see the analytics of the site which decided this list"? Yes, analytics is key. It might not be 100% accurate, but it should be the first thing to look at when considering to support older browsers. As developers, people should be coming to us and try to convince us if a browser is needed e.g. over 10,000 users use it to visit our site. It shouldn't be us convincing the business. But since we don't live in a perfect world, at least ask the above question. It is not just making your own life easier, it is also saving the business tones of resources which we will get to later.

After you've seen the latest analytics numbers, the next step to make some the tough decisions or try to convince some difficult people in the business. Explain to them the different benefits and fallbacks that can be put in place to handle everything gracefully even if someone's grandparents load the site on IE6. Yes, the outdatedbrowser.com tool works on IE6! How many other sites out there works on browsers that old? With this tool, you are technically improving the customer experience for people with old browsers (say there is someone crazy enough to be using IE6 visiting your site).

A faster web

We all know small JavaScript bundles are good, it means the site will load faster on low-end devices. ES2015 lets us write much better code to achieve the same things in ES5, there are also plenty of new features of ES2015 which doesn't exist in ES5 which is why we add in those huge polyfills.

But how much small is ES2015 bundle compared to ES5?

This is a tricky question to answer because it honestly depends. But just as an example, let's take a look at the source code of two implementations of todomvc. One is written in ES2015 and the other in ES5.

Things to note:

  • It was not implemented by the same person, so the code quality may vary
  • This is just for fun, don't quote me based on this example
  • Try doing a comparison on the project you are working on, it will be much more relevant than this example

I combined all the source code of the ES2015 vanilla and then minified it, the uncompressed size is 12,074 bytes, gzip compressed size is 3,190 bytes.

I then did the same for ES5 vanilla and the uncompressed size is 16,085 bytes, gzip compressed size is 4,104 bytes.

todomvc bundle comparison

The actual difference here is pretty tiny especially after gzip, but the percentage difference (ES2015 is about 75% smaller than ES5) is nice to see. It is worth remembering this is only several hundred lines of code. In a big problem, 25% of bundle size is quite considerable. Especially considering todomvc doesn't use any polyfills, if you use a few big polyfills then that's going to add a lot more to the bundle size.

We are professionals

If you are walking past a stranger and see their bag is open, wouldn't you tap them on the shoulder and tell them? You are all nice people, of course, you would. Now, you see your company wasting time and effort on some poor decisions made a while back, the solution is simple and makes everyone's life easier. Should you not raise your hand and make everyone aware of the issue?

Often the people making the decisions doesn't know they are wasting resources on things that don't matter. As professionals, we should stand our ground and say what we think is right. Maybe do it in a polite and assertive way, so people don't think you are crazy or you are attacking them personally. I'm sure most bosses would love to cut 20% cost and give up 1% of the customers, it is simple maths. But remember we are not "giving up" on those customers either, we have discussed fallbacks already which will help them to "find their way".

As professionals, we should and I'm sure most of us want to create the best product. It is also a much better ego boost when people say "oh I love your product!" compared to "can you fix x, y and z issues on your site? I keep getting them".

Final words

I hope the above is enough to convince you that this is something that is worth doing, not just to make our developers' lives easier. It will also benefit our companies and our customers. But if you can't get this point across to anyone at your workplace no matter how hard you tried. Then at least do this on your personal sites :)

I hope 2019 is the year ES2015 will become the default standard when creating new projects, and that ES5 polyfill becomes a thing in the past!