Global variables eat memory - local variables exist only as long as the function survives, unless they are in some way referenced from somewhere else. (Mostly the objects that has been created using the function, gíven the function is a constructor.)
Every extra action you have to take - including climbing the scope chain and calling a function - consume processing power. You gain load speed and readability from splitting up in smaller functions, especially if they are called from many places.
Do..while is faster than while is faster than for is faster than for..in. Sometimes a function calling itself is faster than an iterator, sometimes not. Seems to depend on function complexity - the more complex the more gain. If you can keep a loop shorter than a function, use that instead.
setInterval is better than setTimeout. Neither is good.
Don't ever use eval, Function constructor or RegExp constructor if you can avoid them. They are big hogs all of them.
Use break and continue in loops if they perform an action you might be interested in. It's often better to loop through everything and jump what you don't want to handle than to set a more complex expression in the condition of the loop.
Use labled blocks and breaks for complex execution handling. It may be spaghetti, but it's fast.
Minimise actions inside loops. For instance, never use collection.length inside the condition if it's static during the loop - store it in a variable instead.
Never use MSDN for information about anything non-MS-proprietary. If you look up a standard property MSDN will tell you how IE implements it, which may or may not be how it's supposed to be implemented, but MSDN never distinguishes. Therefore its information with regard to anything non-MS is unreliable.
<nb>I'm not MS bashing here .. simply passing on advice because I value integrity of information ... and I've been embarrassed too many times </nb>
For MS-proprietary information it's second to none, but it's search facility is not so great; Google Site Search is much more reliable: "site:msdn.microsoft.com your search words"
"Why bother with accessibility? ... Because deep down you know that the web is attractive to people who aren't exactly like you." - Joe Clark
Last edited by brothercake; 07-19-2003 at 05:44 AM..
Just made a cleenup of blind links and made some additions. (Thanks, everyone reporting those blind links and suggesting additions.)
I'm also looking for some way to bring the structure of this list to a level that makes it easier for newbies to find what they are searching for in it (Currently it's more targetted at people already familiar with the languages and it's construction and abilities). If you have any suggestions, PM me.
(I like to keep this thread absolutely on-topic and relevant)
Yet another bug in the oldest, poorest, most unmaintained and most buggy browser in the last 5 years, Internet Explorer. Some time ago I was doing some tests with one of my products. Worked really fine, in all browsers, including IE. The problem I'm talking about here is a little harder to detect.
Imagine a bug that doesn't manifest until you made several dozens requests in your page. This is the most dangerous type of bug. At first you believe everything to be excellent, you start to push harder on your software, adding more features, take it to the limit. And when you notice that behavior, it's like the sky falls on your head.
The problem I'm discussing here is that IE leaks memory on certain occasions. If your script complies to this behavior, you will usually notice an abnormal slowness when IE executes it, usually after 40-50 requests made within the same browsing session (I mean, without restarting the browser). This happened to me and: (1) I'm glad I noticed it, (2) I hate IE even more than I did so far and (3) I managed to fix it--in 3 freaking days!! ;-(