I guess we should have warned everyone :)<p>There's quite a bit of good advice in the presentation.<p>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.
I find it really surprising some people don't use the apps they are developing. If you're not using it day in day out heavily, how can you know what's likely to irritate users.<p>Use the app all the time, if it's slow or buggy you'll soon get irritated by it enough to fix it :)<p>As a developer you should be one of the biggest users IMHO
I really wish people would stop this fad of rubbishing the reader in titles.<p><pre><code> "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."</code></pre>
etc<p>Most of the time the article doesn't live up to the claim in the title.
didn't know:<p>- setting innerHTML is faster than dom manipulation<p>- doing dom node manipulation is faster off dom (reinsert when manip is done)<p>- is attaching a 'click' event listener really that much slower than setting node.onclick?<p>disagree:<p>- 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.<p>
Lots of schools teach CS and say "Code it first and fix it later". They call this preventing "Premature optimization".<p>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.<p>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.<p>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.
"Minimize dependency on 3rd party library code"
doesn't make sense especially when it's in the "write less code" section P15. Moreover, it's a really easy thing to say when you have seven guys fully dedicated to the view layer as compared to a two man operation doing everything....
Interesting product (Plaxo).<p>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?
Don't miss the video; there's a lot of detail here that's absent in the slides: <a href="http://www.vcasmo.com/video/osnow/391" rel="nofollow">http://www.vcasmo.com/video/osnow/391</a>