blogZero

What's this, no multi-page post today—complete with code examples and links all over the place? Instead, I did some house cleaning, and added a new wing. JavaScript has been such a hot topic around here of late, and in the Web development community in general, that I took a look at my growing list of resources and discovered that indeed, the JavaScript category was in need of some pruning. Amongst the list, and in particular by studying the most popular tags, I found that JavaScript libraries would make an excellent category to splinter off and reduce the weight in the parent folder. I know, I know, I need to implement paging. PHP is another one that grew out of its clothes.

Speaking of implementing paging (and caching and a lot of other things on my todo list), I have been really busy behind the scenes fixing bugs and making other improvements to both this blog and loadaverageZero in general. Some of them my visitors may have noticed, some may not. But things are definitely on the upswing around here since health has improved.

One thing that really has me puzzled is what to do with this blog. I'm running a rather old, and hacked to pieces, version of Serendipity. I don't want to let go of the design, which I spent a lot of time on, yet on the same token it bothers me that my only recourse to block spammers and other miscreants was to disable comments and trackbacks. I'm not a big fan of Captchas, I would prefer to go the OpenID route.

Anyway, I'm starved and I haven't been to the diner for some good old eggs and bacon in ages...

No sooner had I added Dave Shea's (of CSS Zen Garden and mezzoblue fame) excellent (if somewhat dated) CSS Sprites ALA article to my CSS resources category, then what does he go and do?

Too Late Again

You guessed it, he publishes a follow-up article. The reason I went looking for it in the first place, or rather found it to be the best write-up on the topic, was not so much the how, but the why of using this technique. But he kind of missed the point. Sure, he explains the ins and outs and a bit of the history of sprites, but for my money the single best reason to consider using the technique is a huge reduction in the number of HTTP requests you serve up when storing a bunch of similar iconic images from one master file. Better still, once the browser downloads the aggregate file and caches it, it's a simple matter of some integer offset math to display only that portion you need as a background image in your documents.

Sprites in a Nutshell

Basically, the technique involves creating one or more fixed-sized, block-level elements with ids or classes to be used as selectors in your stylesheet, set the display property to absolute, but relative to some other containing element, say a <ul> with <li> descendants, and then use the top, right, bottom and left values of the background-position property as needed to offset that portion of the image you want revealed. Kind of like a peephole onto a larger canvas. The nice thing is you can move the canvas (the parent element) around with margins or other positioning methods, and the child elements follow right along like a duck and her little ducklings.

CSS Sprites Redux

The latest version of the article takes the technique a step further by introducing some animation effects via John Resig's outstanding jQuery JavaScript library. But Dave misses the original point again, which I found ironic after he warns his audience that using jQuery imparts a certain overhead when downloading the library for the first time.

Ajax Libraries API

However, I did learn something very interesting—Google Code is now hosting jQuery as part of their Ajax Libraries API project—allowing you to link to the library without having to host it yourself. This has two benefits: it saves you a little bandwidth, but more importantly, if enough developers are doing this then chances are your visitors already have a copy of jQuery cached locally. You can also take advantage of the Google CDN if you're using Prototype, script.aculo.us, MooTools/moo.fx, or Dojo. It would be really sweet if Google started hosting some of the more popular jQuery plugins.

google.load()

Personally, I don't understand the advantage of using the google.load() method unless your project involves using their Maps, Search, or Ajax Feed APIs. Why not just load the library and start using jQuery (or whatever) like you normally would?

<script type="text/javascript"
         src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
<script type="text/javascript">
// when the DOM is ready
$(function() {
 // fire away
 $('#selector').method({
  // ...
 });
 // ...
});
</script>

Related Reading

• High Performance Web Sites
• Announcing Ajax Libraries API: Speed up your Ajax apps with Google’s infrastructure
• Speed up access to your favorite frameworks via the Ajax Libraries API
• jQuery Hosting With Google Ajax Libraries API

There used to be a lot of talk about browser wars (both old ones and new), but now days it seems the race is on to see who can develop the fastest JavaScript engine. Not surprising given the explosive growth in front-end development, and JavaScript frameworks and effects libraries. Oh, and a little thing called Ajax. So I spent some time researching and evaluating the current, and future, state of JavaScript implementations and these are my findings.

Evaluation Parameters

