jQTouch is an amazing project spearheaded by @davidkaneda and has been promoted by many people including @jonathanstark. jQTouch, if you ain’t know, is a JavaScript library dependent on jQuery and is intended for making mobile webapps targetted for the iPhone. jQTouch is an absolutely brilliant piece of work where one can take the default project, modify the index.html with their markup, change some simple JavaScript, and within minutes one has a mobile webapp that looks like a native iPhone app. I have used jQTouch for rapid prototyping efforts and have been repeatedly blown away at how fast I can take a concept and have it “working” on an iPhone in such a short amount of time.

However, jQTouch, is only for building something that is specifically targeted for the iPhone. That approach, in my opinion, is flawed. The browsing experience of a jQTouch webapp on an Android device is awkward at best and crashes the browser altogether at worst. jQTouch will be similar to the problem that arose when people were building webapps where Internet Explorer was required and was “best viewed in a 1024px x 768px” screen resolution. We all know how successful that approach was.

In my opinion, one needs to design, architect, and develop sites, apps, and experiences, universally. That is not to say you can’t take advantage of some of the cool things the iPhone browser has over some of the other devices’ browsers (hardware accelerated transitions FTMFW), but note that creating a mobile webapp that is supposed to simulate a native iPhone experience creates at best, a lackluster experience for (almost) all the other internet friendly mobile devices.

Moreover, Android’s market share is rising…fast. iPhone’s market share is not that safe. Why? iPhone is a device. Android is a platform for devices. There will be thousands of Android devices by this time next year. There will still only be one iPhone. Moreover, Palm, Blackberry, and Nokia appear to be moving to webkit as well. Do you really want your mobile webapp to look like an iPhone app on a Blackberry Curve?

And if you needed more proof that providing a “native iPhone mobile app experience” for all mobile apps is the wrong approach, look no further than a recent article on ReadWriteWeb where mobile stat guru, Taptu, explains the future of the web is to be dominated by cross-platform based mobile websites that are “mobile web touch-friendly”. So while it currently may be trendy to design and develop strictly for the iPhone (because it dominates in mobile browsing market share), one may be shooting one’s self in the foot in the process. Moreover, with so many various touch screen devices coming to market from the iPad to Archos, Acer, the HP Slate, and various Android and Chrome OS tablets, doesn’t it make sense to design and develop for various mobile platforms that support touch events? Why limit yourself to the experience that is only on the iPhone?

But Joe, I only want to design for the iPhone. Great! Meanwhile me and the rest of the world will be designing for iPhone and everybody else. But Joe, jQTouch makes it so easy! I know, suck it up and build your own framework. Get smarter, get better, design something, destroy it, start all over, and then do that again. Now you are ready for the mobile web.

Disclaimer: I have had a G1 since October 2008 and have developed a few Android apps (none publicly released yet, but soon will be). The majority of my bias may come from the upgrade to the Android source (2.1 as of this writing) coupled with a number of hardware related upgrades.

Pros

• Snapdragon 1Ghz processer’s snappy-ness
• The orientation change’s (switching from landscape to portrait and vice versa) responsiveness
• The screen’s clarity and fidelity
• Five pages/screens of “home desktop” real estate
• Voice commands for nearly everything
• 5MP Camera with LED Flash
• Video recording in MPEG-4 quality
• Navigation mode with Street View
• Live Wallpapers
• Auto-adjusting display brightness

Cons

• Haptic response keys’ awkward experience
• No orientation change on home screen(s) plus a bug when attempting to do so
• Power button only means of “awaking” the device
• Gallery application interaction issues
• Unlock screen’s awkward “slide” gesture
• Text input in landscape mode’s poor experience

Programmer’s Perspective

By seeing such features as the Navigation and even the street views available in Google Maps, I have become motivated to start utilizing those APIs or consider using some of the additional features of the Android SDK that I did not consider before, mainly because the phone itself is fast enough at rendering something like Streetview in a rather seamless fashion. Seeing what Google has done with some of their own apps, coupled with the overall speed improvements between orientation changes inspires me no longer worry about programming against a poor experience. However, the speech-to-text feature, and its inclusion in nearly all of the input fields on the device, gave me glimpse into the future of Google’s approach to allowing that faster mobile processor to remain just that: fast.

