The Golden Era of Front-end Web Development

Grafika -frontend

Inspired by all the innovative techniques of today’s front-end craft, I wanted to do a simple summarization of its’ evolution for a long time. The recent W3C’s announcement about the HTML5 standard being complete was a great impulse to finally do so. In this article I will highlight all the major differences from the web developer’s, as well as end-user’s point of view.

A little bit of history

The first fact which might surprise some of you: the creator of both World Wide Web and the first web browser is still among livings. After all it didn’t happen that much time ago (1990), despite the impression of WWW being present in our lives since always. The mentioned Man’s name is Sir Timothy Berners-Lee. Along with his colleague Marc Andreessen, they started working on the origins of web standards in 1993 concerning elements like the <img> tag or mime types. There was not a lot work to do for a front-end developer that days (if this job existed, they would probably starve). Therefore I am not going to compare the present with the 1990s, let’s step to the turn of the millennium.

The browsers wars

I remember how back in 2007ish, half of the front-end development time expenditure was intended for adjusting look & feel to major browsers. Most of them, like Mozilla Firefox, Safari or Chrome (published a little later) differed a little bit, but handling this difference was way easier than adapting to Internet Explorer with his always late, always peculiar way of feature implementation. And this was the case, since IE6 had the lion share of web browsers market, as shown on the following figure.

Web browsers market share in 2009

Web browsers market share in 2009. Source: netmarketshare.com

The problems included: different box model interpretation, strange boxes alignment, occasional weird margin size interpretation, floating elements position, percentage dimensions, missing some basic properties, no out-of-the-box transparency handling etc. Phew… Some developers even attempted to create formulas for evaluating profitability of developing for IE6. As Lea Verou, the creator of one of the best present sites about web development, stated in 2011:

“Making something that worked in modern browsers took me half an hour, then an hour to make it work in IE 8, and then three(!) more hours to get it to work in IE 7. Who knows how much longer it would’ve taken if I had to support IE 6, too!”
Source: smashingmagazine.com

She even charged extra for implementing support for the most bothersome versions. I hope this fully illustrates the past problem of browsers compatibility.

There were some well-worn methods to tackle the browser compliance problem, like including conditional stylesheets, which of course led to additional work:

<!--[if lt IE 7]>
<link rel="stylesheet" href="ie6_support.css" type="text/css"/>
<![endif]-->

Others were to imitate the behaviour of newer versions with JavaScript by conditionally including for example Dean Edwards’ IE7.js script.

The present

After over 5 years of web browsers development the situation looks compelling. All major browsers engines’ basic feature support is exhaustive: WebKit (Safari, Google Chrome and Android browser), Trident (Internet Explorer and Windows Phone), Gecko (Mozilla Firefox), Blink (Opera and Chromium) – all of them interpret basic layouts the same way. What is more, according to ADI Report (see the next figure) the right browsers are starting to dominate on the market. Even Internet Explorer’s fruitful efforts to comply to the standards have been noticed by users and resulted in the overall plummeting line starting to take a horizontal trend.

Browsers market share over the years

Browsers market share over the years. Source: cmo.com

One more imposing fact to note is that all the mentioned browsers had implemented some HTML5 features long before it got official. Already one year ago we could find support for majority of them in most of browsers (for details see the following figure). Check which HTML5 features does your browser support.

Collective HTML5 features browser support

Collective HTML5 features browser support. Source: caniuse.com

What about the older browsers support? Well, we still care about them:

<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
<script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
<![endif]-->

There are many so called shivs and polyfills, which are JavaScript scripts creating a bridge between new features and older browsers. We use them according to the needs of the particular projects.

The Tools