Before I get into what's on the horizon, I took the time to evaluate the relative performance of JavaScript in four current browsers. I'll be using the WebKit SunSpider JavaScript benchmarking tool on my Dell XP Pro laptop with the latest Service Packs installed. Internet Explorer is not in the mix because, first of all I can't stand the browser, but mostly because it would likely be crushed by the other competitors—listed below by product, version, vendor, and JavaScript engine:

• Firefox v3.0.3 (Mozilla) (SpiderMonkey)
• Safari v3.1.2 (Apple) (SquirrelFish)
• Chrome v0.3.154.9 (beta) (Google) (V8)
• Opera v9.62 (Opera) (Presto)

To level the playing field, each test was performed after a fresh restart with no other foreground applications running. Of the four, Firefox was the most heavily loaded, at least in terms of the number of extensions/plugins installed. I'm not sure if that would have an impact on the results or not. In all cases there were no other tabs open to skew the results (Google mail leaps to mind).

Firefox

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                 6506.0ms +/- 1.1%
-------------------------------------------------

 3d:                    693.6ms +/- 2.0%
   cube:                264.2ms +/- 3.6%
   morph:               200.0ms +/- 2.6%
   raytrace:            229.4ms +/- 1.6%

 access:                997.4ms +/- 1.2%
   binary-trees:        152.2ms +/- 3.0%
   fannkuch:            473.4ms +/- 0.6%
   nbody:               236.8ms +/- 3.3%
   nsieve:              135.0ms +/- 4.5%

 bitops:                789.8ms +/- 3.2%
   3bit-bits-in-byte:   186.4ms +/- 4.5%
   bits-in-byte:        212.0ms +/- 0.6%
   bitwise-and:         151.0ms +/- 0.8%
   nsieve-bits:         240.4ms +/- 7.6%

 controlflow:           166.6ms +/- 6.5%
   recursive:           166.6ms +/- 6.5%

 crypto:                494.8ms +/- 1.7%
   aes:                 174.2ms +/- 1.3%
   md5:                 160.2ms +/- 2.1%
   sha1:                160.4ms +/- 3.1%

 date:                  571.4ms +/- 4.5%
   format-tofte:        357.4ms +/- 6.6%
   format-xparb:        214.0ms +/- 7.8%

 math:                  742.0ms +/- 1.9%
   cordic:              351.2ms +/- 1.8%
   partial-sums:        218.4ms +/- 5.5%
   spectral-norm:       172.4ms +/- 1.1%

 regexp:                508.6ms +/- 7.1%
   dna:                 508.6ms +/- 7.1%

 string:               1541.8ms +/- 0.4%
   base64:              176.4ms +/- 3.5%
   fasta:               381.6ms +/- 1.6%
   tagcloud:            296.0ms +/- 3.4%
   unpack-code:         476.0ms +/- 1.3%
   validate-input:      211.8ms +/- 4.8%

Safari

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                 6428.2ms +/- 1.1%
-------------------------------------------------

 3d:                    745.0ms +/- 1.9%
   cube:                240.2ms +/- 3.7%
   morph:               258.4ms +/- 3.9%
   raytrace:            246.4ms +/- 2.7%

 access:                977.0ms +/- 2.1%
   binary-trees:        132.0ms +/- 4.2%
   fannkuch:            474.8ms +/- 2.4%
   nbody:               242.2ms +/- 5.6%
   nsieve:              128.0ms +/- 8.1%

 bitops:                782.8ms +/- 2.1%
   3bit-bits-in-byte:   120.0ms +/- 0.0%
   bits-in-byte:        176.0ms +/- 3.9%
   bitwise-and:         292.4ms +/- 3.6%
   nsieve-bits:         194.4ms +/- 3.6%

 controlflow:           154.2ms +/- 4.3%
   recursive:           154.2ms +/- 4.3%

 crypto:                442.8ms +/- 3.0%
   aes:                 164.2ms +/- 6.7%
   md5:                 136.2ms +/- 5.2%
   sha1:                142.4ms +/- 4.2%

 date:                  624.8ms +/- 1.1%
   format-tofte:        262.0ms +/- 2.1%
   format-xparb:        362.8ms +/- 1.6%

 math:                  811.4ms +/- 2.9%
   cordic:              322.6ms +/- 3.3%
   partial-sums:        330.2ms +/- 4.5%
   spectral-norm:       158.6ms +/- 3.8%

 regexp:                520.8ms +/- 0.1%
   dna:                 520.8ms +/- 0.1%

 string:               1369.4ms +/- 6.9%
   base64:              184.0ms +/- 3.7%
   fasta:               328.2ms +/- 3.1%
   tagcloud:            314.4ms +/- 30.2%
   unpack-code:         268.6ms +/- 4.0%
   validate-input:      274.2ms +/- 2.4%