The speech-to-text feature processes all its data in the cloud. This concept is not something that should be taken lightly. The processing power needed to handle something as complex as speech-to-text recognition would bring the 1Ghz Snapdragon chip to a crawl. However, Android, and more importantly Google is relying on this processing to take place elsewhere (the cloud) and instead rely on the data transfer (and the subsequent data networks) and ultimately the speed of the transfer to create a seamless and pleasant user experience.

The text-to-speech feature is not unique to the Nexus One, but its pervasiveness across input types is (so far). Furthermore, the front and back microphones (for improved noise cancellation) installed on the Nexus One shows a commitment of sorts toward the idea of “more speaking, less typing”. This is inspiring from a programmer’s perspective for if Google does in fact adapt this model for let’s say something like, potentially the managing, streaming, or recording of 3-D camera data, and they handle the intensive processing, but we simply receive back data, then the sky (or cloud) is the limit. The services provided by Google (or potentially other cloud-processing/SaaS vendors) would offload the heavy lifting for programmers so the programmers can focus on creating bleeding edge apps without worrying about the processor’s ability to crunch loads of data. This, from my perspective, is huge.

UI Engineer’s Perspective

Where to begin. The richness and clarity of the screen is enough to make any UI engineer anxious to create an app that simply cycles through RGB values. The AMOLED screen is now more like a canvas. This not only provides obvious benefits for the visual designer but can also pose a problem in regards to fragmentation across devices’ screen resolutions. I think we’ve dealt with issues like this before.

The new animations and simulated 3-D environments across many of the apps including the “Starwars” rollover effect for the Home screen lend to the notion of more animations coming available to the UI designer.  The Android SDK comes packaged with some preset animations, but it is interesting to see how Google is using some of the newer animations/transitions on the Nexus One running Android 2.1.

Google has also paid attention to even subtle improvements at interactions with the UI at the application level.  For example, the browser renders pages much faster and if the page is a standard site, not a mobile version, it shows the page in nearly in full with the ability of double-tapping to zoom in to the area you wish to see at a more granular level.  The double-tap is way more intuitive than the earlier quasi-magnifying glass click then drag and release awkward interaction.  Note, this interaction is an Android 2.0 version improvement, not unique to the Nexus One (Motorola Droid).

I would be remiss not discuss the newest bit of eye candy for the UI engineers:  Live Wallpapers.  The live, moving, seemingly breathing wallpapers that shipped with the Nexus One are definitely the first thing one notices when you turn on the Nexus One.  Not only are the wallpapers animated and full of color, but that are fully interactive as well.  For example, the “rippling water” live wallpaper not only has leaves falling onto the pool of water thus causing a rippling effect, but a tap anywhere on the desktop of the home screen not occupied by an app or widget shortcut triggers the same rippling effect as if you had actually touched the water.  How practical and useful is something like this?  Well not so much.  What is important is the fact the the animation library Processing was used on a couple of the early prototypes (according to Romain Guy) and an API for developing live wallpapers is due out in the Android 2.1 SDK release.  The potential for using Google’s version of a Processing-like class for other uses than actually making live wallpapers is really inspiring.

Final Analysis

Most of what the Nexus One offers as a mobile smart/superphone is not anything game-changing for the device itself or the mobile smart/superphone market.  Yet, the Nexus One is not just another smartphone, but more of a showcase of what the Android platform is capable of doing.  Given the right hardware and knowledge of the Android platform (and potentially C and/or Linux), vendors and developers can create Android-based devices with the ability of being game-changing or even create new categories for devices altogether.  A touchscreen tablet for web browsing?  E-readers?  Live TV-streaming devices that fit in your pocket?  All of these are possible.  However, to simply compare the Nexus One next to an iPhone, Palm Pre, or any other slew of mobile smartphone devices, is not, in my opinion the correct comparison.  Android is to mobile what Windows is to desktop PCs.  The Nexus One just happens to have a telephony as a feature of this mobile device.

So after doing some digging I found an article somewhat related that called for modifying your hosts file.  However, this didn’t work for me either.

So it was onto Android’s online documentation.  Yikes, I know.  Nonetheless, I found EXACTLY what I was looking for almost immediately.  According to the authors of this section of the documentation

Each instance of the emulator runs behind a virtual router/firewall service that isolates it from your development machine’s network interfaces and settings and from the internet. An emulated device can not see your development machine or other emulator instances on the network. Instead, it sees only that it is connected through Ethernet to a router/firewall.