A couple of years ago, a front-end developer had a quite big choice of tools to pick from. The problem was that the tools (apart of a simple text editor and hand crafting all the code) didn’t help in creating very good products. First thing that comes to mind is a WYSIWYG software. This terrifying creation brought goosebumps to every professional developer who took a look inside of the generated code. Really bad idea to use it. There was also the Flash technology, which provided us tools for producing very interactive (as for that times) and all that flickering-glimmering-bouncing experience. This was good, but came along with some problems: first and foremost, SEO within Flash websites was extremely poor. Search engines simply couldn’t read their’s content. Secondly, it required additional browser plugins and nobody likes excessive software to update, maintain and take up your computer’s processing power. Then, there was Java and .NET. These where good solutions, surviving up to today. However they require special hosting and additional browser plugins and are not pure web technologies. Moreover, each change / bug fix in such application requires recompilation, which is a big drawback in maintenance and deployment context. I have a feeling that technologies like these, that where non-pure web technologies, were being chosen by developers because of lack of available professional tools for the pure ones. This state gradually changed to what we have today.

The present

The current front-end web development environment is nothing like in the past. The computers became faster, the browsers got more capable, the web transformed from a notice-board to a real business place and customers / companies see it. This has grown a new demand: reliable, functional, fast web experience. The mixture wouldn’t be possible to obtain without professional tools resembling those from the back-end or desktop side. And this is exactly what happened: internet is overflowing with useful open-source tools. The production flow can be fully automated, deprived of unnecessary redundancy and with error proneness reduced to minimum. For nearly each part of development process there is a choice for top quality tools. Just to list the basic ones included in our development stack:

What is this bunch capable of? You can install the whole project with one command line. You can change your CSS and immediately see the result in a browser without reloading. You can write CSS with variables, mixins and functions in object oriented manner, all that in elegant, importable portions of code. You are able to write many lines of JavaScript, debug it, test it for memory leaks and time-profile it. You can delegate the care for your code correctness to other code. You can use high-end browser built-in functionalities or provide fallback in case of detected lack of support. You can do it all asynchronously. You can write a complex, customized web form in just a few lines. You can develop in groups, simultaneously. This all makes front-end development the real-deal development. THIS is what makes people call such products: Web Applications.

Some more used by us things worth to mention, that are easily available now but were hard to get several years ago, are: text and box shadows, gradients, visual transformations, animations, custom fonts, vector and raster dynamic drawings, video and audio support, easy adaptation to certain devices. New HTML5 tags help the web documents in being more semantic (no DIV tags just for aligning, no icon or background images mixed with the content, text appearance tags got well-defined functions), reflecting just the substance of the page – the presentation layer is left for CSS. More sophisticated, available features include: Web Sockets for real-time applications, user Geolocation, offline functioning, local storage. And of course JavaScript. Tons of shiny ECMAScript standardized, powerful JavaScript to connect all the dots and satisfy the user with high functionality.

The Golden Era? Really?

The lofty term of Golden Era in the title implies that now is probably the best period in lifetime of web development ever. I admit to committing a misconception in here: the term applies to the part of timeline up to date, excluding the future. This is to say that each forthcoming chapter in web development will be better and better (I assume). My goal was to highlight the tremendous leap between the process of front-end development 10 years ago and today. I aimed to mark out that thanks to the innovative tools and the large-scale standardization, the production process is now so refined, that we, the developers, can almost fully focus on the delivered experience instead of methods or the process itself. The client’s, as well as end-user’s needs at last became the focal point of creating web solutions.

Looking to scale-out your
web application?

Hire Octivi!
  • LindaJFlynn
  • Mahomed

    Nice article. Personally what I think is missing, is the ability to have a WYSIWYG editor that produces compliant code 🙂 Particularly in terms of developing web applications (as opposed to pretty looking websites and blogs).

    If you have ever used Visual Studio to develop a desktop app, then you’ll know what I mean. You just create your form (surface area) and drag your text boxes, buttons etc. and when you run the application, that’s exactly where they appear and it’s the same on EVERY computer apart from screen resolution 🙂 Then you just write your code behind.

    Currently developing for the web requires several tools, stacks, languages, frameworks and then hand coding pretty much every element and position to then get the end result.