High-Performance JavaScript: Everything you've been taught is wrong
slideshare.net
slideshare.net
There's quite a bit of good advice in the presentation.
One thing that I didn't see mentioned though is the difference between load-once and reload-on-every-page. Many of the worst JS abuses are from people loading 500k of JS every time the user clicks on anything. Apps such as Gmail or Google Reader only load the JS once then update bits of the page or an iframe as the user clicks around. That has some downsides of course, but it's the only good way to do something that's really JS-heavy.
Use the app all the time, if it's slow or buggy you'll soon get irritated by it enough to fix it :)
As a developer you should be one of the biggest users IMHO
"The best X you've ever seen"
"Everything you've been taught is wrong"
"Why you're wrong about everything"
"10 things you don't know about X"
"Why you'll never amount to anything"
"All the code you write is rubbish. Here's how to do it."Most of the time the article doesn't live up to the claim in the title.
- setting innerHTML is faster than dom manipulation
- doing dom node manipulation is faster off dom (reinsert when manip is done)
- is attaching a 'click' event listener really that much slower than setting node.onclick?
disagree:
- onmousedown and onclick are different actions. onclick is inherently slower because it doesn't fire until after onmouseup. the difference is not 100ms, it's however long the user holds the mouse button. onmousedown should not commit the user to the action, since the user may decide not to do the action and needs a way to cancel it and void the action (ie: move the mouse off the target area before clicking). onmousedown, on the other hand, is an immediate commitment, so it can't be used for dangerous actions that the user may regret a split second later.
I'd take many of the points with a pinch of salt. Use profilers, and other debug methods to find out what works/doesn't work in your code.
For example the point about event listeners vs setting node.onclick. Perhaps it is marginally quicker. But will the user notice unless you add 1,000 event listeners? Unlikely. Might not even notice then. It all depends on where and how it's used. Also obviously you can't use .onclick if you want several event handlers attached to the same event unless you do that functionality yourself.
It's not totally wrong. But it's often wrong. The world isn't writing it's first program. Code that's too slow has a performance bug. And like any bug, it's better and cheaper to catch it early than late.
And you can't always use your own code. Eating your own dogfood is a reasonable idea but it can break the organization that is trying to fix and build the software. For example, if there's a bug in your new bug reporting system you'll lose the information that there's a bug and never fix it. And so on.
The performance gains that chip makers have given us have been stolen by the software makers to make generating software cheaper and faster, rather than being passed on to the users to make systems more responsive. Yes, there's a user benefit to having more software quicker, but that isn't enough.
I've been looking for a web-based contact manager/address book. Plaxo is probably the best I've seen, but it still has major usability problems - trying to prune/combine contacts after importing was a nightmare. Is there anything better?
Thanks, but I think I'll stick with everything I've been taught.
I'm no more patient that I would expect any of my clients to be. Funny, they never care WHY something isn't working right.