Why are frontend web development technologies so broken?

W3C

If you’ve worked in front-end web development recently, you’ve probably realised how messy the whole thing has become. From languages that compile on top of other languages, to the ridiculous number of frameworks released every day, it’s overwhelming. In fact, you’re probably already struggling to keep up. But trust me, you’re not alone. Let’s take a look at what’s going on, and how we ended up here in the first place.

The Palaeolithic Era

Microsoft was one of the first pioneers of what we now know as the Internet. Not of the infrastructure itself, but of the tools we use to browse it. Internet Explorer was one of the first browsers to hit the market, deeply embedded into Windows 95. Its engine was originally developed by NCSA (a US state-funded organisation), and Microsoft licensed it from Spyglass Inc. There were not many standards at the time, and everyone interpreted the Internet in their own way. However, since Microsoft held such a massive market share, Internet Explorer became the de facto browser for accessing the web.

From IE1 to IE7, everything was a complete mess. Each version behaved differently from the last, and websites would render inconsistently across them. It was so chaotic that Microsoft introduced a “Compatibility Mode” button in Internet Explorer, just so users could barely browse the web properly. Everyone and their mother knew that IE was broken, and other companies began to take matters 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 standards-compliant option available at the time. It supported modern technologies such as SVG and canvas, and it was so good that it began gaining market share, leaving Internet Explorer behind. Then Google released Chrome, marking the beginning of the modern web. But not so fast…

What I outlined in the previous few paragraphs took place between 1995 and 2005. Ten years of the Internet, hampered by Internet Explorer and its broken rendering engine. But by 2005, the Internet was already everywhere. So, what could companies like Google and Mozilla do about it? The answer was to take the technologies that already existed and build on them.

HTML

The HyperText Markup Language was born with the Internet. You can’t say “Internet” without thinking of HTML. This language is very basic, and it allows you to visually structure and group the elements you see on a website. There are five versions of HTML, with the latest one supported as far back as Internet Explorer 9 (although not all features are fully supported). The biggest feature of HTML5 is the “canvas”, which lets developers draw cool things on a canvas using JavaScript.

Throughout the history of the Internet, HTML has lost a few tags (originally introduced by Internet Explorer), gained some new ones, but its core has not changed much. You could say it was a well-thought-out technology from the very beginning, and it has remained true to its roots.

CSS

Cascading Style Sheets were invented in 1996, and let me tell you, they haven’t changed much since then. The idea behind CSS is to allow developers to “style” HTML and make it look better, fancier, prettier. It doesn’t support nesting, logic or variables; nothing like that. Instead, you write plain, boring rules that apply to each tag to make them look different. When you’re done, you often end up with large files that are hard to read and painful to maintain.

I exaggerated when I said it hasn’t changed one bit. Of course, it has changed. The W3C has introduced new rules, properties, animation support, 3D transforms, and many other features. But at its core, its simple one-level rule structure remains the same limited language we had 18 years ago.

Because of these limitations, a massive array of tools have emerged that you’ve probably already heard of: Compass, SASS, LESS, CSS Fonts, CSS frameworks, and more. They all try to fix what’s broken with CSS and overcome its limitations, allowing developers to write smarter and more readable code.

SASS and LESS are both pre-processors where you write CSS-on-steroids code with variables, nesting, classes, and more which then compiles into basic CSS that the browser can understand. This way, you don’t have to worry about messy CSS; you only need to keep your SASS files clean, readable, and optimised. There’s also Compass, a framework that sits on top of SASS, which itself runs on Ruby and compiles into CSS (are you following so far?). But Ruby is slow, so SASS can take a few seconds to compile. That’s where LIBSASS comes in, a Node-based version of SASS that’s faster, doesn’t rely on Ruby, but still compiles into CSS.

nodejs-frontend

Oh, but wait, there are also web development frameworks such as Bootstrap and Foundation, designed to alleviate the pain of building a website. In truth, they are mostly trying to solve how broken and outdated CSS is, especially when it comes to the grid problem.

You see, in web development, everything is a square, so you’d think CSS should let you organise and arrange those squares easily. Nope, it doesn’t. CSS’s cringe-worthy rules don’t allow for anything complex, so you have to resort to hacks on top of other hacks that the community already knows well and bundles into frameworks like Bootstrap or Foundation. This way, you don’t have to waste time memorising all the hacks, instead, you memorise the framework’s classes and rules, which will most likely change with the next revision.

Ideally, you would use all of these tools with Webpack, Grunt or Gulp, which are task automation tools for web development. If you ask me, we wouldn’t need those if front-end technologies were half decent. Wait, let’s go back for a second: are you saying that Grunt sits on top of Node.js, which is a backend environment based on JavaScript, which runs SASS, which sits on top of Ruby and compiles into CSS? Yes, that is correct.

But this isn’t even the tip of the iceberg yet. Oh no, there’s still more to come.

JavaScript

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

jQuery was one of the first to enter the JavaScript framework market, alongside Mootools, Prototype, and others. It allows you to write simple rules that are processed by the jQuery engine and translated into vanilla JS (pure JavaScript). jQuery is so popular that it is still widely used today. However, more complex frameworks have since joined the party, such as Angular, Ember, Knockout, React, Backbone — and I could go on. These are known as MV* frameworks, which try to emulate a backend development pattern called MVC (Model-View-Controller). There are so many of these frameworks that there is even a dedicated website to keep track of them all.

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

But since JavaScript’s syntax is sometimes not enough, there is now a range of scripting languages that compile into JavaScript. For example, TypeScript, CoffeeScript, and Dart all compile to JS. This means you write your code in another variant of JavaScript, which then compiles into plain JS. In fact, Angular 2.0 will be based on TypeScript, which is an open source technology developed by Microsoft.

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

Browsers

We’ve already talked about the technologies and where they stand, but these technologies need a browser to run. The main problem developers face in this area can be summed up in two letters: IE. When Internet Explorer was first released, there was no way to update it except by waiting for a new version of Windows or a Service Pack. This caused IE to fall badly behind, never quite catching up with modern web technologies. IE9, 10, and 11 were the only versions of this ancient browser that barely played along with web standards. But wait a second, IE7 and IE8 come integrated with Windows XP by default, which is still widely used by many corporations and computers around the world.

the-ie8-comparison

This IE problem is holding back the web’s ability to move forward. Developers and companies still need to support these ancient browsers, which costs a lot of money, hampers progress, and prevents technologies from advancing as quickly as they should. Microsoft is in such deep trouble with its browser that they have now abandoned the IE brand to create a new browser from scratch, which is supposed to be standards-compliant and updated regularly (I’ll believe it when I see it). To date, IE11, the latest version, is not updated as often as it should be. In fact, why do we still have people running IE9 and IE10? Shouldn’t they already be using IE11? I invite you to answer that.

By now, you’ve probably realised how broken this whole thing is, and there is no solution in sight. JavaScript and CSS are here to stay, but they evolve very slowly. As long as browsers lag behind with obsolete rendering engines, the front-end web development industry will remain as messy as it is now. To make things more bearable, I’ve put together a small list of tips and questions that could be useful to any front-end developer out there. These are by no means rules to follow, just questions I ask myself when deciding whether to invest time in a new technology.

  • Do some research before you invest time learning a new technology. It might 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 largest community?
  • Do I really need to use this technology for this project? is it worth the time investment?
  • 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 customer experience. This is the holy grail of it all. If you choose a technology or framework that ends up dead in three months or is too time-consuming to learn, you will have a frustrated team unable to deliver. So, remember: move fast and break things.