This article was originally a Medium post I wrote for the now defunct Maya Agency

Some History

I started making websites a long time ago. I remember getting table layouts to work on Internet Explorer 5 for Mac. I had to debug CSS before Firebug was a thing.

I’ve seen things you people wouldn’t believe.

A lot has changed since then. What started as a simple way to link together static text documents has turned into a complex, dynamic multi-media platform. You can talk to people in real time, even with video like it’s Back to the Future Part II. You can do things in 3D like play games or sculpt. You can create imaginary money and spend it on things you probably shouldn’t. You can do all sorts of things, it’s nuts. The web is everywhere. You’ve probably even used it yourself.

If something dynamic happens on a webpage (say you click a button and a new thing appears on the page) it’s probably due to the dark and twisted magic of JavaScript, a throughly thought-out language created in 10 days by one man in 1995. At that point in time, web pages were pretty basic. You had titles, links, maybe some images… The CSS 1 spec wasn’t completed until 1996. The simplicity of the web at this time allowed a lot of people to teach themselves how to use it. I was one of those people. You could view the source of a page and see exactly how it was made. You could copy, paste and make something of your own. It was great. Ugly, but great. Really ugly.

But as the web became more popular people wanted to do more complicated things. They wanted things to move, to be interactive and preferably to not reload the page every time. Web 2.0 was born.

Web 2.0

Web 2.0 has come to be technically defined by waving your hands around and saying something about interactivity. In reality it was a wave of new websites using technologies and techniques that allowed for more interaction with users. Previously you would have to create your own X-Files fan site to air your views on the Illuminati. Now you could register with LiveJournal and blog about it instead. What a time to be alive.

With this interactivity came the need for more advanced JavaScript and, man, coding stuff is hard, you know? Especially when it’s 2005 and none of the browsers can agree on things. Who can remember all of those browser implementations, let alone the ways to check which one to use. Can’t it just be easy?

Enter jQuery, stage left, to rapturous applause.

jQuery

jQuery is a JavaScript library that provides some useful features and hides some incompatibilities between different browsers’ JavaScript implementations. The main draw of jQuery is that it is easier to understand and easier to write than plain JavaScript.

Simplicity

A large part of this simplicity comes from the Sizzle selector engine, which is instantly familiar to anyone who has used CSS.

