Be Library Agnostic

One of the slides in my presentation at Webvisions last year was titled "Avoid Library Calls". The idea behind this was to try and build your code in a way that it didn't need to be tied so deeply to one particular library.

Here's the example I used:

function makeBlack(elementname){
  $(elementname).style.color = '#000';
}

function makeBlack(element){
  element.style.color = '#000';
}

In both cases, I have to make the call to the makeBlack function but in the second example, I've already received the actual element and can perform my magic on it directly; I'm not tied to any particular library.

Moving Forward

With the recent announcements of Jack Slocum's Ext moving to support jQuery and jQuery supporting OpenAjax, I feel like the JavaScript community is slowly moving towards that ideal.

When using a JavaScript library, there are commonly three tiers to an action:

1. Core code
2. The Bridge
3. Library

The core code is the whole purpose of whatever you're trying to accomplish. It's the photo gallery, it's the star ratings, it's what you're getting paid to do.

The library is the reusable components for handling DOM retrieval, event handling and so on. This might be jQuery, Prototype or you own custom home-brewed solution. Either way, this is the base that you pop into every project you start.

All hands to the Bridge

The bridge is the component that most people don't bother with. Most would take the core code and tie it in directly with one's library of choice. Thing is, creating a bridge via JavaScript can actually be quite straightforward.

Take a look at Lightbox 2.0 as an example. Looking through the code, only a small portion of it is actually reliant on library-specific functionality like:

Element.show('caption');
Element.setInnerHTML( 'caption', imageArray[activeImage][1]);

This type of functionality is found in more than one library and minimizing ones footprint within a library gives you the flexibility to quickly and easy move to another library. For example, wouldn't Lightbox be handy for those who use jQuery[1] or YUI?

JavaScript makes implementing a bridge quite easy because it's easy enough for us to override and overload functions from other libraries without a large footprint. For example, you might like to use $ to retrieve elements. Sure, jQuery and Prototype have $ functions but what about YUI? Sure thing, just map $ to YAHOO.util.Dom.get and just like that, none of your core code has to change.

Wasteful?

For some, adding a bridge component to their applications on top of a hefty JavaScript library seems wasteful but if you're developing something to be repackaged and reused (like Ext or Lightbox) then the additional footprint can be minimal. Ext's jQuery bridge, for example is only 6k. Considering the entire Ext library comes in at 373k, that's less than a 2% increase in size to maintain library agnosticism.

For those not having to rely on redistribution of code, minimizing your direct ties into a library may save you time and effort down the road when it comes to refactoring, either to switch libraries, upgrade to a new version that may have API changes, or reusing the component within other internal projects.

I'm definitely pleased to see jQuery and Ext moving in this direction and I suspect we'll see more of this in the future.

[1] Yes, I know about Thickbox, I'm just saying.