Why are frontend web development technologies so broken?

If you have worked in frontend web development lately, you probably have realised how messy the whole thing is. From languages that compile on top of other languages to the ridiculous amount of frameworks that are published every day. In fact, you are probably already struggling to keep up; but trust me. you are not alone. Let’s take a look at what is going on and how we got here in the first place.

The Palaeolithic Era

Microsoft was one of the first pioneers of what we know as the Internet. Not of the infrastructure per se, but of the tools we use to browse the Internet. Internet Explorer was one of the first browsers to hit the market embedded to the bones of Windows 95. Its engine was developed by NCSA (US State Company) which Microsoft licensed from Spyglass Inc. There weren’t many standards back then, and everyone interpreted the internet as they wanted, but since Microsoft had such a massive market share, IE became the de-facto browser to consume the internet.

From IE1 to IE7, everything was a complete mess. Every version different to the previous. Websites rendered differently from one version to the other. It was so chaotic that Microsoft incorporated a “Compatibility Mode” button in their IE so you could “barely” browse the Internet decently. Everyone and their mother knew IE was broken, and other companies started to take the matter into their own hands.

Enter Mozilla and standard compliant browsers

Firefox tried to set things right, and it did. Mozilla’s browser was the most standard compliant browser you could get at the time. It supported modern technologies such as SVG and canvas. It was so good that it started to gain market share, leaving IE behind. Chrome was released by Google and there started the era of the modern web. But not so fast…

What I just outlined before in a few paragraphs, happened from 1995 to 2005. 10 years of the Internet, hampered by IE and its broken rendering engine. But hey, in 2005 Internet was already everywhere. So what could companies such as Google and Mozilla do about this? Well, use the technologies that were already out there and improve upon them.

HTML

The Hyper-text Markup Language was born with the Internet. You can’t say the “Internet” without thinking of HTML, and if you do, you are not a developer (see what I did there?). This language is very basic and it allows you to graphically add and group the things you see on a website. There are 5 versions of HTML, being the newest one supported down to IE9 (not all features though). The biggest feature of HTML5 is the “canvas”, which allows developers to draw cool things on a “canvas” by using JavaScript.

During the history of the Internet, HTML has lost a few tags (introduced orignally by IE), added new ones, but its core hasn’t changed much. You could say it was a well-thought technology from the very beginning and it remains true to its roots.

CSS

The Cascading Style Sheets were invented in 1996, and let me tell you something, since then, it hasn’t changed one bit. The idea behind CSS, is to allow developers to “style” that HTML and make it look better, fancier, prettier. It doesn’t allow any nesting, logic, variables, no, nothing like that. Instead, it allows to write plain boring rules that you apply to each tag so they look different. When you’re done, you end up with big files, hard to read and painful to maintain.

I exaggerated when I said it hasn’t changed one bit. It has changed of course. The W3C has included new rules, new properties, animation support, 3D transforms, and many other perks. But its core, its plain one-level-rule structure is the same crippled language that we got 18 years ago.

Due to these limitations, come the massive array of tools that you’ve probably already heard of: Compass, SASS, LESS, CSS fonts, CSS frameworks, etc. They all try to fix what’s broken with CSS and try to overcome its limitations to allow developers to write more intelligent and legible code.

SASS and LESS are both pre-processors in which you write CSS-on-steroids code (with variables, nesting, classes, etc) and then compiles into basic CSS that the browser can interpret. This way you don’t have to worry about that ugly CSS, you only worry about keeping your SASS files clean, readable and optimised. There is also Compass, which is a framework that sits on top of SASS, which also sits on top of Ruby, which compiles into CSS (are you getting it now?). But wait, Ruby is slow, hence SASS takes a few seconds to compile, so there comes LIBSASS, a Node based version of SASS (faster), which doesn’t sit on Ruby, but still compiles into CSS.

Oh but wait again, there are also web development frameworks, such as Bootstrap and Foundation, which are designed to alleviate the pain of building a website, which in all truth, are just trying to solve how broken and outdated CSS is: the grid problem.

You see, in web development, everything is a square, so you would think, CSS should allow you to organise and arrange those squares easily. Nope, it doesn’t. CSS cringe worthy rules, don’t allow any complex stuff, so you have to resort to hacks on top of other hacks that are already well known by the community and put together in a framework (Bootstrap, Foundation, etc). This way, you don’t have to waste time memorising them all, instead, you memorise all the framework classes and rules, that will most likely change in the next framework revision.

