1. Writing code well in a way that you could keep adding developers and they could each increase productivity linearly.
2. Writing code that will work for increasingly larger sites.
3. Writing code that is maintainable, testable, and extendable.

I know others have thought about this, some people call it “best practices”, some people call it frameworks, Yahoo even went as far as to create the YUI family of libraries. I think deep down, most people were trying to think about how to “scale” whatever it was they were doing.  This entry is the first in a series of writing jQuery code that “scales”.

Another thing I probably need to address before we get started is “Shu”. It comes from the Japanese phrase “Shuhari“, which I learned from Alistair Cockburn and is common in the Agile circles, and “describes the stages of learning to mastery”. Once you’re aware that there are certain levels of mastery of something, you start asking yourself which level you’re at and what level others are.

JQuery is awesome, and I love it. For along time, I treated javascript as a 2nd class citizen, but I’ve recently been really digging into it and making it “scaleable”.

In Dan Cederholm’s recent book, he introduces some jQuery that I’m lumping into the “Shu” box (ba-da ching!).

$(document).ready(function(){
$("#loc-adv a").click(function(){
$("#map").slideToggle("slow");
return false;
});
});

Now don’t get me wrong, this code is perfectly acceptable, especially for the situation it’s presented in (a small, static site, built by 1-2 developers). I’m all for not complicating things if they don’t need to be. This code is the simplest thing that could possibly work, and that’s awesome. However, we’re talking about scaling javascript up to larger sites, more developers, and maintainable in legacy applications, and there are some things about this code which don’t make it very scaleable.

First, it’s not really re-useable. Sure, you could include it in any page that has the `#loc-adv` a link and a map, and it’s going to work, but what if  you needed multiple maps in one page or had multiple links. All of a sudden, you’re going to need to repeat yourself, and we don’t do that.

Second, if you put this right in your page, as it’s presented in the book, you can’t use it on other pages without repeating yourself. Maintaining this code could be painful if you put it in more than one page.

Third, the only way this code is going to fire is if you click the link. There’s no way to call it from other code, or test it, and you’ll have to attach it to multiple elements if you add another link or some other element that needs to reveal the map.

What if you want to link to the page with the map open? This code won’t account for that.

I’m not going to address all these issues in this post. I’m going to leave that up for the “Ha” and “Ri” posts. Look for them in a couple days.