Chrome

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                2697.4ms +/- 2.6%
-------------------------------------------------
 3d:                   237.8ms +/- 12.9%
   cube:                53.8ms +/- 9.3%
   morph:              120.6ms +/- 24.5%
   raytrace:            63.4ms +/- 3.0%

 access:               154.6ms +/- 6.0%
   binary-trees:        10.8ms +/- 18.9%
   fannkuch:            54.4ms +/- 3.5%
   nbody:               54.0ms +/- 9.4%
   nsieve:              35.4ms +/- 7.7%

 bitops:               119.8ms +/- 5.6%
   3bit-bits-in-byte:    9.8ms +/- 5.7%
   bits-in-byte:        18.8ms +/- 7.2%
   bitwise-and:         37.4ms +/- 3.8%
   nsieve-bits:         53.8ms +/- 11.1%

 controlflow:            6.8ms +/- 8.2%
   recursive:            6.8ms +/- 8.2%

 crypto:                96.8ms +/- 4.4%
   aes:                 33.8ms +/- 9.9%
   md5:                 32.4ms +/- 3.4%
   sha1:                30.6ms +/- 2.2%

 date:                 621.6ms +/- 2.7%
   format-tofte:       264.8ms +/- 6.5%
   format-xparb:       356.8ms +/- 1.8%

 math:                 198.4ms +/- 5.3%
   cordic:             105.2ms +/- 10.6%
   partial-sums:        67.2ms +/- 5.1%
   spectral-norm:       26.0ms +/- 3.4%

 regexp:               547.4ms +/- 1.7%
   dna:                547.4ms +/- 1.7%

 string:               714.2ms +/- 2.2%
   base64:              73.0ms +/- 13.6%
   fasta:               99.8ms +/- 2.8%
   tagcloud:           188.0ms +/- 3.7%
   unpack-code:        246.0ms +/- 1.2%
   validate-input:     107.4ms +/- 3.0%

Opera

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                 7536.2ms +/- 1.2%
-------------------------------------------------
 3d:                    815.6ms +/- 2.7%
   cube:                254.4ms +/- 2.5%
   morph:               302.6ms +/- 5.5%
   raytrace:            258.6ms +/- 2.3%

 access:               1160.4ms +/- 0.8%
   binary-trees:         82.4ms +/- 7.3%
   fannkuch:            568.8ms +/- 1.0%
   nbody:               314.6ms +/- 1.9%
   nsieve:              194.6ms +/- 3.5%

 bitops:                987.2ms +/- 10.8%
   3bit-bits-in-byte:   116.2ms +/- 5.6%
   bits-in-byte:        238.2ms +/- 44.3%
   bitwise-and:         378.6ms +/- 1.4%
   nsieve-bits:         254.2ms +/- 2.6%

 controlflow:            98.2ms +/- 10.3%
   recursive:            98.2ms +/- 10.3%

 crypto:                454.6ms +/- 2.8%
   aes:                 214.2ms +/- 5.5%
   md5:                 120.2ms +/- 0.5%
   sha1:                120.2ms +/- 0.5%

 date:                  551.0ms +/- 2.9%
   format-tofte:        290.6ms +/- 5.3%
   format-xparb:        260.4ms +/- 0.3%

 math:                  638.6ms +/- 3.1%
   cordic:              278.2ms +/- 5.8%
   partial-sums:        206.2ms +/- 3.4%
   spectral-norm:       154.2ms +/- 4.3%

 regexp:                871.6ms +/- 2.5%
   dna:                 871.6ms +/- 2.5%

 string:               1959.0ms +/- 1.0%
   base64:              200.4ms +/- 0.3%
   fasta:               392.6ms +/- 1.3%
   tagcloud:            390.6ms +/- 2.4%
   unpack-code:         765.0ms +/- 0.9%
   validate-input:      210.4ms +/- 4.2%

