Around 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
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.
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 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.