As it turns out the virtual router that is running actually has its own internal loopback interface which is the same as the loopback interface address on my development machine, 127.0.0.1.  However, the key is the special alias that the virtual router provides to your localhost’s loopback interface, that address is 10.0.2.2.

So just type http://10.0.2.2 into the browser from the Android emulator and you’ll be requesting from http://127.0.0.1 on your development machine.

Not anymore, with applications like Dropbox, XAMPP, Digsby, and Skype, and using them together in methods that exploit their awesome utility when combined.

Dropbox

For those of you that aren’t familiar with Dropbox, in a nutshell, Dropbox is the easiest way to share and store your files online. It works on any platform as well. Brendan has a Mac and I have a PC and it works flawlessly on both of our machines. Let’s say you have a home desktop computer, a personal laptop, a work laptop, and a work desktop computer. Once you install Dropbox’s application on each of those computers, you will have access to any files you store in your “My Dropbox” folder on any of the computers. For example, say you have a TPS Report that you save in your “My Dropbox” folder on your work desktop computer. With Dropbox running on each of the other three computers, they each will automagically have that same file stored in their “My Dropbox” folder as well. Moreover, say you get home and on your personal laptop you make a change to the file. The delta (the difference or change to the file) is the only thing uploaded to your Dropbox account and a revision is created for that save (or in subversion terms “commit”). Now, that file on every other computer is automagically updated with the new version of the file. If you need to revert back to a previous file version, just open up the revision that you need. Simply brilliant.

Now, one of the coolest features for Dropbox is that you can create a folder and share that entire folder with anyone you invite. For example, I created a folder called “joe_paddy” (Paddy is Brendan’s nickname), right-clicked on the folder and under the Dropbox menu selected “Sharing Options”.

Sharing Options with Dropbox

My browser then immediately opened up my Dropbox account page where this folder, “joe_paddy”, resides. On this page, there is a box where I simply add Brendan’s email address to invite him, but, I could have invited as many people as I wanted to have access to the folder, granted they each have a Dropbox account. Upon accepting my invitation, the folder “joe_paddy” was instantly created on his computer.

Sharing Folder via Email Address in Dropbox

The beauty of this is now Brendan, the visual designer, can work directly out of the “joe_paddy” folder and I will receive any/all files and changes to those files in nearly real-time. On the flip side, since I’m the one building out the web pages (HTML via PHP, CSS, and JavaScript), any changes I make are reflected immediately on his computer as well. But Joe, he can’t just open a PHP file and it render in a browser, it needs to be served up from a well, server! That’s where XAMPP comes in.

XAMPP

XAMPP is an easy to install Apache distribution containing MySQL, PHP and Perl. XAMPP is really very easy to install and to use – just download, extract and start. Currently, XAMPP is available for Windows, OS X, Linux, and Solaris. XAMPP assists with a distributed collaboration environment when it is coupled with the use of Dropbox.

For example, Brendan and I are collaborating on a website right now. He is handling the design composition in Photoshop, slicing up images, and creating a style guide. If you don’t currently use a style guide in your projects, I highly recommend you do. In a nutshell, it is a document combining all typefaces, typeface sizes, and typeface colors and colors for other elements (e.g. background color) used in the design composition so the developer doesn’t have to refer to anything but the style guide when hashing out the CSS. Okay, so back to the example, Brendan is doing the visual stuff and I am building out the pages in PHP. Now, if I am making a change to the PHP file and I want Brendan to be able to open a browser and see the webpage in its current state, he can’t do this without a server running. He installs XAMPP for his platform, OS X, and he now has a “local” server up and running, http://localhost/. However, the default httpd.conf file has the document root set to the htdocs folder under the XAMPP install folder. On Windows, that location is here: C:\xampp\htdocs. Unfortunatey, we don’t want to see XAMPP’s local site that is bundled with the application, we want to see our site that we are working on.

At this point, I opened the httpd.conf file and found the lines that I needed to modify in order to point the document root to the directory of where I’m building the site out. First line is of course, the DocumentRoot setting. The value for the DocumentRoot should be the full path to the folder that is where I am building the web pages. This path contains my “My Dropbox” folder.

httpd.conf DocumentRoot Setting

