Do you need a library?
No matter what language you’re writing, libraries all serve the same purpose: to provide common, reusable functionality and save you from writing lots of repetitive code. And no matter what language you’re writing, if you find yourself writing the same thing over and over, odds are you could use a library to help you out, whether it’s one that somebody’s already written or one that you write yourself and reuse.
When you’re writing JavaSript, it’s very easy to end up in just that situation; there are a number of common things you’ll need to do repeatedly, like attach listeners to events or fire off an
XMLHttpRequest, which will be pure misery if you have to write all the code for them each time you use them. For example, consider what’s needed to attach an event listener:
- You need to handle the different ways of attaching the listener.
You need to handle the scope in which the listener’s callback will execute (since the value of
thiswill vary from browser to browser).
- If you want access to the event’s target element you’ll need to handle the variations for that.
- If you want to prevent the default action for the event you’ll once again need to take care of cross-browser variations,
Writing that sort of thing just once is tedious. Writing it over and over again is a nightmare. So the natural solution should be some sort of reusable implementation which normalizes all the browser quirks and gives you a single interface to work with. And that’s precisely what libraries are for.
Do you need someone else’s library?
XMLHttpRequest and all the browser quirks, then you can probably write a nice little quite of common functionality for yourself. So why rely on someone else’s possibly-buggy code? I can think of a couple reasons:
What makes a good library?
It’s really tough to answer this in an objective fashion, because it’s not entirely an objective question; once you get beyond the basics, every programmer has slightly different needs and slightly different preferences, so there isn’t a “One True Library” out there which will be right for everyone.
As far as objectivity goes, there are a few things every good library has to have in order to be usable:
- A normalized event model, including attaching/removing listeners, automatic scope correction and access to the event itself.
A normalized wrapper around
XMLHttpRequest, including the ability to specify callbacks to fire when the request finishes.
- A set of normalized utilities for working with the DOM, especially for getting/setting styles and managing class names.
- Facilities for creating visual animations, whether pre-defined or custom, which handle cross-browser timing quirks.
Subjectively, there are several other things I look for; missing one of them isn’t a deal-breaker by itself, but I’ll always gravitate toward libraries which meet most or all of these criteria:
They don’t wrap DOM methods for the sake of wrapping. Providing a wrapper when cross-browser variations make the real method hard to work with is fine, but I’ve seen too many libraries provide aliases to
getElementByIdfor no good reason; if I want it aliased to a shorter name, I’ll do that myself. Libraries which take it on themselves to do that for me are just adding unneeded overhead and polluting the namespaces I have to work with.
- Closely related to that: good libraries get one object and keep all their code in it. Leaking code out into built-ins is once again asking for a headache. The Prototype folks learned that one the hard way so you wouldn’t have to.
Again, these things are highly subjective; most of them are rooted in what I personally think constitutes good coding practice, and there’s room for lots of opinions on that topic. If you find yourself disagreeing with me on one or more of these points, just ignore them and move on; you’re probably not going to change my mind about them and I’m probably not going to change yours.
Oh, yeah, forgot about this…
- High-level overviews of each part of the library, touching on key objects and methods.
- Practical examples showing how to handle common use cases.
- Full API documentation for everything in the library. JSDoc is both good and bad for this: good because it makes API docs stupidly easy to generate, and bad because people assume that API docs are all you need. Javadoc, which inspired JSDoc, has wrought much ill on the Java world for largely the same reasons.
- Comments throughout the code itself.
Go forth and choose