Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best practices javascript/jquery [closed]

Tags:

jquery

On my work we discussed what is best practice. 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 master page. Is there any overhead to have jQuery selectors fire on every page?

like image 792
Sune Avatar asked Jan 23 '26 03:01

Sune


2 Answers

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.

like image 169
Sarfraz Avatar answered Jan 25 '26 19:01

Sarfraz


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)

like image 32
David Hedlund Avatar answered Jan 25 '26 20:01

David Hedlund