Findings

Ranked from fastest to slowest overall:

1. Chrome — 2697.4ms
2. Safari — 6428.2ms
3. Firefox — 6506.0ms
4. Opera — 7536.2ms

Now I'm not a statistician, but Safari and Firefox yielded very similar results in the middle ground, while Chrome was the clear winner with Opera at the bottom (surprising, given the browser's reputation for performance). SunSpider has a nice feature that allows you to compare two result sets. The difference from fastest to slowest was a staggering 279% speed increase in Chrome over Opera. Of course a lot depends on what you're using JavaScript for, hence the breakdown into categories and different operations within those categories. If you enjoy pouring over raw data, by all means have at it.

On the Horizon

Over the past several months we've seen all manner of announcements and articles about JavaScript performance improvements and what to expect when this research and development makes its way into the mainstream. We've learned about trace trees, JIT compilers, direct-threaded, bytecode optimizers, and so on. Mozilla, for example, plans to roll out it's TraceMonkey engine with the release of Firefox 3.1. For the impatient, you can grab a copy of the 3.1 nightly builds and enable TraceMonkey now if you want to play with it or do your own testing. One can only speculate on how Google and Opera will respond to these latest developments.

Related Reading

• TraceMonkey Update (Brendan Eich)
• The Birth of a Faster Monkey (Mike Shaver)
• TraceMonkey (John Resig)
• Extreme JavaScript Performance (Ars Technica)
• SquirrelFish has Landed (Cameron Zwarich)

Joe Hewitt may be a lesser known member of the original three Firefox cast, but among DOM and JavaScript developers, his work is legendary. In a later Power Tools installment, I will cover in more detail the DOM Inspector, for which he is perhaps better known. At least until recently. This article focuses on FireBug, which Joe has been working on continuously of late (among other endeavors) and what he ultimately considers to be a DOM Inspector replacement.

The latest version of FireBug was released September 12th, 2008.

What in the hell is a FireBug?

I won't get into entomology—which ironically in Greek means "that which is cut in pieces"—although there really is such a thing as a firebug. The extension, on the other hand, is designed to make the Web developer's job a whole lot more productive. With it you can inspect and debug your markup, stylesheets, JavaScript, and even keep an eye on asynchronous XHR object calls back to your server.

Unlike the DOM Inspector, FireBug normally runs in a horizontal console (although you can open it in a separate browser window) underneath the document's rendered view. A statusbar icon indicates if there are any problems with the current page, which can indicate any number of conditions including errors, warnings and results from:

• JavaScript
• CSS
• XML
• XMLHttpRequest (aka XHR or Ajax)
• Chrome

