ISE Blog

Supporting Multiple Browsers in Web Applications

Webpack and BableAround this time last year, I was developing a website for my wedding. The primary function of this website was to have guests RSVP on the site, so we could save a little money on postage and letterhead. I performed a thorough set of testing scenarios on Chrome, Firefox, and Edge, even employing the browsers’ mobile simulators. Everything seemed to work fine, so we sent out the invites and waited for RSVPs.

About a week afterwards, I got a text from my aunt; she couldn’t submit her RSVP! Why didn’t I catch this flaw in my testing?

Turns out that I had used an ES5 Array method, .forEach(), that was unsupported in IE 8 (Internet Explorer 8) and below. I had thought that my users would all have modern web browsers, but I quickly found out that the older, less tech savvy users in my user base could potentially be using IE 8 or lower.

So how might a web developer solve this problem of having an unsupported method in the code base that may prevent the site from functioning on certain browsers? In the following, I present four ways of supporting the diverse set of browsers your user base uses.

Tell Users to Switch Browsers

The easiest solution would simply be to shrug our shoulders and tell users to use a different browser, probably one that we’ve executed our tests on. Due to the diversity in browser implementation in the late 1990s, this was actually a common practice. If a website was developed for Internet Explorer and was being viewed in Netscape Navigator, developers would tell the user that the site was, “Best viewed in Internet Explorer,” or vice-versa.

This practice, however, is no longer common as technology has improved. For one, it is much more difficult now to detect which browser a user is running on due to the development of browser spoofing techniques. The most reliable method is writing some custom function employing duck-typing to determine the type of browser, but that can prove to be more difficult than it sounds.

Another reason this has become less common is that users have become more demanding. According to an article from Time magazine, the majority of users spend 15 seconds or less on a webpage. If you are looking to engage users, you do not want to tell them to go download another web browser to use your product – they are more likely to browse away from your site. If you are supporting an enterprise web application, you want to make your customers have as smooth an experience as possible. Telling them that they need to change browsers may be enough for those customers to turn to a competitor, depending on the product.

Follow the Lowest Common ECMA Specification

Another way to support multiple browsers is to follow the lowest common ECMA specification (i.e. JavaScript version) that all the browsers in your list support (if you don’t know what ECMA specs are you can read more about them in this blog post). Generally, browsers will support old methods from older ECMA specs for a long time, so older sites will still run on their platform. This means you are generally safe if you pick the lowest common version from the browsers in your supported list.

However, this has some consequences. For one, it is expected that you would be severely limited in the number of dependent projects or frameworks you would be able to leverage to build your application. Most older libraries that would support old specifications are out of date or unmaintained – if there is a bug, you would have to find a workaround yourself. You also could shortchange yourself out of all the new features in the new ECMA Specs, like arrow functions, await and async, and the spread operator, to name a few. 

Polyfills

A third way to support multiple browsers is to implement polyfills. Polyfills are alternative implementations of a now standard function that can be included in source code to implement methods that are missing in a previous version. For example, in my case I was able to use a polyfill to support the .forEach() method that was missing in my code base (see here for the code). The use of polyfills has become a fairly standard practice and widely adopted solution to solving the problem of supporting older JavaScript versions.

While polyfills are preferable, they do come at the cost of adding additional source code. This can cause some bloat to the files you serve to the browser, potentially having negative affects on performance.

Use Transpilation Tools

The final approach to supporting multiple browsers that I will touch on is using some modern transpilation tools. The tool suite that I have found the most success in using, and is one of the most widely used in the industry, is webpack and Babel. Webpack is a bundler for JavaScript modules; in this context, it behaves as an orchestrator for Babel. Babel advertises as a ‘JavaScript Compiler’ when really it transpiles ES6+ syntax into older syntax to be used in different browsers. I’m simplifying a little, but essentially you can gain multiple browser support by installing a few dependencies and defining some configuration values. Modern JavaScript frameworks, like React, have adopted this approach so that their tool can be used across browsers.

The cost associated with adopting these tools is that there is a learning curve as well as some configuration. However, I’ve found this to be the best solution due to the flexibility and ease of use, once you get used to them.

Conclusion

While it might be nice to tell your users to switch the tools they use, this is likely unfeasible, as is working in an antiquated JavaScript version. In my opinion, using modern packaging tools, polyfills, or some combination of the two is your best bet at keeping your customers happy while being able to take advantages of the niceties of ES6 and beyond. Hopefully you don’t end up like me and learn your lesson the hard way.


Check back for future posts on using JavaScript for web development. Have questions? Contact us or join in the conversation below! 

Jon Opdahl, Software Engineer

Jon Opdahl, Software Engineer

Jon Opdahl is a full-stack web developer and web technology practice lead at Innovative Software Engineering. He has been with ISE since June of 2017. Fascinated with JavaScript, he loves working with Node.js and front-end frameworks like React and Angular. He is passionate about designing meaningful software that engages users and drives business. Outside of work, he is an avid baseball and hockey fan and enjoys golfing and tennis, as well as spending time with his wife.

Jon Opdahl, Software Engineer

Latest posts by Jon Opdahl, Software Engineer (see all)

Supporting Multiple Browsers in Web Applications Oct 24, 2019

What is ECMA Script? Sep 19, 2019

ConFoo 2018: CSS-Grid Apr 04, 2018