<i>Always fall back to core JavaScript whenever possible. Limit framework usage.</i><p>Why, frameworks exist for a reason and keeps us from reinventing the wheel. Many times a contributor to a framework has labored to make his routine as efficient as possible on the broadest array of platforms. Many times we can forgo a lot of optimization work by using the framework rather than rolling our own.
I hate articles that just make a bunch of assertions without any explanation as to _why_ or performance tests.<p>If I'm earning a savings of < 1ms by making one choice over the other, it is probably more time efficient for me to simply not worry about it.<p>> 8 But if you have multiple string concatenation, prefer pushing to an Array and then calling the join() method on it. This is particularly helpful while building HTML snippets.<p>Depends on too many factors (browser, number of segments, segment length etc) to a be rule. Most of the time, the performance between this and += is going to be more or less the same.<p>> 26 With AJAX, GET works faster than POST. So prefer GET unless request length is more than 2K; yes, you guessed it right - IE.<p>Use GET or POST when you're supposed to not based on how much information you think you'll be sending.<p>> 27. Go easy on scripted animations.<p>What's easy? What's hard?<p>> 30. Always fall back to core JavaScript whenever possible. Limit framework usage.<p>It would be more prudent to _know_ your framework, and know when to not use it. IE (even in 9!) still doesn't implement indexOf - I can roll my own solution or use jQuery's inArray.<p>Here's a better article <a href="http://www.slideshare.net/nzakas/speed-up-your-javascript" rel="nofollow">http://www.slideshare.net/nzakas/speed-up-your-javascript</a>
#29 No Tables. How does that help performance? Sure on very large pages that might help, since the table usually won't render until the </table> has been sent, but maybe the better tip would be "avoid very large pages" (i.e. 100KB or more of HTML). DIV based layout also degrade if text in a single cell is very large, whereas Table based layout is robust against that. Also, I don't understand why <TABLE> is bad, but this is okay!?!?!<p><pre><code> <div class='table'>
<div class='tr'>
<div class='td'>1</div><div class='td'>2</div><div class='td'>3</div>
</div>
<div class='tr'>
<div class='td'>a</div><div class='td'>b</div><div class='td'>c</div>
</div>
</div>
</code></pre>
Which is what DIV/FLOAT layout usually ends up becoming. If your DIV/FLOAT layout doesn't map to a structure like that, you're probably doing something wrong!<p>Finally, has IE fixed the "we double the padding on floats" issue? Because float-driven layout with that bug is pretty hard, since IE will double your paddings while the other browsers don't.<p>I do know that proudly espousing TABLE in a job interview can cost you the job. But aside from that TABLE is very effective for most layouts. I do avoid TABLE inside TABLE of course, that's a code smell, but top level TABLE is the right tool most of the time. Do anti-TABLE people also avoid Excel?
The problem with this list is some are micro-optimizations while others are rather important and dramatic, but they are all listed together in no particular order or weight.
This author doesn't inspire much confidence when he says "A fellow reader just forwarded this link to me" when referring to Google Closure. Did he even try it out?<p>Also, some things are pretty pointless (e.g. "#6 - no globals" doesn't do anything to improve performance), and other are poorly explained (e.g. "#13 - store local refs to out-of-scope vars" - what does that even mean?)<p>He even has syntax errors (e.g. "#7 - var fullName +=", really?) and other oddities ("#28 - element.bind" What in the world is that?)<p>The good points are largely regurgitation of stuff that is much better covered by Steve Souders, the Opera blog and other resources.
Some of the advice is just plain wrong depending on your target platform. For example, on my iPad, iPhone 3G (not 3GS), and Safari 5.0 (6533.16)/Mac, using createElement/appendChild is consistently faster than using innerHTML. In Chrome 5.0.375.70/Mac, they are the same speed. In Firefox 3.6.3/Mac, naive createElement is slower, but using a DocumentFragment makes it as fast as innerHTML.<p>My test case: <a href="http://dqd.com/~mayoff/timeDom.html" rel="nofollow">http://dqd.com/~mayoff/timeDom.html</a>
Thanks for all the valuable feedback. I have updated the post by adding little explanation to most of the points there to justify each concern. And have revised a couple of points. Please feel free to comment further. Please revisit <a href="http://www.webuiarchitect.com/30-best-practices-to-boost-your-web-applicati" rel="nofollow">http://www.webuiarchitect.com/30-best-practices-to-boost-you...</a> to see the changes.
> #13 In any code block, store local references to out-of-scope variables.<p>That doesn't even make sense. The for-loop block doesn't create a new scope, so it's perfectly valid to refer to the variable `a`. Plus, even if you create a new scope, you can still refer to `a` due to closure.
#1 is completely wrong. Use of document fragments is much faster than innerHTML. This way your dom operations occur in memory and the results are pushed to the dom in one operation. Most of the rest of the tips are valid.
To state the obvious: the JS performance advices this person gives won't necessarily apply the same to ALL JS engines. I wonder which specific browser and version he/she bases the advice on.<p>(Why the heck do the kindergarten people of HN downvote this? It's a perfectly sensible question.)