Hacker News new | past | comments | ask | show | jobs | submit login
High-Performance JavaScript: Everything you've been taught is wrong (slideshare.net)
39 points by theoneill on Nov 27, 2007 | hide | past | favorite | 20 comments



I guess we should have warned everyone :)

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.


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.

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


I really wish people would stop this fad of rubbishing the reader in titles.

 "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."
etc

Most of the time the article doesn't live up to the claim in the title.


every "Why you'll never amount to anything" article i've read has lived up to its title :(


Best. Post. Ever.


Most. Overused. Rhetorical. Device. Ever.


didn't know:

- 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.


innerHTML is also really really evil. Apart from making for horrible ugly code, it plain doesn't work for many things (tables/forms have issues).

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.


i recall reading elsewhere (and verifying) that the dom node manipulation thing isn't actually faster, but i can not find it at the moment.


Lots of schools teach CS and say "Code it first and fix it later". They call this preventing "Premature optimization".

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 hate the loading time between slides.


"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).

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: http://www.vcasmo.com/video/osnow/391


Interesting he never mentions "eval()". Anyone notice any performance issues here?


Security issues, and often not the right way to do things, but not sure of massive performance issues with it.


Yes, eval() is much slower than it's call() equivalent.


lol, a site about high performance is down. The irony.

Thanks, but I think I'll stick with everything I've been taught.


The hosting site is just an intermediary. The link is to a presentation by the chief architect of Plaxo (15M users says he probably knows what he's talking about), and it's just hosted on SlideShare.


Could have been 15,000,001.

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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: