views:

102

answers:

7

I recently read a blog post. In it, the author told readers to wire up all their "onclick" events not inline, but when the DOM's ready, like this (jQuery example):

<script type="text/javascript">
$(document).ready(function() {
    $("myElement").click(...
});
</script>

This, for all the elements on the page with events attached to them. And that script block, with all its wirings, should go at the end of the page.

He said that setting it in-line was more difficult to maintain:

<span id="myElement" onclick="...">moo</span>

But he didn't say why.

Is this true in others' experiences? Is it a better practice to do this? What are its advantages?

Thanks.

+1  A: 

It's just messy. It's best to keep your logic separate from your markup, just as you ought to keep your markup separate from your styling. If you keep clean separation, managing code is easier since you don't need to hunt through your markup to modify what happens when you hover over images, for instance.

# index.html
<img class="thumbnail" src="puppies.jpg" />

# index.js
$("img.thumbnail").fadeTo(0, 0.5).hover(
  function () { $(this).fadeTo("fast", 1.0); },
  function () { $(this).fadeTo("slow", 0.5); }
);

# index.css
img.thumbnail { border:1px dotted red; }
Jonathan Sampson
A: 

Having all of your event handlers in one place makes the code much easier to maintain, because you don't need to hunt through the HTML looking for event handlers. It also allows you to have both single and double quotes in the handlers, and will fail on syntax errors when the script block is parsed instead of when the event is first fired.

Also, every inline event handler requires the browser to parse a separate expression (equivalent to an eval call), hurting performance.

SLaks
Don't you think that this eval action is performed anyway when the JS file containing the handlers is parsed? And giving the same performance cost.
Mic
Yes, but this way, you only get one `eval`, as opposed to a separate `eval` for every handler.
SLaks
Each `eval` will incur a large setup cost.
SLaks
My guess is that these multiple inline eval are faster than traversing the DOM and attach the events later on. Did you make some tests?
Mic
No, I didn't, but setting up a Javascript interpreter is expensive; traversing the DOM is not so expensive. If you can prove me wrong, please do.
SLaks
+2  A: 

Well, it's generally regarded as good style to separate code and content from each other as much as possible. If you use that method, you have wonderfully clean HTML:

<span id="myElement">moo</span>

and a separate, central code repository that you can keep in one place, and could even put into an external Javascript file.

Editing your HTML layout becomes really fun then, and it looks great as well.

I don't always follow this rule myself to the letter, and I'm not as zealous about it as others. But I allow myself a maximum of a function call onclick='do_stuff()' when doing stuff inline. Anything more complex turns to code soup really fast.

Pekka
A: 

Read this article on behavioral separation which explains the graceful degradation when JavaScript is disabled. You can also find articles on unobtrusive JavaScript to understand the spirit of jQuery.

Chandra Patni
+1  A: 

Advantages are you won't have to search for events generated by html controls in different controls(ASCX) or Page in case your page has many controls(ASCX) embeded.

You can even debug if the event is registered using Firebug or some other debugger.

Ravia
A: 

Also, if you use event bubbling you can avoid having multitudes of event handlers.

unomi
A: 

An advantage for me of an inline event is you can see directly what will happen when you perform the action, just by inspecting the element.

This is particularly quick if you maintain an old code or done by someone else.

Another advantage is about speed, attaching events later use the DOM and it is probably not as fast as inline generation.

And by using an unobtrusive templating engine like PURE you can keep you HTML clean of any JS logic

Mic