Is there a difference, performance or efficiency wise, between placing javascript calls such as blur, onclick etc. in $(document).ready(function(){ as opposed to placing them in HTML?
Thanks!
Is there a difference, performance or efficiency wise, between placing javascript calls such as blur, onclick etc. in $(document).ready(function(){ as opposed to placing them in HTML?
Thanks!
I dont quite understand the meaning of placing them in DOM. But yes if you mean inside a script tag in your body. The document.ready thing executes before the images are loaded and it save time for javascript actions to take place
I think by "in the DOM" you mean this:
<a href='#' onclick='someCodeHere()'>Click Me</a>
right? If so, then it's not so much about performance as it is about maintainability and power. Using jQuery (since you mentioned the "ready" handler in jQuery terms) to bind your events lets the framework take care of managing multiple handlers, and dealing with browser differences.
In fact sometimes it's even better to not bind directly to elements at all. Instead, you can use the jQuery "live" or "delegate" mechanisms to help cut down on actual handler bindings and provide for a more dynamic DOM.
I agree that it is much more elegant to use jQuery or other and have unobtrusive js. This way it's all clearly visible, and easily extensible.
I just want to mention 1 quick problem that I had with all of this, and it involves generated code (i.e html from frameworks). In my case, Apache Trinidad as part of JSF. When trinidad generates HTML, it included inline javascript calls like onclick='submitForm(..)'
I was modifying the existing custom inline calls to use jQuery, for example:
<tr:commandLink onClick="doStuff()" />
which generates html like:
<a href="#" onclick="doStuff(); submitForm(..)" />
Now in the case that the javascript call is inline, if you return false from the method, the rest of the onClick will not execute. However, when using non-obtrusive jQuery, the inline method will not be stopped (not easily anyway).
I guess what I'm saying is "be weary of frameworks" :-)