Enterprise-class JavaScript
Comparing Apples and Oranges
If you are writing small internal applications that are being worked on and supported by only one or two people then I really don’t have a problem with jQuery. It’s light, fast and the most well known of the JavaScript libraries.
But jQuery is not a framework, it’s a library with plugin capability. Sure it’s extensible, all JavaScript is extensible, but jQuery is not an enterprise-class solution.
The difference between a library and a framework is that a library is a collection of utilities (different JS files) that help you accomplish certain tasks. They don’t necessarily work together and they usually don’t get along unless you marry them with other code.
Sometimes the marriage works, sometimes it doesn’t. Most of these utilities are open-source and written by different people with very different understandings and skill levels of object-oriented and JavaScript programming.
jQuery’s plugin architecture is both its boon and its bane because while the library is highly extensible, most of the plugins come from disparate sources that invariably don’t play well with others, or they’re buggy or badly written or they simply break within your particular application’s implementation of them and need to be debugged or hacked or re-factored to make them work as intended.
In a word, it’s leads to very “sloppy” design.
Fully-stacked!
A full-stack JavaScript framework on the other hand is different. “Full-stack” (as opposed to “Loosely-coupled”) means that all of the modules within the framework were specifically designed work together in unison; they are usually “aware” of other components within the framework; and they seamlessly share a full-stack of properties and methods and exchange data without the need to marry them with additional code.
For example, I can literally build a data object via AJAX and then throw that data object into a table module with only a var reference; the table module will instinctively show a view of the data object each time it dynamically updates with new data. Of course, you can do something similar with jQuery and a few plugins, but a framework’s data object works seamlessly not only with the data table scenario, but with the auto-complete control, and any other control that requires some form of data gathering and storage within the DOM as well.
Do It My Way
Perhaps one of the more interesting aspects, if not the most irritating aspect for programmers, is that a JavaScript framework forces you to code in a particular way, much like an MVC (model-view-controller) does. Mind you, I’m not talking about simply syntax here.
A well-written framework shouldn’t force you re-learn a new JavaScript syntax like jQuery does. Rather it should merely keep you on the straight-and-narrow doing things a certain way. It should force you to keep “clean code” and not allow you to diverge into your own private Idaho when creating modular components for various parts of the application.
As programmers, we sometimes hate that. But in the end it makes for components that work well together within the application and are later easily understood by others in the team after the original author is long gone.
Granularity
A framework module also gives you, generally, substantially more control over components than a library with disparate plugins might. Now that flexibility and control sometimes comes at the cost of needing to write additional code within the framework to describe to the component exactly how you want it to work, but in the end it beats rewriting the module to force it to behave the way you want.
This trend towards doing more with less code is sometimes WAY over-rated. That small code footprint comes at the expense of flexibility. As a high-end developer, I sometimes really need flexibility and libraries like jQuery can get in the way, which is one of the many reasons I don’t use them.
For instance, both the jQuery library and the YUI (Yahoo! User Interface) framework allow you to do basic element animations with just one line of code. You include one JS script file in the header of your page, write one line of JavaScript, and BOOM! you have an animated element on the page.
But if for some reason you need granular control of the “frame rate” of that animation or you need to stop or control the animation mid-cycle or grab all of the elements that are currently animated on the page to see where they are in their animation cycles, libraries like jQuery do not generally expose those things natively, if at all.
Because a “framework’s” components are built modularly by extending one or more base components, and because those components need to “talk” to each other, the framework’s API is generally much more feature-rich than a JavaScript “library” will be.