Getting Over Your jQuery DOM Ready Addiction

You're not bound to it, you know...

If you’re getting started with jQuery or have been using casually for some time, you’ll have read your share of blogs, documentation and assorted other sources decreeing that any and all jQuery code must be declared within the following code:

<script type=”text/javascript”>
    jquery(document).ready(function(){
        // your code goes here…
    });
</script>

This isn’t strictly bad practice per se.  If you want your events bound to your DOM elements correctly, you’re generally best to ensure that the DOM is fully loaded first.  However this blanket, unquestioning approach doesn’t mean you’re adopting good practice all the time either.  Here’s why.

DOM versus Content

The DOM ready event provides a very important hook into the earliest-possible moment at which you can confidently start working with your page’s elements.  Commonly, this is the point at which people wire up their event listeners and DOM manipulations.  What is actually happening here is the browser has mapped out the page’s structure before presenting it visually to the user.  It knows where everything’s supposed to go and all it needs to do now is go get the images and other media and colour everything in.

From here, the images, media files (flash, video, audio, etc) and CSS files are downloaded and rendered on the page.  Once that part is complete, we will see the once-popular window.onload() event fire.  Conversely to the DOM ready event, this is practically the last point at which you can signal page events to fire.

In most cases, we aren’t prepared to sit and twiddle our thumbs while we wait for all our imagery to download and render on the page and so leap at our saviour the DOM ready event.  But does this event deserve its lofty reputation?

Don’t Forget Best Practice

In the Web Wild West of old (what did you think that www stood for?), before jQuery and its ilk were a gleam in their creators’ eyes, the accepted practice was to make sure that you included all your scripts at the bottom of the page, immediately before the closing </body> tag.  This was to ensure scripts being downloaded did not block style sheets, page content and the like (while a script is downloading, the browser won’t start any other downloads).

Ask yourself if you actually need that DOM ready event.  What is it you’re actually doing?  If you’re animating an image, you’ll want that image to actually be on the page first.  What about Ajax calls that retrieve some content or data to be inserted on the page later?  Why not just go ahead and grab that content and then check if your DOM is ready for adding to.  The jQuery delegate() function listens for any changes to a set of DOM elements and binds other events to elements that are affected.  The DOM doesn’t actually have to be fully-loaded for this since jQuery will pick up on any changes that are still in progress.  Suddenly we’re discovering a whole slew of cases where you can look to potentially improve a significant chunk of your site’s performance.

I’ll point to an excellent example from Alex Sexton:

<script type="text/javascript">
      // make an ajax request right away
      $.ajax({
        url: 'ajax.php',
          success: function(data) {
            $(document).ready(function(){  //<-- Hey Guys check this out!
              for(var i in data) {
                $('.app-container').append('
'+data[i]+'

');
              };
            });
          }
        });
</script>

Horses for Courses

Having established that not every jQuery component on a page requires being placed within the jquery(document).ready() function, let me be clear and say that for most people, in most cases, the DOM ready event is just fine.  There’s nothing inherently wrong with placing all your scripts there unless you’re running a particularly JavaScript-heavy page or other constraints require you to place particular importance on absolute JavaScript optimisation.

For basic sites or those who employ very little script content, performance – and therefore page structure – is not likely to be significantly impacted by the placement of your scripts.  But it still pays to be at least cognisant of the different ways in which your design decisions can impact your end users’ browsing experience.

Hope this helps.