Library or no Library, That is the Question!
It is rarely even a question anymore; deciding whether to use a JavaScript library on your next project typically goes without saying, the real question developers find themselves asking is which library should it be? However the decision to adopt any framework for a project should not be taken lightly and deserves a proper evaluation of requirements before making a decision based on assumptions. Often a library may ask of a developer, “Does the JavaScript library help me to write JavaScript?”, but shouldn’t they ask if the library helps them to learn JavaScript? Learning the syntax of your favourite JavaScript library does nothing for the developer’s understanding of the language itself or the impact on performance, memory, and reliability of their implementations. For this article, I will be looking at both sides of the argument, but hiding my bias will not be easy, my hope here is that perhaps a few developer’s may rethink their approach.
Why use a JavaScript Library?
The driving force behind JavaScript libraries and their very rise in popularity is based on two things; cross-browser compatibility and the lack of various native implementations. They create an easy-to-use implementation which helps to normalize behaviour across browsers and add additional functionality, specifically as it relates to the the four core aspects of most JavaScript libraries; event handling, animation, DOM (manipulation and traversal), and AJAX.
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.
The typical reasoning as to why a developer adopts any JavaScript library for their project falls back to the common expression; why reinvent the wheel?
The Criteria
Evaluating a JavaScript library is no different than an evaluation of your own code, after all, once implemented, you will assume responsibility for it. Performance, compatibility, and bugs will immediately become your problem – it is you who will hear the complaints of your end users, not the authors of the third party software you’ve decided to utilize. Therefore, it is important to understand the flaws inherent in all JavaScript libraries and to properly justify your choice of implementation for a specific project.
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)
- documentation
- performance
- extensibility
- 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.
Advantages
Without question, a well developed JavaScript library has many advantages over the alternative and provides the developer a simple layer of abstraction on which to develop their application.
One of the primary advantages to a JavaScript framework is the ease and simplicity of development and implementation. Whether it be prototypical/classical inheritance, CSS selectors, animation and effects, or creating a wrapper class for things like elements, AJAX requests, or what have you, a library typically allows you to make quick implementations in little time and little bytes.
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.
Most of the JavaScript libraries available today are completely open-sourced, including; jQuery, Mootools, Prototype, YUI, Dojo, Ext, and more. Not only does this help to create an active community but can also help a developer in understanding how the framework implemented a certain feature by simply viewing the source and reading the documentation. It proves to be a very useful resource for anyone looking to learn and understand advanced JavaScript.
Disadvantages
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.
First and foremost, browser detection is a common problem amongst JavaScript libraries, and virtually all still utilize it. There is no feature/bug that can’t be detected, tested for, or worked around in some manner. Sacrificing bytes for shortcuts should never be permitted especially amongst the very best the industry has to offer. The goal should be to try and support as many browsers as possible, otherwise you could be turning away potential visitors without even knowing it. I would be remissed if I didn’t mention that jQuery (as of version 1.3) no longer utilizes browser sniffing as part of the base library, however many plugins still do!
Bugs are a common problem with any code, however when it isn’t your code and you don’t understand the implementations, your limited in your ability to resolve the bug. Such is the case with JavaScript libraries, a developer may find himself waiting for a new version or update of a specific framework to solve his bug as visitors continue to encounter the problem. Once that new version is released and implemented, he better cross his fingers and hope it gels well with not only his code, but any other plugins that also rely on that particular library. Often a library will release a version that unexpectedly drops support for specific methods, properties, and/or classes, forcing plugin developers to update their versions (which you will also have to wait for) unless you try and do it yourself.
Another common problem various JavaScript libraries internally struggle with is the battle between usability/simplicity (API) and performance. The layer of abstraction your working with may be on such a high level that the length and intensity of each method call is slower than it otherwise should be, specifically as it relates to DOM manipulation. For instance, jQuery contains all currently selected elements within an internal array that must be looped through on each method call, whether the array contains 100 items or 1 or 2, this creates unnecessary overhead. Although it is true that libraries consistently improve in this regard, performance still lacks where typical manual DOM manipulation excels, especially in IE. Just look at these performance results conducted by Anrea Giammarchi in a test that pits the various JavaScript libraries against the DOM.
A JavaScript framework is often guilty of trying to do too much, resulting in a bloated library of methods and classes that are rarely utilized, trying to answer questions nobody has asked. Whats worse, is the encouragement and support for bad programming, trying to normalize behaviour not only amongst browsers but developers too. Of course, this results in a larger file size full of unused code – wasted bytes using unnecessary bandwidth. On a related note, many developers will use a JavaScript library solely for its support of a specific plugin, such as a lightbox or date picker. This requires them to import a large framework the majority of which is never utilized and therefore never justified.
As I mentioned before, the adoption of any JavaScript library does not progress a developer in the understanding of the language or the various implementations. It creates a certain level of dependence on methods, classes, and plugins that may not be there forever, as you fall at the mercy of the third party software. Sooner or later, the JavaScript language along with browser support will grow and improve, JavaScript libraries will quickly become obsolete in that environment, and any developers who rely on them will be left out in the cold – with their app of course.
The Solution
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.
I love this blog. I’ll definitely be looking into it frequently.
and so… thank you