tags:

views:

53

answers:

5

On my work we discussed what is best practise. Consider we have one or more a tags. We want the a tag to fire an javascript function, when It gets clicked. To have this functionality we could bind an event to the a tags, through jQuery, or we could call a function inline on the a tag. What are the pros and cons for each of these solutions, and what is the best way to do.

Question 2: Usually we have and javascript file with our javascript/jquery located on our masterpage. Is there any overhead to have jquery selectors fire on every page?

A: 

You're talking about unobstrusive javascript, which is the hype thing right now.

"Unobtrusive JavaScript" is an emerging technique in the JavaScript programming language, as used on the World Wide Web. Though the term is not formally defined, its basic principles are generally understood to include:

Separation of functionality (the "behavior layer") from a Web page's structure/content and presentation

Best practices to avoid the problems of traditional JavaScript programming (such as browser inconsistencies and lack of scalability)

Progressive enhancement to support user agents that may not support advanced JavaScript functionality

To me this is the best solution for these reasons.

About question #2, there are overhead to use selectors, but with proper optimisations you should be ok. If you notice some speed issue, you can call the selectors only when needed and not all the time.

marcgg
A: 

Different times call for different measures.

The <a /> tag's event handlers are intended to decide whether to follow the link or not. For example, you might say <a href="http://google.com" onclick="…" >…</a> If that function returns false, then the page shouldn't switch if clicked. (This is a much nicer alternative to saying things like <a href="#" /> because if done right, it works for browsers with javascript turned off.)

On the other hand, binding event handlers with jquery all at once is crazy useful if you have many links that do close to the same thing and don't want to hardcode them all.

One can read about the elements of Javascript style here, though that doesn't touch on jquery very much.

Michael
you can still have a link with a proper `href` and bind a jquery click event handler that instructs the browser on whether or not to follow the link to that url.
David Hedlund
A: 

Definitely Unobtrusive JS is better than Inline JS, so you should put your binds in a separate jQuery file.

In the other hand, remember that being specific in your jQuery selectors is a great way to improve performance. i. e. $('div.content a.link_btn') is a lot faster then $('.link_btn')

Erik Escobedo
+1  A: 

Question 1: Some people would argue that keeping the javascript away from the HTML will give you better readability and maintainability of your code. I would include myself in that group. I certainly think the code is easier to read if the HTML is HTML-only and all javascript is found in JS files.

If you assign the same event handler to several elements, then you'll definitely have to change less things if your requirements change.

There are some functionality considerations, with regards to when the event handler is assigned. With jQuery, there's not a lot you can do before DOMReady. In pages that load a lot of elements, or where the DOM loads slowly for some reason, it's certainly possible for a user to click a link before its event handler has been assigned. If you write the assignments inline, and make sure that the function called from the click has been loaded in HEAD, then you know that your event will fire.

I still think it's reasonable to assign event listeners in DOMReady (and make sure that the pages load fast), but do consider what will happen if the user clicks a link before the event listener has been assigned. I usually advocate javascript:void(0); over # as values for href, since that won't do anything. if your href points to # and you rely on return false to prevent the browser from following the link, you're not covered for the cases where the user clicks before DOMReady or where there's a javascript error in your click handler that prevents continued execution. Following a link to # may in some browser cause a refresh, but in the very best case scenario, it will still cause an item in the browser history, so that clicking the back button will only take you to where you are already.

Question 2: There is some overhead, certainly. Each time the page load, the script will search for elements that match the different selectors. If you know that certain elements will never be found on a given page, you could reduce the execution time by some amount by simply not looking for those elements. If you want to keep it all in one big script file, you could perhaps figure out from the URL whether or not to run a specific set of selectors. Checking location.href a few times is certainly negligible. How much execution time you'll save depends on how many selectors they are, and how complex they are. Simple ID selectors have almost no impact on execution time.

If you use live queries, there will be a greater overhead, because in those occasions, active work is going on each time the DOM is modified. (Nick's comment)

David Hedlund
The last bit is incorrect: "If you use live queries, there will be a greater overhead, because in those occasions, active work is going on each time the DOM is modified."....**no** work happens when the DOM is modified. `.live()` and `.delegate()` work off event bubbling, they just wait for events to bubble, in fact if you have hundreds of elements, it's cheaper to listen for the event to bubble to `document` (this is *exactly* what `.live()` does) and handle it there...as opposed to attaching `n` event handlers to `n` elements, slowing the page load.
Nick Craver
@Nick Craver: that's awesome, i had no idea. thanks for filling in =)
David Hedlund
+2  A: 

Question 1

I would suggest you to have a look at:

Unobtrusive JavaScript Saves You Time & Money, Keeps Your Website Agile
Unobtrusive Javascript Presentation

So:

  • Separation of functionality (the "behavior layer") from a Web page's structure/content and presentation

  • Best practices to avoid the problems of traditional JavaScript programming (such as browser inconsistencies and lack of scalability)

  • Progressive enhancement to support user agents that may not support advanced JavaScript functionality

Question 2

Include the javascript file(s) only on those pages where it is required eg for pages that need it.

Sarfraz