The only other line I needed to change was the <Directory> setting as it was pointing to the htdocs folder under the XAMPP install directory and instead needs to be pointing

httpd.conf Setting for Proper Directory Path

After making these two changes to my httpd.conf file, I save it, close it, and restart Apache using XAMPP’s slick control panel. Simply stop Apache…

XAMPP Control Panel - Stop Apache Service

…then start it,

XAMPP Control Panel -- Start Apache Service

…then navigate to http://localhost/ in your browser and voilà, I am now able to see the website on my local server.

In most cases, trying to get a designer to modify an httpd.conf file can be very difficult, mainly because they are not as technical as developers. Not a problem in our case, for using Digsby as my instant messenger client I am easily able to direct Brendan on what lines in the httpd.conf file need to be modified.

Digsby (and Adium and Skype)

Digsby is an all encompassing instant messaging, email, and social networking client that I have found to be incredibly stable and abundantly useful for not only instant messaging, but keeping up with new emails in my Gmail account, new message on Facebook, LinkedIn, Myspace, etc. Digsby is a one stop shop for all of my communication needs.

After adding my GTalk account to Digsby (and after Brendan installed XAMPP on his Mac), I was able to communicate directly with Brendan and guide him through the httpd.conf file in order for him to modify the two lines of code needed to point to the folder we were sharing to build the website. Moreover, we were then actually able to collaborate and make changes in near real-time. For example, if we are looking at the “About” page of this particular website, he can tell me that the border of an image needs to be red. I simply make the change in the proper CSS file, save that CSS file, then have Brendan reload his browser and BAM, the image has the border. The magic lies in the fact that Dropbox only uploads and subsequently downloads the delta (what was saved in the CSS file), not the entire file!

If you’re on a Mac, I hear Adium is a great instant messaging solution.

Now, if you’re more of a vocal and visual person or just prefer to talk on the phone with folks, Skype may be an even better solution that Digsby. Skype is great Video Chat and VOIP phone service that not only has an instant messaging client, but has the ability for you and another person to physically chat with one another and even see the person as well! All you need to do is install Skype and hook up your web camera and microphone. Me and my three brothers have the following camera, which is in HD and has a microphone built in: Logitech QuickCam Pro 9000. Super easy to install and use; I highly recommend this one.

Conclusion

So the combination of the aforementioned resources has enabled myself and Brendan to successfully build out the website plus, it has enabled us to confidently take on any additional projects with which we may be presented. The best part about it? All of these resources are FREE. Moreover, I believe I’ve only scratched the surface here with this concept of “distributed collaboration” as I’m sure many out there have their own tricks and tips. So share them in the comments!

Click the following link to test it out:

3.ly Bookmarklet

You can also drag that link to your bookmarks to make use of it for later.  As usual you can find this and other projects I’ve completed to improve your browsing experience on my Projects page.

Click the following link to test it out:

Tr.im Bookmarklet

You can also drag that link to your bookmarks to make use of it for later.  As usual you can find this and other projects I’ve completed to improve your browsing experience on my Projects page.

Recently, Kyle gave a talk on how to download scripts in parallel, something Steve Souders and a few others have discussed how to do effectively. Kyle wrote his own, JavaScript library/framework-agnostic library (for lack of a better term) to allow for parallel script downloading with our without blocking (think dependencies). He presented this project of his at our meetup in June, and thus LABjs was born.

Some History on <script> Tags and Performance

If you’ve ever been to a website like Mashable.com or Marketwatch.com or a slew of other sites that seem to take FOREVER to download even with a high-speed connection, then you’ve probably been the victim of multiple <script> tags blocking the page from fully downloading, and ultimately rendering. Sorry in advance for picking on Mashable, but the home page had a whopping 59 JavaScript requests when I went to it today so it is a perfect candidate for LABjs’s usage, or simply some JavaScript loading optimization of some kind.

So why is this bad? Well, <script> tags, when they download, block other assets from downloading to fully render the page. As a result, a user’s experience with the webpage is severely degraded as that page may take significantly longer to download and subsequently render because the browser is unable to download anything else while the <script> tag is “bogarting” the download queue. Steve Souders provides an excellent demo of this problem here.

Download Without Blocking

