Skip to content

Choosing Client-side Libraries

December 22, 2010

There’s a lot of opinions on choosing javascript and css libraries out there. I don’t want to add too much more to that, aside from a few short remarks.

First, some of the conventional wisdom:

  • Use a CSS reset library. Good advice. Probably the best. Any disadvantages a reset stylesheet has are bought back by normalizing the way different browsers handle default presentation of HTML.
  • Don’t roll your own JavaScript library. Again, decent advice. A well-maintained JS lib (and there are about a good dozen on the market now) will contain fewer bugs, a developer community, and ready-made documentation.
  • Use library plug-ins as often as you can. For both CSS and JS, there are libraries that are built intentionally to support plug-ins (jQuery being the most obvious example). Popular plug-ins will be more thoroughly debugged than code you write yourself. Of course, if nothing suits your needs, it’s time to roll up your sleeves.
  • Don’t use code you can’t understand. When evaluating libraries for inclusion in your project, never use anything you can’t extend, modify or debug. You don’t have to understand deep details (I doubt many Prototype or jQuery users understand every line of those libraries), but you need to know the API and it’s limitations at a minimum. Change is the only constant in projects.
  • Don’t fork libraries. Which seems a direct contradiction to the above rule, but isn’t. One of the criteria for choosing a library is that it’s well-maintained, meaning there will be patches, bug fixes, and new features on a regular basis. Forking the code will cut you off from that. What is meant in the above point by extension and modification is that you can add what you need to the library without cutting yourself off from future updates via plug-ins or extending objects.

I don’t disagree with any of the above. I think it’s the best advice you can give a team, and it should be in most company’s guide to style and development practices.

However, I think there a few points missed by the above.

Mobile and alternate presentation

The mobile landscape has exploded in the last few years, in part because of the iPhone. This is one area where every kilobyte counts. Most of the larger, accepted JavaScript frameworks have a big footprint.

Add to this the rise of the eReader. Admittedly, JavaScript is illegal in the official ePub spec, but you still have CSS to deal with.

And there are more devices on the way: Netbooks, Google Chrome OS, the new wave of crackBerries, and things we haven’t thought of yet. The future is bright, but you will probably not be able to build a one size fits all HTML page that responds to different user-agents. Of course, this is the dream, but these devices represent a new “Browsers War” that we will end up fighting in, no matter what we do.

Special-purpose pages

A corollary to alternate presentation layers are the single-purpose pages, micro-sites, and other “special” pages that need to get built for a website. The classic example is the much-maligned popup window, but HTML email templates, video player pages, and interstitial pages all fall into this category.

Many of these pages will not have the standard header, footer, and other elements that contain your main libraries, have the same performance requirements mentioned in the mobile section above, or require library support the rest of the web site doesn’t. In the case of things like HTML email templates, you don’t even have access to modern technology, and have to go ‘old-school’ with table layouts and other relics from bygone days.

Kitchen sinks

A lot of the common JavaScript frameworks take, for the most part, the “kitchen sink” approach, meaning that they attempt to include a lot more functionality than you may ever comfortably use. Even frameworks like YUI 3, which is very modular, contain dozens of functions in the core parts like node and io.

Another problem with the kitchen sink approach is that you can’t delete the parts you don’t want. Not only does this fork the code, but libraries built this way constantly reference utility functions that are never exposed as part of the API, but are necessary for the library to work. Cutting bits is risky, because you may delete a function that’s only used in a special case that you haven’t yet tested for, but will bite you in the ass when you add the next feature and it’s not there.

The last problem is that kitchen sinks, contrary to folk wisdom, don’t contain everything. Before the rise of Prototype, jQuery, and YUI, there were dozens of small libraries that did only one thing, but extremely well. SIFR, Lightbox, and swfObject are probably the most well-known. You will find that the big frameworks only provide the building blocks for these types of things, which is the point. But if the page only needs a lightbox effect and nothing else, and you have to download a huge framework behind it to get that effect, you run into performance issues. Sometimes you can rely on caching and minification to skirt around this, but not always. Some of the special-purpose pages I mentioned above will need every ounce of raw speed, or need to be viewable by first-time visitors whom you’re trying to convert.