We’ll need to get a bit technical for this but I’ll try and keep it light. In CSS you can select elements on the page by their name (e.g. div), their id (e.g. #myId), their class (e.g. .my-class) etc. Sizzle took this way of selecting elements and applied it to JavaScript. So now instead of using a function to find an element, then filtering through it’s child elements, etc. you could perform the whole search with one carefully constructed string.

document.getElementById(‘myWrapper’).getElementsByClass(‘item’);

…becomes…

$('#myWrapper .item')

Cross-browser Compatibility

Another benefit of jQuery was the ease of supporting multiple browsers. For example, to make a button do some stuff you might want to attach adoStuff function that is called when the button is clicked.

In plain JavaScript you would need to check which way the browser uses to add events and then use the appropriate way. E.g.

var button = document.getElementById('myButton');if (button.addEventListener) {
  button.addEventListener("click", doStuff, false );
} else {
  button.attachEvent( "onclick", doStuff);
}

With jQuery this becomes a lot more straight forward. You just tell it what you want to do and it chooses how to do it.

$('#myButton).click(doStuff);

These days these compatibility issues are less of a problem (the above is only really relevant if you support Internet Explorer 10 or below) but at the time that jQuery was first released, this was a big deal.

The click method in the example above is just one of the methods that jQuery provides. And there are a lot of them. It’ll do AJAX calls for you. It’ll do animations. It’ll let you change the CSS. And all of that in only 87KB (v3.3.1, latest version at time of writing). What’s that you say? That’s not enough? You want it to do more? Well not to worry, it’s 2010 and everything’s a jQuery plugin now! You want a carousel, there’s a jQuery plugin for that. You want fixed images to appear as you scroll? I made a jQuery plugin that does that! (I haven’t touched it in 4 years. Maybe don’t use it.) You want a jQuery plugin that makes fart noises as you scroll down the page? Well guess what. Everything is a jQuery plugin.

jQuery became so popular that people confused jQuery and JavaScript, jQuery got listed as a language (when really it’s just a piece of JavaScript), and almost every answer on StackOverflow (the programmer’s question and answer site) suggested using jQuery, whether or not that was a good idea.

So what’s the problem? jQuery became fantastically popular due to its ease of use but, ease of use does not necessarily result in a great end result or, crucially, ease of maintenance. What jQuery doesn’t provide or enforce is any kind of structure. It is easy to start making a website using jQuery. It’s easy to add a couple of new features to a site. And then a few more. And a few more. Now at this point, it’s probably not so easy to add more. And if you want to change something you’ve done…can we just rebuild it?

And while you can be careful about what you do when (maybe by using DOM-based Routing or by splitting your code into separate files and loading what you need, etc. etc.) you still probably have classes everywhere and your jQuery is still probably tied to your DOM structure. There are ways to limit this but unless you (and everyone on your team) are really careful, you’re gonna end up with some kind of spaghetti code that can’t be untangled.

It’s unmaintainable.

[Exit jQuery, stage right, pursued by a bear.]

JavaScript Again (but different this time)

So it’s 2018 and everyone’s learning vanilla JavaScript. It’s the hot new “framework”. But things are better nowadays. With better support for new versions of ECMAScript (the spec that JavaScript follows). Internet Explorer 6 has essentially gone. Even Internet Explorer 8 and 9 have pretty much gone. The browsers that remain, whilst still not quite on the same page, are, generally speaking, for the most part, at least reading the same book. These days, instead of listing which jQuery plugins are a must-have, people are writing articles with title like You Might Not Need jQuery, (now more than ever) You Might Not Need jQuery, You Don’t Need jQuery and You Truly Don’t Need jQuery.

“So, wait”, you ask, “now we just write everything from scratch?”

Vue et al.

I’m going to talk about Vue.js for a minute here and I’m sure some people will say “but React has…” or “actually I think that Angular…”. So let me just say that they’re probably right and that I think the similarities between Vue, React and Angular are greater than their differences and all three are powerful tools. Ok? Ok.

The benefit of using Vue (or whatever) is the ability to create easily reusable chunks of code, components, that are self contained. This is the end goal of a large part of programming. You want to make something once and then just use it anywhere. It’s the dream. Now your template and the related code can be stored together even in the same exact file. You can even bundle your styles in there, too. This can feel pretty wrong at first.

In many ways programming for the web has come full circle and we are now able to do things in ways that were previously frowned upon, sometimes because the tools available to us enable us to avoid what would be downsides (e.g. HTTP2 allows us to transfer multiple files rather than bundling everything together into a single file) but sometimes because after a few decades of testing in more and more complicated projects, different methodologies have been agreed on.

Often the phrase “separation of concerns” is used and people put the separate technologies (JS, CSS, etc) in separate folders. But unpicking which part of, say, an html template fits which part of a JavaScript file can be tricky, even if you try to keep things organised because the functionality that you’re concerned about has been separated — the component you’ve made isn’t a component, it’s just a bunch of code scattered here and there.

While it’s still possible to mess this sort of thing up with Vue — everything still ends up as HTML, CSS and JS on the page so there’s lots of new and interesting ways you can go wrong — it’s a lot easier to keep things organised, reduce cognitive load and keep things maintainable. Everything Is Perfect Now and Nothing Is Wrong

Right? Well…almost. Learning JavaScript in 2018 can be daunting. There are lots of new, exciting technologies to learn. But on the other hand there is a lot to keep track of. Browsers have come on leaps and bounds, so you can often just use native JavaScript rather than relying on libraries like jQuery to fill in the gaps. But on the other hand you’ll probably still want to use something (like Babel) to make your code work on older browsers. But the other other hand those tools actually exist these days. The limits of what you can do in a browser are always being challenged and expanded. But on the other hand I now need to learn the Navier-Stokes equations for fluid dynamics just to make a cool header. Maybe things are getting out of hand, maybe they’re just getting interesting. Either way the web is a complex, evolving world with increasingly complex tech and anything that can simplify working with it is gratefully accepted into my tool-set.