Thursday, August 30th, 2007

Joseph Smarr: “High-Performance JavaScript: Why Everything You’ve Been Taught is Wrong”

Category: Presentation

Joseph Smarr gave a talk at Yahoo! with a pretty provocative title: High-Performance JavaScript: Why Everything You’ve Been Taught is Wrong.

He discusses some of his findings in performance such as, the Plaxo team found that in some cases they could achieve substantial gains by attaching event handlers inline using DOM level 0 syntax (e.g. <div onclick=”someGlobalFunction();”>) rather than attaching them via DOM level 2’s favored addListener.

This is very much a micro-benchmark, and if that is the source of your performance issues, you are a lucky man ;)

In sum, Joseph argues for a four-point approach to achieving maximum performance in your web-app:

  • Be lazy: Don’t load or do things before you need to; maybe you won’t need to load or do them at all.
  • Be responsive: Make things happen quickly. If you can shave 100ms off of an interaction by responding to a mousedown event instead of a click event, do it.
  • Be pragmatic: Frontend engineering is hard enough. Don’t make it harder than it needs to be.
  • Be vigilant: Blank web pages are fast. Web pages become slow because you put stuff in them; slowness is your resonsibility. Vigilance is required to prevent slowness.

Posted by Dion Almaer at 6:48 am

4.3 rating from 29 votes


Comments feed TrackBack URI

You are right! That’s why I hate addEventListener.

Comment by Rizqi Ahmad — August 30, 2007

I can understand that during the development process (generally out of time) elements event handlers may be used. But we defined three layers for an approach, to keep them all separated from each other and that’s not so difficult if you develop right xhtml, define labels which links inputs, id and classes for the form tags.

It’s important too, not to overload the pages with a lot of js cool effects or ajax interactions. Page flow must be consistent, and the server-side model should do the hard work for themselves. Don’t forget the only purpose of client side scripts (js) is to INCREASE the usability, which is optional and totally subjective.

Comment by Luis Merino — August 30, 2007

Hmm, and how are we to cope with graceful degrading and the separation of content and behavior?..

I guess there’s a trade-off we need to make between improving speed and improving coding standards.. Some may argue that it is better to be safe and accessible.. But in the end, it’s the result that really matters..

Comment by MarkeeO — August 30, 2007

Excellent talk, thanks Joseph for a good mantra :)

Comment by Joonas Lehtinen — August 30, 2007

@Luis – that is a very 1998 view of javascript. More and more it is common to see server-side code acting as little more that a traffic cop for DB I/O. The client ‘application’ does most if not all of the heavy lifting; with some sort of data interchange format (JSON, XML) in the middle.

p.s. IE + XHTML = HTML 4.01 transitional, save yourself some cross-browser CSS headaches and always use HTML 4.01 Strict + good syntax. I guess 2001 still lingers with us until all users are finally using XHTML compliant browsers. ref: Ian Hickson’s “Sending XHTML as text/html Considered Harmful”

Comment by Wade Harrell — August 30, 2007

the “popout” for the video loads a howto for video embedding. how ironic ;-)

Comment by Kae Verens — August 30, 2007

This is a great case study on a very functional and heavily used app! It’s *stuff* that most people have heard about ( manipulating DOM elements before adding it to the DOM, render last, etc. ) and what people have observed ( if the amount of JavaScript loaded to the browser is >500k ), then there are performance issues.

The thought that toolkits/libraries should be used as for “scaffolding” is a nice way to think of where these things fit in. Toolkits should slowly progress from where you are, rather than replace all your previous work.

Joseph and the Plaxo Team, thanks for sharing!

Comment by Oliver Tse — August 30, 2007

Slides available at

Comment by Ben — August 30, 2007

I disagree with you Wade, we should be treating Javascript as an enhancement to the site’s functionality, not the functionality itself. It’s so easy to attach behaviours and events to links with an actual HREF or to forms with an actual ACTION, and what you get as an end result is something that is greater than the sum of its parts. On top of that, you gain an understanding of the complete flow and scope of your project as you’re working it out, so it’s win-win.

Comment by Mike Ritchie — August 30, 2007

This is very much a micro-benchmark, and if that is the source of your performance issues, you are a lucky man ;)

I understood from the slide that the big gains are to be had by the use of innerHTML, and then the event attaching via DOM level 0 is necessary to hook the events up because the alternative is some kind of dom traversal to find the node….

Comment by Lindsay — August 30, 2007

You can see the presentation, video synchronize with slide here:

Comment by luar — August 30, 2007

This reflects my findings 100%… after having seen this video I really feel fine :)

Comment by Frank Thuerigen — August 30, 2007

Haha. These guy tried to update all the layers in the background – all the time…surely that does not perform very well…AND…this app is updating the whole info-block instead of the single pieces just because its tooo complicated and the code would slow the browser down…yeah…sure…sure it would if u walk the whole dom to find the right div to replace….

i’d say: doh…go home and really optimize that app. in the meanwhile please shut up about web-development.

Comment by Bingobob — August 30, 2007

I´d like to see a technology that does it better, it sounds like you can name one? Would you please enlighten me – perhaps with a link to it so we can start discussing options?

Comment by Frank Thuerigen — August 30, 2007

The man is generally right, it’s sad enough that some frameworks are as bloated as is.

The key is to keep the page as useable as possible. Loading and response need to be well balanced, for example: implementing a function may increase response by 1ms, but if that saves on memory.

I haven’t gotten any publicity for it, but I’ve been working on a gaming page for some time…It may be worth taking a look at, I’ve made many small sacrifices for overall improvements. Decreased both overhead and response time, I still have much work to do, but the concept is there.

Comment by Shawn K — October 2, 2007

Leave a comment

You must be logged in to post a comment.