So how do we avoid or at least minimize the deterioration of the user experience from the blocking associated with multiple <script> tag requests? That is where LABjs comes in. LABjs, an acronym for “Loading and Blocking JavaScript”, uses well known, yet clever techniques for adding script tags in a manner that allows for non-blocking, parallel downloads.

A quick and easy example of this can be seen in the following code on this demo page.

Upon page load, a quick inspection of the Net tab in Firebug yields the following results:

What should be noted here is how JavaScript files are being downloading not only with other JavaScript files, but images as well. The process could not have been simpler either.

<head>
 <script type="text/javascript" src="js/LAB.js">
 </script>
 <script type="text/javascript" src="js/load.js">
 </script>
</head>

In the <head> tag we only need to include the request to the LAB.js library file and then a file I called load.js which contains the following LAB API calls.

$LAB
.script("http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js", "http://www.google-analytics.com/ga.js")
.block(function(){
 pageTracker = _gat._getTracker("UA-3312370-2");
 pageTracker._trackPageview();
});

If you notice, I am making a call to the script() method passing in a request for the latest version of jQuery and the Google Analytics tracking script. The next is a block() method call that handles my Google Analytics tracking. Even though this example was to show a simple use of the LABjs API, I did add this block of code for my own personal tracking statistics. The block() method call is not required for this example to work.

Downloading with Dependencies

One of the best features that puts LABjs ahead of other methods and frameworks that produce similar results is that LABjs allows for you to load a file, say the latest version of jQuery, and then run some code that is dependent on that file’s existence.

An example of using LABjs with dependencies can be seen in the following code on this demo page.

Upon page load, a quick inspection of the Net tab in Firebug yields the following results:

What is important to note here is the times and places where global.js and the __utm.gif tracking image were downloaded: global.js is dependent on the jQuery library to execute some code and the tracking image is a result of the Google Analytics script executing the tracking code. These files were downloaded (and executed) after their dependent files were fully downloaded, the result of the block() method call. The ease of use and the robustness of dependency management coupled with non-blocking script downloads should be evident with this example.

The Conventional Route

Of course, I have to show the same page using the conventional approach of multiple <script> tags. The demo is here.

Upon page load, a quick inspection of the Net tab in Firebug yields the following results:

As you can clearly see, the blockage from the JavaScript requests denies any other asset from downloading until the JavaScript file has completely downloaded. Even with this simple example, it took 3.43 seconds to render the page as compared to the prior example coming in at only 2.35 seconds a difference of 68.5%. The numerical results themselves should be reason enough to use LABjs.

Where Can I Get It

LAB.js can be found at the humble site, LABjs.com where you can download a zip file of the code with some examples. LABjs is maintained by Kyle himself and he is incredibly responsive to questions or requests so be sure to follow him on twitter.

Many new web designers/developers that start to use jQuery usually write their first block of code starting with something like the following:

$(document).ready(function(){
    alert("Hello Whirled");
});

However, if you ask most people what is happening here, most likely the response is, “When the DOM is ready, I show an alert popup with the text ‘Hello Whirled’”.  However, there is no “DOM Ready” event in JavaScript; it is a rather ingenious method that will execute a block of JavaScript before the page has finished loading.  The benefits to having some JavaScript executed before the page has finished loading are immense, for one may need to manipulate the DOM prior to the page fully rendering, possibly some user agent detection, or whatever.  Waiting to execute that code using the traditional window.onload method doesn’t allow us to do these things.  But what is really happening when you call the ready() method?  I aim to sort that out from a technical perspective in this article.

Ready?

The ready() method does three things when it is called:

1. Attaches listeners to the method by calling the bindReady() function.
2. Checks to see if jQuery.isReady property is true and if it is, it executes the function immediately.
3. Otherwise, it adds it to the stack (array) of functions to be executed when jQuery.isReady is in fact true.

jQuery.fn.extend({
    /* ... */
    ready: function(fn){
        // Attach the listeners
        bindReady();
        // If the DOM is already ready
        if (jQuery.isReady)
            // Execute the function immediately
            fn.call(document, jQuery);
        // Otherwise, remember the function for later
        else
            // Add the function to the wait list
            jQuery.readyList.push(fn);
        return this;
    }
});

The majority of the magic happens inside the bindReady() function:

