Basic performance tips

Performance tips

• Native for loops rather than jQuery each:
• Avoid jQuery.each if you can.
• Allways cache array length (don't calculate it each iteration)
  

  var arr = ["1","2","3","4"],
      len = arr.length, // Array length cached
      callback = function(ind,val){};
  
  jQuery.each( arr, callback ); // Slower
  for (;len--;){ callback(); }  // Faster
  while (len--){ callback(); }  // Faster --> while()
  

• Avoid globals: access to globals is slower. Global scope is a polluted. Use of global variables should be minimized.
• Cache globals you need, as local variables:
  

  (function(jq, window){
      // here, access to 'jq' is faster than 'jQuery'
  }(jQuery, window));
  

• Reduce the times you call jQuery:
• Cache the jQuery object if you are going to need it more than once:
  

  var jqDog = jQuery("#dog");
  

• Chainning actions.
  

  jQuery("#dog")
      .fadeIn()
      .css()
      .addClass();
  

• Optimize jQuery selectors:
  
  • Use ID instead of classes:
    

    jQuery(".selector"); // Slow
    jQuery("#dog");      // Faster
    

  • Keep them simple:
    

    jQuery(".selector .selector .selector"); // Slow
    

  • Use find() instead of context:
    

    jQuery(".selector");              // Slower
    jQuery("div.selector");           // Slow
    jQuery("#dog div.selector");      // Slow
    jQuery(".selector", "#dog");      // Fast (context)
    jQuery("#dog").find(".selector"); // Faster --> context.find()
    

• Group queries with same callback:
  

  jQuery('div.close').click( callback );    // Slow
  jQuery('button.close').click( callback ); // Slow
  jQuery('input.close').click( callback );  // Slow
  
  jQuery('div.close, button.close, input.close').click( callback ); // Faster
  

• Check if element exists:
  

  if ( jQuery( "#someElement" ).length > 0 ){}
  

• Reduce reflows. DOM manipulation is costly:
• Use a single append().
• Restyle before appended.

Maintenable and reusable Javascript Tips

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."
By Charles Antony Richard Hoare.

Programs are meant to be read by humans. We have to communicate each other through code.

The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you're saying rather than on how you're saying it. If code you add to a file looks drastically different from the existing code around it, it throws readers out of their rhythm when they go to read it. Avoid this.

• Line length: Avoid lines longer than 80 characters. The less code on one line, the less likely you will find a merge conflict. When a statement will not fit on a single line, it may be necessary to break it. Place the break after an operator, ideally after a comma. A break after an operator decreases the likelihood that a copy-paste error will be masked by semicolon insertion. The next line should be indented 8 spaces.
• Avoid Null Comparisons. Comparing a variable against only null typically doesn’t give you enough information about the value to determine whether it’s safe to proceed:
  

  if( whatever !== null ) {}               // Bad
  if( typeof( whatever ) !== "string" ) {} // Good
  

• Separate configuration data
• Validate your code (JsHint, JsLint)
• Variable declarations: The var statement should be the first statement in the function body (Hoisting). This helps make it clear what variables are included in its scope. It is preferred that each variable be given its own line and comment. They should be listed in alphabetical order if possible:
  

  var currentEntry, // currently selected table entry
      level,        // indentation level
      size;         // size of table

• Names:
  
  • Function names: Do not use _ (underscore) as the first or last character of a name. It is sometimes intended to indicate privacy, but it does not actually provide privacy. If privacy is important, use the forms that provide private members. Avoid conventions that demonstrate a lack of competence.
  • Global variables should be in all caps. (JavaScript does not have macros or constants, so there isn't much point in using all caps to signify features that JavaScript doesn't have.)

• Opperators: Use the === and !== operators. The == and != operators do type coercion and should not be used.

• Follow some programming principles:
  
  • Single responsibility: every function should have responsibility over a single part of the functionality. Loose coupling. Gain reusability. If a function needs more than 30 lines, is a bad sign.
  • Don't repeat yourself.
  • Don't do it, if you aren't going to need it.

Sources:

• Google Javascript Style Guide (https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml)
• jQuery JavaScript Style Guide (https://contribute.jquery.org/style-guide/js/)
• Dojo JavaScript Style Guide (https://dojotoolkit.org/reference-guide/1.9/developer/styleguide.html)
• IdiomaticJS (https://github.com/rwaldron/idiomatic.js)
• "Maintainable JavaScript". Nicholas C. Zakas. (http://shop.oreilly.com/product/0636920025245.do)
• Douglas Crockford (http://javascript.crockford.com/code.html)