In the not so distant past, the common browsers were Microsoft Internet Explorer (IE) and Netscape Navigator, and web developers usually had an assortment of browsers installed on their machines, together with multiple remote or virtual machines (as it was impossible to install different versions of IE).
And if that wasn’t enough, the competitive environment led to vendors releasing new versions frequently. This meant that companies with websites available to all (or most) users had to support as many browsers and versions at they could. Moreover, even though the W3C had already been founded at that time, browser vendors did not follow its recommendations, and incompatible HTML implementations were still published. All of this made cross-browser compatibility a burdensome task that involved familiarity with proprietary HTML tags such as IE’s <marquee> and Netscape Navigator’s <blink>, different rendering engines, and encoding support for foreign languages.
Eventually, Microsoft achieved market domination and won the browser war by distributing IE as part of every Windows installation. With a 95% market share, many companies gave up on supporting Netscape completely and embraced IE’s proprietary technologies, such as HTC, XML Islanders, ActiveX objects, and many more, making their sites more dynamic and interactive.
Desktop applications still offered better user experience than Web applications, and the goal was to make the Web applications as intuitive and beautiful as the traditional Desktop ones (known as Rich Internet Applications (RIA)). Due to the limitations of the traditional mix of HTML, CSS, and JS, it was difficult to achieve these goals and a lot of low-level coding was required (not to mention the headaches caused by browser incompatibility). So new technologies were born, each with its pros and cons, but the most widely used were Java Applets, Adobe Flash/Flex, and Microsoft Silverlight. This meant that in order to run applications implemented using these technologies, users had to install browser plugins.
In development terms, things became easier, as developers didn’t have to concern themselves with what browser a user used as the outcome would usually be the same on all browsers as long as the proprietary plugin was installed (which is one of the biggest disadvantages of this approach, together with the potential security vulnerabilities).
When modern browsers embraced the HTML5 specification (not necessarily with all of its features), RIA development changed dramatically. New JS frameworks such as Ember.js and AngularJS were introduced and finally gave front-end developers the tools to focus on implementing application logic by adopting the MVC concept, for example, regardless of how a DIV object would be presented on a specific browser. Front-end developers no longer had to consider what device their application ran on as its appearance could be automatically adjusted to the screen resolution using frameworks such as bootstrap.
After years of having to maintain the client-side code − which initially was mixed with server-side script engine technologies such as ASP and JSP making things unmanageable as the business layer was coupled with the presentation layer − frontend developers finally had access to mature frameworks.
They could finally manage their third-party packages by using package managers such as Bower, automate their tasks with GRUNT, and scaffold everything with yeoman. And as for unit tests, finally they were done in the presentation layer as well.
The days of “This site supports Internet Explorer 5.5 and above” have truly passed. Today, when web applications are available on desktops, laptops, cellular devices, tablets and TV, front-end developers can finally deliver outstanding applications rather than relying on window.navigator.userAgent.
About the Author
Yossi Shirizli is the Director of R&D at Correlsense. He has over 16 years’ of hands-on managerial experience in the software development field and is responsible for all R&D activities and leads a group of three teams.