Seriously, what is jQuery?

It's a revolution.

Its creator, John Resig, calls it "New Wave JavaScript". Whatever. I know a revolution when I see one.

The whole concept is based on the undeniable premise of web design: “separate content, behavior and presentation”. This makes an emphasis on the markup-javascript separation and does an incredible job at it. Behind this whole concept is the fact that any behavior in a document can only be triggered by the user, and the user can only interact with the HTML document. There's no new DatePicker() inheriting from new Calendar. Everything is just a bunch of links, inputs and buttons. This concept dramatically simplifies development and maintainability, as it's clear that it won't change by the introduction of a new gadget-widget.

What about inheritance? what about OOP?

OOP is not the only way to reuse code. It's great, yes. It doesn't work well with JavaScript and the DOM because it's not supposed to deal with supers. What's the super of an input? Nothing. How do we reuse functionality across similar objects? I know how, I just don't know what it's called. Look up Decorator Pattern , Composite Pattern and Adapter Pattern and let me know if I'm close.

The idea is that there's a wrapper that goes around each and all DOM nodes (when you need it). Inputs, divs, spans, you name it. Then there's some functions that you can call on them just because they've been all wrapped. All of these functions take a collection of nodes and return the same collection, so you can even chain them one after the other and same some vars. Fancy? For an additional kapow, let's say you can get your nodes in an extemely eloquent way. Ok, you'll have to ramp up on CSS3, but you don't even have to. It's just that if you do, your code will be smaller.

The core is a library called jQuery. Its mailing list started in January 2006 and it has a significant amount of skilled javascripters as users. The jQuery project is very well organized with unit tests and documentation both in code and online. The library is also provided "packed" which makes it roughly 16kb in size (circa 2006; 31k circa 2012).

The appendages vary. Most of them are plugins for jQuery. What's special about them is that they follow a pattern, which is at the core of jQuery eloquence: you have to write them in a way that you always return the same object (the "jQuery" object) and iterate within your plugin. This means that you know exactly what to expect from the plugins. Another great advantage is that since jQuery is so eloquent, these plugins are very, very small, so if you or me don't like something... we rewrite it without breaking a sweat.

It is to be noted that the fact that everything is supposed to act on a collection of nodes, implicitly mandates that all plugins are all mix-and-match. If you want to encapsulate some of those behaviors into something more general, you go ahead and do so. But did you realize that you didn't have to create a class? Inherit from anything? What? OOP? Did you say something? Exactly.

There's obviously functionality that hasn't been written as a plugin. There might be libraries that already do what our code does, but no plugins for jQuery. So we write one of those, for example. Did I mention how fast this is? I'm talking at least one order of magnitude faster.

Ok, all this sounds fantastic. What's wrong with it? Hmm. Well, libraries are unlikely to have unit tests, although there's demo pages. Honestly, even if the libraries aren't tested by a QA department, they have been used, discussed and tested by a large amount of very good developers. You don't have to take my opinion for granted but I'll say I wish I could write code like a bunch of these guys. Worst case: If something craps out, we just have to replace a tiny part, thanks to the massive amount of modularity here. The plugins clearly define what each bit is supposed to do or not do, so changes are extremely localized. The conventions makes communication across modules a no-brainer.

We must spend our coding hours developing either more abstractions, or writing the specific rules for our specific feature. No more redoing monkey work. Enough is enough.