Are you prepared for life after jQuery?

When jQuery was first introduced, it changed the world. It gave us all the ability to refer to elements on the page from JavaScript, like we could in CSS. Not only that, but it gave us an API for these elements that was miles ahead of what the browser had. We could hide them, add and remove classes, and even write our own plug-ins to do unprecedented things.

It also hid much of the complexity of dealing with that era of browsers from us. Through painstaking fixes, all of the various bugs that those browsers included were worked around, until you could be confident that if something was done with jQuery, it would work.

Before too long, jQuery became the vernacular of the internet. Scores of people learned it before they learned the DOM itself: it became an implied dependency in every library and tool out there. jQuery was ever-present.

But things have moved on since then. jQuery thrived in a time when browsers were broken and slow to change, but that itself is changing.

Since IE8, browsers have included the document.querySelector method, which gives us all jQuery's killer features right out of the box. IE9 gave us addEventListener, freeing us from onclick and onmouseover. In IE10, JavaScript programmers were granted the classList object, enabling us to add and remove classes without tricky string manipulation.

And this is without touching on all of the amazing things that CSS can do without any JavaScript at all. CSS is finally getting powerful enough to truly facilitate the separation of the JavaScript logic from its presentation. In modern browsers, classes can represent the state things are in and the CSS can define what that means visually – but you can't do that if your code is littered with calls to .hide().

And beyond all that, there are new, powerful APIs that you can't access through jQuery on its own: things like the new MutationObserver and WebRTC require you to talk to the browser itself. And, it turns out, that's not all that bad.

Use it: don't depend on it

We may not need jQuery any more, but what's the harm in using it if it makes your job easier? There isn't any! Keep using jQuery to build your sites and apps. But if you're building a library, consider not making it into a dependency.

Why? Because jQuery is a big, monolithic library. It includes Ajax, DOM manipulation and selection, events, promises, effects and a whole bunch of utilities. Having all of this in a single package locks us all into the jQuery way of doing things – which is also the 10-year-old way of doing things.

Alternative solutions

So what can we use instead? Q does brilliant things with chaining promises and exception-handling. CSS animations are much smoother than anything you could do with JavaScript. Soon, custom elements are going to provide the best possible way of building reusable components. If we live in a world where you can pick and choose which DOM manipulation library you want, or whether you want to use RSVP.js or Q for promises, we can end up with better open-source solutions to all of these problems.

Beyond all this, the jQuery plug-in style puts every library you include in the same, ever-growing namespace. Everything is $(el).colorPicker(), or $(el).chosen(). This doesn't play nicely with a future in which we have real modules. Modules will enable us to cleanly seperate our dependencies, and create optimised builds more easily. Whether you use Browserify, RequireJS or the modules added with ECMAScript 6, it's the future. A single, global namespace isn't.

So how do we reach this brave new world? The first step is for all the libraries we need to release their death grip on jQuery. If they become dependency-free, we can begin to imagine building a modern web app without it.

There is one important caveat: if you're targeting older browsers, including IE6 and 7 or Android 2.3, you aren't ready for this brave new world just yet. Enjoy jQuery to its limits and dream of a future when you can finally speak the browser's language.