

High-Performance JavaScript: Everything you've been taught is wrong - theoneill
http://www.slideshare.net/pureclone/highperformance-javascript

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

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

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

~~~
edw519
Best. Post. Ever.

~~~
tlrobinson
Most. Overused. Rhetorical. Device. Ever.

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

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

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

------
german
I hate the loading time between slides.

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

------
cdr
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?

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

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

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

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

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

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

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