var readyBound = false;
function bindReady(){
    if (readyBound)
        return;
    readyBound = true;
    // Mozilla, Opera and webkit nightlies currently support this event
    if (document.addEventListener) {
        // Use the handy event callback
        document.addEventListener("DOMContentLoaded", function(){
            document.removeEventListener("DOMContentLoaded", arguments.callee, false);
            jQuery.ready();
        }, false);
        // If IE event model is used
    }
    else
        if (document.attachEvent) {
            // ensure firing before onload,
            // maybe late but safe also for iframes
            document.attachEvent("onreadystatechange", function(){
                if (document.readyState === "complete") {
                    document.detachEvent("onreadystatechange", arguments.callee);
                    jQuery.ready();
                }
            });
            // If IE and not an iframe
            // continually check to see if the document is ready
            if (document.documentElement.doScroll && window == window.top)
                (function(){
                    if (jQuery.isReady)
                        return;
                    try {
                        // If IE is used, use the trick by Diego Perini
                        // http://javascript.nwbox.com/IEContentLoaded/
                        document.documentElement.doScroll("left");
                    }
                    catch (error) {
                        setTimeout(arguments.callee, 0);
                        return;
                    }
                    // and execute any waiting functions
                    jQuery.ready();
                })();
        }
    // A fallback to window.onload, that will always work
    jQuery.event.add(window, "load", jQuery.ready);
}

That’s a good bit of code, so let’s break it down into digestible chunks.

Standards-Compliant Browsers

The first, and most trivial check, is to see whether or not the readyBound variable is true and if it is, then we’re done! Otherwise, let’s set it to true now because when we only want/need to bind the handlers once.

if (readyBound)
    return;
readyBound = true;

Next, we see an example of browser feature detection being used for executing a particular block of code. Most standards-compliant browsers support the addEventListener() method. By passing the DOMContentLoaded event to the addEventListener() function we are telling the browser to “listen” for the event that is fired when a document’s DOM content has finished loading. The anonymous callback function that is passed as the second parameter to addEventListenter() is then executed when that event has fired. This anonymous event handler function removes itself (referenced via arguments.callee) from being bound to the document once it has been called. Finally, we call the jQuery utility method jQuery.ready(). We will discuss this method later on.

// Mozilla, Opera and webkit nightlies currently support this event
if (document.addEventListener) {
    // Use the handy event callback
    document.addEventListener("DOMContentLoaded", function(){
        document.removeEventListener("DOMContentLoaded", arguments.callee, false);
        jQuery.ready();
    }, false);
    // If IE event model is used
}

Internet Explorer is Special

In the next block of code, this bit of feature detection checks to see if Internet Explorer’s event model is used. To handle iframes, we need to “listen” for a “complete” response from the request sent by that iframe. document.attachEvent("onreadystatechange", function(){...}) handles this and fires the anonymous function when that response arrives. If it is in fact a “complete” response, then, similar to how we did before, the event is detached (no longer listening), document.detachEvent("onreadystatechange", arguments.callee) and the jQuery.ready() utility method is called.

 // Mozilla, Opera and webkit nightlies currently support this event
if (document.addEventListener) {
    // Use the handy event callback
    document.addEventListener("DOMContentLoaded", function(){
        document.removeEventListener("DOMContentLoaded", arguments.callee, false);
        jQuery.ready();
    }, false);
    // If IE event model is used
}

else
    if (document.attachEvent) {
        // ensure firing before onload,
        // maybe late but safe also for iframes
        document.attachEvent("onreadystatechange", function(){
            if (document.readyState === "complete") {
                document.detachEvent("onreadystatechange", arguments.callee);
                jQuery.ready();
            }
        });
        // If IE and not an iframe
        // continually check to see if the document is ready
        if (document.documentElement.doScroll && window == window.top)
            (function(){
                if (jQuery.isReady)
                    return;
                try {
                    // If IE is used, use the trick by Diego Perini
                    // http://javascript.nwbox.com/IEContentLoaded/
                    document.documentElement.doScroll("left");
                }
                catch (error) {
                    setTimeout(arguments.callee, 0);
                    return;
                }
                // and execute any waiting functions
                jQuery.ready();
            })();
    }

If we are not using iframes, then some true JavaScript trickery is used, so naturally we first want to verify that we are in fact using Internet Explorer and that it is not an iframe:

if (document.documentElement.doScroll && window == window.top)

