Additionally, some libraries also feature, as a plugin or as part of the core, various user interface (UI) components and widgets, most notably jQuery UI, YUI, Digit (Dojo), and Ext.
With that in mind, it is important to outline the criteria when considering which framework to adopt or whether or not to use one at all. Much of the criteria including the weight of each measure will be specific to the project in question, most of which stemming from the scale of the project and the desired functionality. Does your project require certain UI components such as a grid, toolbar, or tabbed interface? Will my application require support for HTML, XML, SVG, flash, or canvas? These are just a few of the questions that should be evaluated on a case by case basis. In addition to that, there are several general questions a developer should ask of himself and the pending project that are relevant to any and all projects:
- the ease of implementation/updates (API)
- browser support
- file size (bytes)
- robustness and modularity
- stability and reliability
- the developer’s overall capacity to understand and progress in their understanding of their implementations
The last point is especially important and should not be glossed over, dependency is something you should steer away from – to understand all the code is to know how to fix/improve it, even if it isn’t your code.
As I mentioned above, cross-browser compatibility and normalization is perhaps the greatest attribute of any library. The developer need not worry about the flawed implementations of the various browsers or what functionality is supported or isn’t, let the library worry about that.
If you are to adopt any third-party software, well documented code and a highly adaptive API are key. Although it is completely dependent on the framework at hand, typically a library will supply solid documentation set with examples.
Plugins, extensions, and user interface widgets are just a few of the byproducts of a healthy and active community. Extensibility plays a large role in developing and maintaining a community of developers for a specific library, and nobody does this better than jQuery. The library boasts an impressive amount of plugins ranging anywhere from drag-and-drop and layouts to data stores and media. With a community as active as that, virtually anything you could ever want is already available and ready for implementation.
At some point in the last four or five years, as the library revolution started to take over, too much attention has been placed on the positives and not enough focused on the negatives. These libraries are often portrayed as perfect, but they are not, and you should understand all the disadvantages inherent in their adoption for a project.
Ultimately the solution lies in learning the language and not a library, to know the bugs, the browser inconsistencies, and the supported implementations and knowing what to do about it. However, I realize that it is a time consuming goal that may not be realistic for the short term, that is why I propose a middle man; the module, think of it as a plugin for the language not a library.
Perhaps its a lack of support for lightweight and standalone modules that have driven people to the all inclusive framework and the various plugins that lie on top of them, in part this blog is dedicated to fill that void. Still third party software, a module however is small and concise and serves only one purpose, whether it be DOM manipulation, event handling, AJAX requests, or what have you. This makes for a much simpler approach and therefore easy debugging, not to mention, the author is more likely to update with greater frequency, plus no pesky dependencies.
Naturally, as many modules are thrown together, cohesion is likely to be effected resulting in code duplication and loose coupling, that is where you come in. Make it cohesive, merge the modules and create something custom for each project, your not reinventing the wheel but your also not relying on someone else’s. Take the tire, the rim, nuts and bolts and put it together yourself! You might learn something in the process!
Development is about one thing; to have a better understanding of what is going on behind the scenes, know your implementations and understand their impacts. The ultimate goal is the satisfaction of your end-user, and at the end of the day reliability should be your number one concern. For this, the answer is clear.