Skills atrophy

The biggest single plus of CSS and JS frameworks is that they abstract away a lot of the low-level detail work that needs to be done like event handling, DOM manipulation, normalizing margins and clearing floats, and accommodating browser bugs and implementation differences.

The benefit of this abstraction is that developers can focus on the feature that needs to be implemented, not on the differences between browsers. The cost of this abstraction is that developers start to forget these details, or never understand them to begin with. This cost can also be a side-benefit, because it allows junior developers to work productively while they continue to learn.

Knowing the technology versus knowing an API is a trade-off with every library you’ll ever use in any programming language. How this is dealt with in your organization or project is something to which I can’t offer any specific advice.

No easy answer

All of this is really about making informed design decisions regarding unique situations. There is no silver bullet answer.

I would like to suggest some possibilities:

  • Don’t be afraid to roll a mini-lib. In some cases, producing a tight, minimal library for special-purpose pages can pay dividends. What goes into that library will depend on your project goals, but there things like event handling, DOM manipulation, and basic AJAX that will be in most mini-libs. The Sitepoint book Simply Javascript has an excellent example of a mini-lib called core.js, MIT-licensed, that could form a good starting point.
  • Wrap calls to functions in your larger JavaScript library when you build plug-ins. If you can. Meaning, instead of calling the function directly, build a simple layer between your plug-in and the framework that will translate the function in the plug-in into the right function in your framework. So, instead of calling Y.one('#myID') in your plug-in (assuming you’re using YUI3), you call myCustomGet('#myId'), and have a smaller library translate that into a valid YUI 3 call. When you need to use the plug-in on a page where YUI3 isn’t available, you can create a myCustomGet() utility that sits in place of the translation library. Yeah, this is complicated. The work may only be worthwhile on domains that host micro-sites almost exclusively.
  • Roll your own framework from existing parts. You don’t have to choose a big framework. Stuff like swfObject and SIFR is still around. You can build from a collection of smaller parts to suit your needs. This can be very modular, but requires a much higher level of communication and management within the organization.
  • Save your custom functions and styles. Code reviews can ferret out CSS rules and JavaScript functions that are duplicated in different areas of your site. Moving them into common libraries is the best way to cut down on duplication and create a ‘house framework’ to supplement what you’ve chosen as your main framework. Consider donating these to the maintainers of the framework you’ve chosen. It’s good karma and free publicity.
  • Naming conventions are your friend. When you absolutely need to have more than one presentation layer (completely different sets of HTML, CSS, and JavaScript), strong naming conventions can ease development considerably. Giving all error fields a class of ‘error’, all non-printable areas a class of ‘noprint’, etc, can make building separate CSS and JavaScript files easier. Even if the visual representation of an ‘error’ tag is different, even if the tag itself is different, having the class remain the same allows you to share code and coding design patterns between the different presentation layers. Modelling your data is the best investment you can make.

Frameworks are cool

Probably the best investment you can make is a framework. There’s no denying that. Prototype, jQuery, YUI, the various reset and grid CSS frameworks, have all significantly sped up development efforts and reduced debugging. There is no reason to build from scratch when you can use one of these excellent pieces of software.

But there are points when you have to make architectural choices that force you to deviate from the norm. When you need to do so, don’t be afraid to get creative. But remember that CSS and JavaScript are there to serve content, and aren’t content themselves.

Advertisements
2 Comments leave one →
  1. Dave permalink
    December 28, 2010 3:48 pm

    One thing you leave out is that if people are using a shared repository, like the Google JQuery, chances are that the surfer will have it cached already.

    • Jeff Wyonch permalink*
      December 31, 2010 5:23 pm

      There are pros and cons to that, as well. But my point is that it’s highly unlikely that one lib is going to solve all your needs, with the amount of different devices on the market beyond the desktop browser. And, I wouldn’t want to rely on Google maintaining that service in the long term.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: