Thursday, August 30th, 2007
Joseph Smarr: “High-Performance JavaScript: Why Everything You’ve Been Taught is Wrongâ€
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.
4.4 rating from 28 votes
You are right! That’s why I hate addEventListener.
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.
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..
Excellent talk, thanks Joseph for a good mantra :)
@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”
the “popout” for the video loads a howto for video embedding. how ironic ;-)
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!
Slides available at
http://josephsmarr.com/2007/07/25/high-performance-javascript-oscon-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.
Quoted:
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….
You can see the presentation, video synchronize with slide here:
http://www.vcasmo.com/video/osnow/391
This reflects my findings 100%… after having seen this video I really feel fine :)
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.
@Bingobob:
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?
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.
http://www.sentertainment.net/new3/
Thanks.Good article
Great Yahoo video. Interesting Article, thanks Armenian Genocide , great information and research.