views:

110

answers:

4

As comment to one of the questions here a commenter wrote (emphasis mine):

... By using an inline "onclick" you are doing a similar thing, but it is harder to maintain and more prone to issues. The JavaScript community as a whole has been moving away from inline JavaScript for a while now.

This was referring to attaching events to HTML elements using

$("#someID").click(function(){
    do something here...;
});

rather than

<a id="someID" onclick="someFunction();">

Has there really been a shift away from the old school way of declaring events inline, and if so, what are the benefits of one of the other?

EDIT I guess it may be helpful to include a reference to the original question. It asked about attaching a different click event to each tab. Is my answer crap and do I owe FallenRayne an apology =).

+4  A: 

Yes, there has, at least in some portion of the community, not sure how you'd measure it overall.

There are definitely advantages, off the top of my head:

  • Cleaner / Less code
  • Easier to debug
  • Easier to change
  • Easier to package
  • Performance

From sheer volume, think of this:

<a onclick="someFunction();">
<a onclick="someFunction();">
<a onclick="someFunction();">
<a onclick="someFunction();">
<a onclick="someFunction();">

Or this once:

$("a").click(someFunction);

You can do this with most frameworks via a css selector, etc, handles many elements at once. This means in server code you're just assigning IDs and classes, the client side is easier to handle separately. It's easier to debug as well, for example: in the console I can do $('a').unbind('click').click(...something new...);

Another benefit is performance. If I can split this into a separate .js file, cached by the client, that's thinner webpages and extra data I'm not sending every time. Smaller web page = faster load.

Here's one more example, thinks about how simple it is, granted some framework action via jQuery going on, but how would this look with inline events?

$("li").hover(function() {
  $(this).children().slideToggle();
});

Comparatively, that's a tremendous amount of inline code, even if you leave out the animation portion it's messy (think mouseenter/mouseleave, not mouseover/mouseout...the former, which .hover() uses, is more complicated)

Nick Craver
I always try to avoid putting code to document.ready(), shouldn't I have to put this $("a").click(function() {..}) in document.ready() ? just that I am little aversive to it. Is it bad ?
Mahesh Velaga
@Mahesh - Yes, you should wrap any binding events in `$(document).ready(function() { })`, or the shorter: `$(function() { })`
Nick Craver
@Nick Craver: Yeah, I understand the benefit of doing a selector on a class or an element type is a lot cleaner then putting all the declarations inline. When it comes to hooking up to IDs, it seems like it'd be six of one, half a dozen of the other. Your profile mentions you do a bunch of work with WebForms. When you move JS into separate files, you sort of lose the ability to do `$(#"<%= Control.ClientID %>")` style selectors, how do you get around that?
R0MANARMY
@R0MANARMY - You use a class :) alternatively, if you *need* to match an ID and you know what it is, you can use the ends-with selector, like this: `$("[id$=myElementID]")` Many times, you find you don't actually need a `runat="server"` and the normal `#id` selector works fine...just depends what needs to be an actual server control. The class approach always works though.
Nick Craver
@Mahesh: jQuery offers the `live` method (http://api.jquery.com/live/) to subscribe an event handler on elements not yet defined.
outis
@outis: Awesome, thanks!
Mahesh Velaga
+3  A: 

Has there really been a shift away from the old school way of declaring events inline

Yes, definitely, especially with the rise of the JS Frameworks like jQuery, Prototype and so on, all of which encourage declaring events the "new school" way.

and if so, what are the benefits of one of the other?

One of the main reasons is the separation between the HTML structure and the JavaScript programming intelligence (which arguably do belong separated). It makes the markup much, much cleaner and easier to maintain, while all the programming logic is kept in separate files, which has loading performance advantages as well as better maintanability - you have proper libraries that contain the code, instead of fragments of JS code all over the place.

Pekka
@Pekka: Yeah, I'm running into the "fragments of code all over the place" in my current project. If you can recommend some readings on how to structure rich JS interface, that'd be awesome.
R0MANARMY
@R0MAN Check out the references section in the Wikipedia link posted by rosscj, some good stuff to get started there.
Pekka
+4  A: 

The big benefit is the separation of content (html) and action/behavior (javascript). This is known as Unobtrusive javascript. Keeping these separated makes it easier to change either without affecting the other.

rosscj2533
A: 

With inline declaration you can assign only one event handler while from code you can assign as many as you wish. Also if you need to assign same event handler to multiple elements doing it with javascript is easier and shorter and you comply to DRY principle.

Giorgi
Under the hood there is still only one event handler for DOM1 events; that handler can be used, however, to call several other functions.
LeguRi