and even problems encountered from remote domains—which can be the source of massive numbers of errors (I'll leave it to Joe to name names). Thankfully you can suppress these messages, or disable FireBug entirely for certain domains, through the options menu.

Almost every object in the FireBug interface is actually a hyperlink. Elements in the source view can be expanded or collapsed and your current XPath is displayed as you explore the document structure. Like the browser itself, views are toggled through a tabbed interface, which include Console, HTML, CSS, Script, DOM, and Net. Each tab has one or more sub-functions associated with that feature.

By using FireBug, you will quickly learn just how much is going on behind the scenes of even the simplest Web page.

Power Tools

• console.log()

Forget about using alert() to test or debug your scripts. By adding console object logging to your code you can pinpoint exactly what is going on, and even restrict messages according to different levels of severity including: informative, debug, warnings, or errors.

The console object also allows you to make assertions to more deeply test your code as well as performing stack traces, time sections of code, and log the number of times a function is called and has been executed.

All of the console logging methods can format strings using patterns similar to the C stdio printf() family of functions.

Command Line Functions

For command line junkies like me, console mode gives you access to a wealth of query and history/editing features you're probably already familiar with. Even more powerful are the following predefined shorthand functions:

• $("id") - A shortcut for document.getElementById().
• $$("css") - Returns an array of elements that match a CSS selector.
• $x("xpath") - Returns an array of elements that match an XPath selector.
• $0 - Variable containing the most recently inspected object.
• $1 - Variable containing the next most recently inspected object.
• $n(N) - Returns the Nth most recently inspected object.
• inspect(object) - Displays an object in the DOM Inspector.
• dir(object) - Returns an array of property/method names on an object (Python anyone?)
• clear() - Clears the console.

>>> inspect(document)

is a good place to get started.

CSS Quick Search

While in Inspect mode, you can use the quick search box to locate any element by entering a CSS selector. FireBug will display all matching elements in the console view, which you can then expand to view more details or switch tabs to explore the stylesheet that defines the rules for each element, the computed propeties and layout/display attributes, JavaScript events that are attached to the element, and even the gory details of DOM for the selected item.

You can also use quick search to match JavaScript events.

In the future, Joe plans on adding XPath search as well as plain text. For those in a hurry, you can try the getElementsBySelector() JavaScript function, which uses the Firefox XPath API to translate CSS selectors to XPath making them a lot faster than searching the DOM directly.

FireBug 1.2

Some of this material is a bit dated. For the latest on FireBug, visit the new Get FireBug Web site and in particular the "Learn more" feature links on the home page and the documentation section.

Wow, talk about a hiatus. Looking down at the previous post it's been over a year since the last time my shadow has darkened this doorway. Below are a few recent items of interest regarding development and the Web in general. To me at least. But who am I kidding? I must be the only person left who actually still reads this blog.

jQuery I spent a lot of time evaluating the myriad of JavaScript libraries out there and I've settled on a favorite. jQuery is compact, fast, powerful, easy to use, and extensible. If you haven't tried it, do yourself a favor and do so.

Chrome The long-awaited browser from Google, in beta naturally, has arrived for Windows XP and Vista. Versions for Linux and Mac are on the way. Built from WebCore (the rendering engine that forms half of Apple's open-source WebKit project), Mozilla's Firefox and V8, the open-source JavaScript engine from Google. Although you'd think they would come up with a more original name, one intriguing feature are tabs that sit externally at the top of the browser window and each one runs in its own virtual space, so one misbehaved Web application won't crash the entire browser. You can also monitor the amount of memory taken up, the amount of CPU used, and the network activity for each tab via the Task Manager.

Google Turns 10 Has it really been that long? Actually, Larry and Sergey first met in 1995 at Stanford where Larry was considering going to grad school and Sergey was assigned to show him around. The rest, as they say, is history. To the best of my knowledge, the magic 9-27-1998 date is when Google was officially incorporated.

Also long overdue, last month's DC PHP Developers Group (now located at the DC Greenpeace office) featured a presentation on the CodeIgniter open-source PHP Web application framework, by Oscar Merida and Matt Gibbs of Forum One. Next month will feature Barry Austin on MySQL Optimization for Developers.

Stay tuned, I may just be back sooner than 12 months. In fact, you can count on it.

Prototype version 1.5 has just been released and includes many enhancements and bug fixes. Best of all, excellent online API documentation. For more information on the latest version, visit the Prototype blog.

Joe Hewitt has announced the final release of FireBug 1.0. Rather than go into all the details about new features and enhancements here, I'm going to refer you to the Yahoo! User Interface Blog where you can view a lengthy video featuring Joe as he demos the new version. Joe has put an enormous amount of work into this extension, if you use it regularly and it saves you time and frustration, then consider helping out with a donation.

JavaScript development just keeps getting more efficient and powerful!

In my second visit to the DC PHP Developers group meeting I joined yet another over-crowded room of local programmers for this month's presentation. I really appreciate Robyn Wyrick's efforts to put these meetings together, but it's becoming clear that the venues provided by the National Press Building are faltering—a testament to the growing popularity of the group.

Jonathan Modell was tonight's presenter. A DC local, recently returning from a 10 year stint in Colorado (my home state, or more accurately I was born in Durango and then lived in Boulder for a year), Jon has extensive experience in many aspects of Web development.

His presentation focused on how he learned to integrate Ajax technology within a core PHP system. Obviously this is a hot topic, if somewhat too hot in my opinion. In a nutshell, Ajax allows you to create an HTTP request back to a server-side script, and then dynamically insert the results into your page via the DOM—all without having to POST or GET a new page (something most PHP programmers are well versed in).

Web-based applications that quietly introduced this technique are most famously associated with Google. First was "suggest" a sort of search as you type, and then Gmail and many others that began to reinvent how Web pages could improve interactivity. In truth, it was Microsoft (circa 2000) who first implemented the XMLHttpRequest (XHR) object in their version of JavaScript (jscript). Later browsers (Firefox, Safari, et al.) followed suit.

As the function implies, the traditional payload of a server-side script called by an XHR request is XML. I know of very few people that continue to do this. By far the simplest method of dynamically insterting results into your page is to use a element with a unique id, initially hidden via CSS, then grab the data returned as normal markup (for instance a set of unordered list elements), then use innerHTML to update the DOM, and finally "unhide" the element (typically a <div>). This technique is sometimes referred to as AHAH.

JSON is another lightweight technique for returning data to the requestor. It's basically serialized JavaScript in the form of name/value pairs that you eval() on the client-side for parsing and insertion into your page. In addition to JSON, the Yahoo! Developer Network set of Web services are able to return serialized PHP. Although not as applicable to an Ajax implementation, it is none-the-less an interesting method worth investigating. If there is such a beast as a JavaScript unserialize PHP function or class out there, by all means drop me a comment. For PHP developers interested in available packages for encoding and decoding JSON data, visit this comparison of PHP libraries. As of PHP version 5.2.0, JSON support is native.

In the early stages of his presentation, Jon confessed to having tested many of the Ajax JavaScript libraries that are floating around out there, and then spoke highly of his choice to use Sam Stephenson's Prototype. He is not alone, not by a long shot. There are a number of frameworks that are built on top of Prototype: RoR, Rico, and "effects" libraries that include script.aculo.us and moo.fx. PHP frameworks with built-in Ajax support include CakePHP and ModX.

If you are doing this sort of development work, I cannot emphasize enough how much Joe Hewitt's fantastic FireBug Firefox extension will save you hours of headaches.

To conclude his presentation, Jon demoed a social networking application that displays a calendar of events and the members who are attending, locations, dates, and so on. I came away with the feeling that traditionalists in the audience were impressed how the page would update without the need to refresh it. But keep in mind that is the nature of asynchronous requests. There is nothing particularly new going on here, these are normal HTTP requests, they just happen to occur in the background via JavaScript and a little DOM magic to alter the page on the fly.

Yahoo! has just upgraded their Maps Beta product. For end-users, you now have Satellite and Hybrid views. A major complaint from many users to date has been the lack of maps outside the US. They are now rolling out coverage across the globe, although from my tests the results are still pretty limited. For a couple of examples, check out:

• Hong Kong
• Stuttgart

For developers, several of the Map APIs have also been upgraded to Version 3. These include:

• Ajax Getting Started Guide
• ActionScript/Flash API Guide

Why it's taking so long for a killer mashup that integrates geotagged Flickr photos with Yahoo! Maps Beta is a mystery to me, although I can guess who is working on it. To stay up to date on the latest development news, join the Yahoo! Maps Developer Community.

There is never any need to get lost.

A few days ago an informal poll appeared on the Digital Web news page asking visitors if they are Formally Educated or Self-Taught? I was surprised by the large number of respondants (many of them highly influential developers) stating they are mostly self-taught.

Another prevalent thread running through the comments is the concept of learning by observation, or what I like to call "how'd they do that?" In order to understand a technique, one of the best methods is to study source code. This is easy enough to do with any browser, and Firefox has some extensions that make it even easier. On my own Web site I try to expose as much as possible, including the markup, PHP source code, I also list my CSS and JavaScript files in the sitemap, and so on. These are just niceties, because other than code originating on the server-side (PHP for example), anything delivered to the user-agent is viewable in source form. Unless you're in the obfuscation camp, which I'm not here to discuss (shame on you if you are).

By now you may have heard of Ajax, and the booming trend in dynamic or DOM or client-side scripting that goes along with it. In other words, JavaScript is red-hot right now. If you're just getting into scripting, then this is a damn fine time to be learning by studying the code that drives all this stuff. It's also a fine time to be learning JavaScript because its reputation as a toy language with many poor examples is quickly being replaced by a new-found respect and clean, structured code.

As far as JavaScript code goes, there are a couple of different sources you're likely to run into. Embedded JavaScript can be found right in the markup. This is still almost as common as it is a bad practice. So there you are, back to viewing the page markup. Often this practice is made even worse by code that is disorganized and dispersed all over the place. There is also inline JavaScript, most often used to fire on certain events such as onclick, but I'm not going to get into that here. Likewise for so-called "javascript:" protocol URLs, such as those used by bookmarklets.

A better solution is to use the src attribute of the <script> element to include external libraries of code. Some developers claim this can cause the page to load more slowly since it involves an extra HTTP GET request for each included JavaScript source file. In my opinion modularity, code maintenance and browser caching of the external scripts easily trumps these concerns.

So once you land on that page with the fancy JavaScript effects, what is the best way to study the techniques being used? One method is to open the source of the page, locate the code embedded in it, or in the case of external source, copy the URL to the file and make a separate request with your browser. Using this rather tedious method for external code with Firefox and most other browsers will result in the code being displayed in a window as plain text, although IE has a nasty habit of prompting you to download the file rather than simply displaying it.

A more elegant solution is to use JSView, a Firefox extension which will open up separate view-source windows for any or all external JavaScript files referenced by the current page (it will do the same thing for external CSS). I find this method acceptable if I only want to look at a particular file, and it sure beats hunting through the markup, copying (and possibly having to modify "../.." paths) then pasting the URL into the address bar of a another tab or window so you can continue to view and test the rendered page.

But this method only works for external source code. Some pages use a mixture of external files and embedded code. In these cases, the all-powerful Web Developer extension really shines. From the Information menu, select "View Javascript" and the extension opens a new tab with all the JavaScript from the current page concatenated into one view. Code from external files are labeled as such with links to the files, and embedded JavaScript is labeled as "Inline Script" referencing the document that defined it. The code appears in source-order, or in other words in exactly the same sequence as it is appears in the markup.

But source order is not important to the JavaScript interpreter embedded in your Web browser. It simply builds a collection of objects after receiving and parsing each form of source code, and then waits for some event to fire that will trigger the intended behavior. If you think in these terms, which I recommend, then Steve Chipman's JavaScript Object Tree favelet/bookmarket is the way to go. To use it, simply drag a copy of the link to your bookmarks toolbar, then on the page you want to study click the link. A new <div> element appears overlaying the top portion of the document and in it you will find a collapsed tree-view of every object type defined by that page. Object types include functions, objects (arrays, dates, etc.), strings, numbers, and so on. To expand an object type into a list of its members, just click on it. To view the value of an object, which in the case of a function is its source code, just click on the item by name. You can easily collapse parts of the tree in the same manner.

Another really handy favelet is Shaun Inman's View Rendered Source, which also overlays the current document with source code, but not JavaScript code. Rather, it displays the browser's internal view of the markup after any changes are made to the DOM. For example, if a script is using Ajax to insert new elements into the document tree and you want to observe the results, then the script will give you a before and after snapshot of the markup.

Remember that observation and studying working examples are powerful ways to learn how Web software is built, and a great way to improve your skills. Whether you are a new or a seasoned JavaScript developer, if you plan on studying code in the wild then Firefox and its many extensions, and any number of other tools (I'm just scratching the surface here) are the way to go.

On a tip from Krista at Digital Web Magazine, I learned that O'Reilly's seminal Web Design in a Nutshell by Jennifer Niederst was recently released in a 3rd edition. This is good news since the 2nd one was getting a little dog-eared and needed to play catch-up with the latest trends and techniques. I hope O'Reilly is planning on doing the same for Webmaster in a Nutshell.

Acclaimed accessibility advocate Derek Featherstone and Digital Web contributing author Aaron Gustafson both invested some of their time in the Nutshell project, and today A List Apart has published an excerpt from Aaron's work titled Getting Started with Ajax. The article does a good job of introducing Ajax concepts, including the JavaScript XMLHttpRequest object, various data formats that can be returned from such calls, and how to update the DOM of the page with the requested data. Aaron uses the simple XHConn interface library in his examples, and provides sample code, both markup and JavaScript. Keep in mind that ALA is not a programmer's magazine (any more than Digital Web is), so do not expect gory details here. But it is important for designers to understand Ajax development since it is a client-side technology. Or at least the designer's half of the equation.

And this leads to my point, something I plan on asking as many designers as I can corner at SXSW—in this day of Rich Internet/Web applications and Ajax (I really hate to mention Web 2.0), do you see the line between designer and programmer blurring a bit more? If you're not able to make it to the convention, feel free to post your viewpoints here, regardless of whether your area of expertise is design or code.