tags:

views:

462

answers:

8

Self-explanatory, I hope.

A: 

It will be unpredictable when the script will run from browser-to-browser, page-to-page.

mgroves
So if I don't care when it runs, it's perfectly legitimate? My hope is that it will run sooner than it would if wrapped in the $(document).ready();
Larsenal
If it doesn't involve DOM, then I'm sure it's OK to run before ready().
Adrian Godong
+7  A: 

Your jQuery selectors will randomly miss any elements because it is not loaded yet (by the browser).

Adrian Godong
+3  A: 

$(document).ready() is jQuery's way of making sure that the code you want to run on page load runs at the same time across browsers.

It also provides a mechanism to stack different functions to run on page load. If you don't use it and you have multiple onLoad assignments, only the last one added will actually run.

Justin Niessner
$(document).ready() actually runs BEFORE the onLoad event fires, usually - it runs as soon as the DOM has loaded, while onLoad also waits for all images and such to download before it fires.
Joel Mueller
A: 

When you are selecting elements in the DOM they will sometimes work, and they will sometimes not work.

It just depends on whether they have loaded or not.

However, if you throw in the script at the very end of the document, it will generally be okay. (Since by that point in time it should have loaded everything).

Thomas
+2  A: 

This is the first thing to learn about jQuery: If you want an event to work on your page, you should call it inside the $(document).ready() function. Everything inside it will load as soon as the DOM is loaded and before the page contents are loaded.

 $(document).ready(function() {
   // put all your jQuery goodness in here.
 });

The $(document).ready() function has a ton of advantages over other ways of getting events to work. First of all, you don't have to put any "behavioral" markup in the HTML. You can separate all of your JavaScript/jQuery into a separate file where it's easier to maintain and where it can stay out of the way of the content. I never did like seeing all those "javascript:void()" messages in the status bar when I would hover over a link. That's what happens when you attach the event directly inside an tag.

On some pages that use traditional JavaScript, you'll see an "onload" attribute in the tag. The problem with this is that it's limited to only one function. Oh yeah, and it adds "behavioral" markup to the content again. Jeremy Keith's excellent book, DOM Scripting, showed me how to create an addLoadEvent function to a separate JavaScript file that allows for multiple functions to be loaded inside it. But it requires a fair amount of code for something that should be rather straightforward. Also, it triggers those events when the window loads, which leads me to another advantage of $(document).ready().

With $(document).ready(), you can get your events to load or fire or whatever you want them to do before the window loads. Everything that you stick inside its brackets is ready to go at the earliest possible moment — as soon as the DOM is registered by the browser, which allows for some nice hiding and showing effects and other stuff immediately when the user first sees the page elements.

Referenced from http://docs.jquery.com/Tutorials:Introducing_$(document).ready()

Shadi Almosri
A: 

Bassicly use this basic rule:

if your code involves the DOM wrap your code in $(document).ready(). If it doesn't involve the DOM, then don't wrap it in $(document).ready()

Pim Jager
A: 

hmm if its not wrapped, its just plain old JavaScript, do what you want with that, but will the jQuery library be loaded, hard to tell.

Mark Schultheiss
A: 

There are two main reasons for using

$(document).ready (function ()) // or $(function ())

1) It ensures that the code within is only run once the DOM is fully loaded (this doesn't include loading images, flash or other resources, just the DOM built from the HTML). This means that you can put the javascript anywhere in the HTML instead of at the bottom (which with vanilla javascript is the only place you can put it to guarantee that it'll work on the whole DOM instead of what's currently loaded). Unless you use the window.onload event which also guarantees this, but can only be used once. Which brings me onto my second point;

2) It allows you to fire off multiple functions when the page has loaded, rather than the single use of window.onload which you have when using vanilla javascript. This is great because it means that you don't have to a) write your own function to take care of it, b) worry about checking to see if there's already an onload function from another library, c) spend what feels like years debugging only to find out that your window.onload has been overwritten by someone else's code.

Bonus point: 3) It looks cool, no? :P

Other notes: If you're not using or manipulating the DOM then your code doesn't need to go inside the $(document).ready() function.

Putting your javascript files at the bottom of the html, just before the </body> will give a perceived increase in loading spead - it's not actually faster, but the browser will load the JS after the HTML, so can start rendering the HTML while the JS is loading. This in turn means that something will appear on the user's screen a split second earlier than a script in the <head> - and in the web, split seconds count :)

slightlymore