This isn’t a jQuery vs. the world rant, nor is it a comparison of MVframeworks. Instead, this is my take on how the jQuery phenomena is hindering the progress of MV frameworks and front-end development in the mobile age.

I’ll start by saying there’s absolutely nothing wrong with jQuery as a library. It’s a great library that gets the job done well. People love it, it’s pretty easy to use and well documented.

Similarly, there’s nothing wrong with your MV* framework of choice. Be it Backbone, Ember, Angular or the slightly less popular Batman, Spine, CanJS and the likes. All are good and worthy.

The world of DOM libraries and MV* frameworks is peachy, rosy and with a slight scent of cinnamon. Or is it…….?

When it comes to open-source code, freedom of choice is imperative. It’s the secret sauce that pushes innovation, progress and community effort forwards. However, when mixed with the opinionated programming philosophy, that freedom is limited, and sometimes for the wrong reasons.

The right reason for limiting choice is making a decision that helps solve a problem well. For example, if I need model-view binding, I could argue that opting for a specific template engine that provides better tools to achieve this is a good decision. Ember.js did it with Handlebars, and regardless of whether I like Ember or Handlebars, there are probably a number of reasons why this choice was made and why it works for Ember.

I could say that I dislike this tight-coupling of Ember and Handlebars and choose another framework and that’s fine. We make these decisions based on a multitude of preferences and requirements daily.

The wrong reason for limiting choice is making a decision based on popularity, laziness or short-sightedness. So, when Ember.js says it only officially supports jQuery, or when Spine.js says it only supports jQuery or Zepto (without Ajax) that choice means the authors assume jQuery is the right tool for the job, when in some cases it isn’t.

My guess is that this assumption has nothing to do with the technical merits of jQuery in comparison to other libraries and has everything to do with the assumption that jQuery will most likely be used as a DOM library, so it’s okay to rely on it for DOM manipulation, AJAX etc.

Seriously?

That’s like saying “If you want to parse JSON in Ruby, you have to use the native JSON parser because it’s part of the standard library”. To which every sane developer will respond with some variation of “Fuck You!!”

But in the browser world, we’ve become so lazy and tired of browser-incompatibility horrors, that we’re happy to sit back and let a bunch of very clever and talented people make this decision for us without so much a s peep. Sure thing Mr. Katz, I’ll use your great framework, even if you didn’t have the time of the foresight to decouple it from jQuery.

And it gets worse.

What happens when you want to develop a mobile-friendly application with AngularJS, Ember.js, Backbone and derivatives or Spine.js? Does the whimsical jQuery choice justify downloading more than 50KB of code every time someone wants to see your app?

And what if you stumbled upon the best touch events Javascript library in the world, which alas, works with the mighty Tire.js library? Will you have to abandon it for the sake of the popular voice?

This doesn’t make sense, and in any other language would not have been so casually tolerated.

Opinions are fine. Solving problems with a specific set of tools that are right for the job is great. Making arbitrary choices that limit the freedom of choice and herd developer into a close-minded coral is wrong and stupid.

And, to add insult to injury, if you take a close look at what is really needed from jQuery to make such frameworks tick, you’ll find it’s probably selectors, DOM manipulation and AJAX. These are such basic dependencies that any puny DOM library that weighs 4KB can provide, yet jQuery, which even in V2 isn’t as modular as MooTools, YUI or Dojo or as tiny as Zepto, Tire or XUI is the absolute best solution for these trivial requirements.

Let me take a moment and throw up in disgust.

Luckily, since this is the open-source world, all this can be changed pretty easily.

CanJS proves the point by providing bundled versions with support for all popular DOM libraries.

Spine.js could work with any DOM library as long as a small bridge that adds a few DOM methods and AJAX support to the $ object is provided.

Batman,js and Serenade.js aren’t dependent on an external DOM library, and I’ve probably missed a few others.

Following the above examples, if you find this whole jQuery-MV* coupling annoying, idiotic or plain wrong, you can

1. Contribute patches that decouple your framework of choice from jQuery
2. Request projects’ maintainers to decouple / bridge jQuery out of the framework’s core code
3. Use a jQuery-decoupled or library agnostic framework
4. Stop taking jQuery for granted. It isn’t!