It's a revolution.
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?
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 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.