Ideally, you would use all of these tools with Grunt/Gulp, which are task automation tools for web development. Which if you ask me, we wouldn’t need those if frontend technologies were half decent. “Wait, let’s go back for a second there: are you saying that Grunt sits on top of NodeJS which is a backend language, which is based on JavaScript, which runs SASS, which sits on top of Ruby and compiles into CSS”. Yes, that is correct.

But this isn’t the tip of the iceberg just yet. Oh no, there is more to go.

JavaScript

You have had it easy if you haven’t developed on modern JavaScript. JavaScript (JS) was written by Brendan Eich in just a few weeks when he worked for Netscape. Since Netscape was the direct competitor of IE back when the internet was in its infancy, Netscape pushed JS forward by promoting how easy to learn it was. Then Microsoft adopted it for IE and in 1996 it was standardised as ECMASCript. Since then, JS has evolved slowly, mostly because its new features are not widely supported by all browsers. For example, ECMAScript 6, which is to be released in mid-2015, is not even 50% supported by Chrome or Firefox (at the time of writing). So if you want to write complex stuff with JS, you will need frameworks and other languages that compile into JS.

jQuery was one of the first to enter the JS framework market (along with Mootools, Prototype, and others). It allows you to write simple rules that are then rendered by the jQuery engine and translated into vanilla JS (pure JavaScript). jQuery is so popular that is still used nowadays. However, more complex frameworks have joined the party such as Angular, Embed, Knockout, React, Backbone and I could keep going. They are called MV* frameworks, trying to emulate a backend development coding practice known as MVC (Model-View-Controller). There are so many of these frameworks, that there is a dedicated website trying to keep track of all of them.

These MV* are not only changing constantly, they are not easy to learn. Their learning curve will force you to forget all you know about other frameworks and work in an opinionated environment of what the developers think is right. So, good luck trying to learn them all. Angular, the most famous of them all, which was acquired by Google (no, Angular wasn’t invented by Google) changes so much in every major version that it has raised some concerns in the community.

But, since JS syntax is sometimes, not enough, there is now an array of scripting languages that compile into JavaScript. For example, TypeScript, CoffeeScript, and Dart all compile to JS. So you write your code in another variant of JS which compiles into JS. In fact, Angular 2.0, will be based on TypeScript, which is a Microsoft Open Source technology.

Dart, a scripting language maintained by Google, was initially intended to replace JavaScript. But JS adoption is so wide, that Google has since abandoned that idea and Dart will now compile into JS. So we are now stuck with languages that sit on top of other languages that then compile into JS. This is Inception all over again.

Browsers

We have already talked about all the technologies and where they are, but those technologies need a browser to run. The only problem developers have in this area could be resumed in two letters: IE. When IE was conceived, there was no way to update it but to wait for a new Windows version or Service Pack, this made IE lag in time badly, never catching up with modern web technologies. IE9, 10 and 11 are the only versions of this ancient browser that do barely play along with respect to the standards. But wait a second, IE7 and IE8 come integrated into Windows XP by default, which is still widely used by a lot of corporations and computers around the world.

This IE problem is hindering the ability of the web to move forward. Developers and companies still need to provide support for these ancient browsers, which cost a lot of money, hampers web progression and doesn’t allow the technologies to move as fast as they need. Microsoft is in such deep sh*t with its browser, that they have now ditched the IE brand to create a new browser from scratch, that will supposedly be standard compliant and be updated regularly (I’ll believe it when I see it). To date, IE11, the latest IE version is not updated as often as it should. In fact, why do we still have people running IE9 and IE10? shouldn’t those be already running IE11? I invite you to answer that.

By now, you should have probably realised how broken this whole thing is; and there is no solution in sight. JavaScript and CSS are here to stay and they move very slow. As long as we have browsers lagging behind using obsolete rendering engines, the frontend web development industry will remain as messy as it is now. So in order to make things bearable, I have put together a small list of tips/questions that could be of use to any frontend developer out there. These are by no means rules to follow, just questions I ask myself when I decide to invest time in a new technology.

• Do some research before you invest time learning a new technology. Sometimes it will get abandoned in a few months and all that effort will go to waste.
• Is this technology backed up by the community or just one company?
• From the array of possible technologies, does it have the biggest community?
• Do I really need to use this technology for this project? is it worth the time investment? It might be overkill
• Is this technology updated at least once every 3 months?
• Are new versions backwards compatible with older versions?
• Can people in your team learn this new technology fast enough?
• Does it degrade gracefully on older browsers?
• What about mobile support?

In the end, use what makes you and your team comfortable, while also providing an excellent experience to the user. This is the holy grail of it all. If you chose a technology or framework that ends up dead in 3 months or is too time consuming to learn, you will end up with a frustrated team not able to deliver. “Move fast and break things”.