Now, the good part. We have a self-invoking function that first, checks to see if the jQuery.ready property is true, for if it is then we return. Next, we use a trick (hack) by Diego Perini to see if the DOM Content is loaded by using the doScroll() method in a try/catch polling loop. This triggers the jQuery.ready() utility method when no errors are returned by the doScroll(). Pretty slick and a nice find by Diego. The catch(error) statement here is worth noting as the line containing the code setTimeout(arguments.callee, 0); essentially keeps calling this anonymous function until there are in fact NO errors, which then calls the jQuery.ready() utility method.

     (function(){
        if (jQuery.isReady)
            return;
        try {
            // If IE is used, use the trick by Diego Perini
            // http://javascript.nwbox.com/IEContentLoaded/
            document.documentElement.doScroll("left");
        }
        catch (error) {
            setTimeout(arguments.callee, 0);
            return;
        }
        // and execute any waiting functions
        jQuery.ready();
    })();

If all of this fails, then we simply attach a load event, to the window object, and THEN call the jQuery.ready utility method when this event has fired.

 // A fallback to window.onload, that will always work
jQuery.event.add(window, "load", jQuery.ready)

Where Am I?

Let’s recap where we’re at. By now, we have determined that either the DOM Content is loaded, regardless of the browser, OR we are falling back on the fail-safe window.onload() method. Now, we just need to execute the jQuery.ready() utility method.

jQuery.extend({
    isReady: false,
    readyList: [],
    // Handle when the DOM is ready
    ready: function(){
        // Make sure that the DOM is not already loaded
        if (!jQuery.isReady) {
            // Remember that the DOM is ready
            jQuery.isReady = true;
            // If there are functions bound, to execute
            if (jQuery.readyList) {
                // Execute all of them
                jQuery.each(jQuery.readyList, function(){
                    this.call(document, jQuery);
                });
                // Reset the list of functions
                jQuery.readyList = null;
            }
            // Trigger any bound ready events
            jQuery(document).triggerHandler("ready");
        }
    }
});

The jQuery.ready() utility method is concise and elegant in its design. It starts off by checking to see if the DOM is already loaded and if it is, then we skip to the last line of code in the ready method definition. If the DOM is not loaded, then we set it to be loaded if this method is called again some time in the future.  Then we check to see if the readyList property of the jQuery object (an array of functions) has a “truthyness” value of true, as it is null by default.  If it is true, then we pass this array of functions into the jQuery utility method, jQuery.each(), and iterate over each element of the array.  The second parameter of the jQuery.each() method is an anonymous function that is executed over each iteration.  In this case, we are calling each function in the readyList in the context of the document and passing the jQuery object parameter to each function so it may be used within that function call:  this.call(document, jQuery);

After we have iterated over the array of functions we then set the jQuery.readyList value to null, since we just executed all of those functions there is no need to keep track of them for the next potential jQuery.ready() utility method call.  Finally, we trigger any events that may have been bound to the ready event using the triggerHandler() method.

Indirect Call of Ready Method

Earlier I mentioned there was a third way of calling the jQuery.ready() method, namely $(function(){...}). By first glance, one may posit what exactly is going on here and how does it correlate to a ready() method call? First, we are creating a new jQuery object with the common $() notation. However, instead of passing in a selector such as $('#myDiv'), we are passing in an anonymous function. If you view the source code of jQuery 1.3.2, you will come across this block of code at line 80:

		// HANDLE: $(function)
		// Shortcut for document ready
		} else if ( jQuery.isFunction( selector ) )
			return jQuery( document ).ready( selector );

This code is found within the init() method of the jQuery object and is the final check in the init method to see if the value passed in, selector, is a function and if it is, then it returns a call to the ready() method passing in the anonymous function as the parameter. So the ready() method is still being called, just indirectly.

Thoughts?

Attempting to break the DOM Ready method down into bite-size pieces and still be comprehensible was no easy task. Please let me know if this article helps you out or if there is anything I can do to improve it. Thanks!

UPDATE: Hat tip to @getify for some quality feedback to improve this article.

In her code, she has an object method defined in the following manner:

myFeature.$section_nav = $('ul/>').attr('id','section_nav').prependTo(myfeature.$container);

Absolutely nothing wrong with this code and it reads well and works fine. However, it is slightly different than the way I write my code when I’m dynamically creating and appending elements to the DOM. Typically, instead of creating an element and passing it to the jQuery method, I find the element I want to append the element to and then simply call the append method passing in a block of HTML. Again, nothing fancy, but the key difference I picked up on was that when I pass a block of HTML, I include all attributes in the element(s) I’m passing in. So essentially I would have:

$('#header').append("<p class="orange" id="headerText"/>");

So even though this may be just a coding style, I was curious to see what the difference would be in performance based on passing a block of HTML first, adding attributes to it via the attr() method and then appending (or prepending) to an element, or the way I do it, which is a bit of the reverse.

I created a very simple test with the following markup:

			<div id="main">
				<form action="">
					<input type="button" value="No Attribute Method Call" id="noAttr" />
					<input type="button" value="With Attribute Method Call" id="withAttr" />
					<input type="button" value="Clear Response Div" id="clear" />
				</form>
				<div id="response">

				</div>
			</div>

And the subsequent JavaScript:

$(function(){
    var $response = $('#response');

    $('#noAttr').click(function(){
        $response.append('<p id="myParagraph"/>');
        $('#myParagraph').text('Some Text');
        return false;
    });

    $('#withAttr').click(function(){
        $('<p/>').attr('id', 'myParagraph').appendTo($response);
        $('#myParagraph').text('Some Text');
        return false;
    });

    $('#clear').click(function(){
        var children = $response.children();
        $.each(children, function(i){
            delete children[i].parentNode.removeChild(children[i]);
        });
        return false;
    });

});

The results are interesting…

Test With Attribute Method

The above screenshot shows the results in Firebug’s profiler of the technique used that is similar to Rebecca’s example. Note, the total number of calls and the total amount of time it takes to execute the function on the click event.

Test Without Attribute Method

And these are the results using the technique of which I am most accustomed.

The obvious numbers that stand out to me are the total number of calls and the total amount of execution time. 90 total function calls in the first example versus only 62 in the second and a difference of 0.811 milliseconds in total execution time. Now, many may argue that .811 milliseconds is not that significant of a difference on the surface, but the percentage difference is…a whopping 37.5%!

Try it out for yourself on the demo page (requires a standards-compliant browser and a JavaScript profiler).

James Duncan (@jamesduncan) from Joyent gave an excellent talk on “JavaScript Platform as a Service” and the economics associated with it.  Duncan made an excellent correlation to using web technology related services very much like one would pay for electricity:  you should only pay for what you use, a solid argument against adding additional data centers, servers, and the like. The concept behind his Platform as a Service (PaaS) is not necessarily new, but it’s association with JavaScript is.  Duncan claims there are “tons of money being spent to make JavaScript super fast,” and “the world is really changing” in regards to JavaScript.  Looking forward to what comes of this.

Easily the most entertaining presentation was by Brian Leroux (@brianleroux) from Nitobi on Phonegap.  Just check the second slide and you’ll see why his presentation woke the crowd up.

If you are not familiar with Phonegap, you should be.  With all the fragmentation between mobile operating systems and how we developers loathe said fragmentation, Phonegap comes to the rescue by allowing you to develop in your native environment (e.g. HTML,CSS,Javascript) and allows your app will work on multiple mobile platforms.  Pretty ingenious and not very well known, which is baffling to me.  Most iPhone developers, I believe, would prefer their app to work on the Android phones and Blackberries as well, yet there doesn’t seem to be a large adoption to Phonegap…yet.  I believe JSConf, with the incredibly bright and influential minds that were there, will help push this abstraction SDK further in the mobile dev community.

Some highlights that stood out to me from the other talks included the concept of hyperlinking/JSON referencing in a REST Architecture and Persevere by Kris Zyp, some remedial website performance related topics by Stoyan Stefanov (author of Object Oriented JavaScript), an excellent introduction by Richard Worth on the jQuery UI framework, a high-energy presentaiton of the Sproutcore framework by Mike Subelsky, and finally a truly thorough and comprehensive presentation of the true depth of the Dojo framework by Peter Higgins (@phiggins).

I could go on and on about the presentations and the mental stimulation gained from this conference, but I would never get to work on time.  If you are a serious JavaScript engineer, you would be remiss to not attend next year’s JSConf.  The content and quality of the conference overall was by far the best I’ve ever experienced.