Friday, January 11th, 2008
Making Ajax Applications Scream on the Client
Cyra Richardson, Senior Program Manager Lead on the IE team, gave a presentation at MIX 2007 on Making Ajax Applications Scream on the Client.
The scope of the presentation is to show how to speed things up right now, not in the future.
Optimizing Symbol Resolution
How to speed up in a late binding world. Discusses the scope chain from vars to the DOM itself, and how to make sure that you don’t keep running around the chain.
JavaScript Code Inefficiencies
To make string manipulation more effience in IE:
- Use local vars
- Cache strings from IE objects
- Use Array.join for concatenation
(I prefict that array.join will stick around even when it isn’t faster, just like the equivilent in Java land).
Some other thoughts:
- Don’t use eval unless you really have too. Instead of parameterized code
- SWITCH is costly for large sets, consider a hash table wrapped in a try/catch
- WITH is costly due to symbol lookups everywhere, use manual iterators
- Don’t use your own get/set accessors
IE Performance Considerations
DOM is expensive in IE, especially due to the generic nature of the platform. Also watch out for layout improvements such as hover CSS style.
HTTP Performance
Simplify and reduce:
- Script in on JS file
- Styles in one CSS file
- Fewer, smaller, unscaled images
- Simplify layout
- Use HTTP compression (lots of detail on cache control)
Tools and Techniques
- Developer Toolbar
- Fiddler: HTTP traffic watching
- Ajax View: New from MS Research. On the fly rewrite the JavaScript and add instrumentation code.













In addition the use of XSLT can deliver huge performance boosts to HTML generation and rendering over JavaScript. TIBCO General Interface uses a technique to poke values from JavaScript objects into parameters in XSLT (so developers do not have to get into the yuck of XSLT development), then use XSLT/XML merge to generate and update GUIs faster. Essentially the XML/XSL merge process acts as a sort of compiler for these processes and gets the job done faster. It’s one the the things that makes TIBCO GI (after it loads — which does take a second or two more given all that’s in it to deliver full featured ajax apps — not a component or three in an HTML page) run so fast. Of course this means that your data must be in XML, but GI’s data objects can be accessed as both JSON or XML simultaneously.
This looks very much like last years “recommendations” from the IE team, about not using closures etc. Basically: “gimp your script to accomodate our browser” … after a few years of supporting various generations of IE, you get kind of an ambivalent attitude towards the IE team(s) at MS.
On one hand, they do great work, and I personally can’t wait to play around with an IE version, that can pass the Acid2 test.
On the other hand, the sheer arrogance of some of these guys is just staggering. They keep churning out mediocre code, and expect the rest of the worlds (web)developers to jump through hoops to continue to support the clueless masses that choose IE because someone decides to cash in on their desktop dominance.
That Ajax View thingy crashes IE6… but still pretty neat though…
A few weeks ago, I presented High Performance Ajax Applications at Yahoo! I posted the video on my personal web site.
Cheers!
This is good stuff straight from the team at MS, I think a lot of the practices are relevant to javascript in general and not specifically just IE’s JScript engine. I also recommend Julien’s presentation as well - all good stuff.
At this point, the platform, the web browser, should be responding to the (developer) market, not the other way around. They should be saying/thinking “what do you want?” or “how can we make things easier?” and delivering on that.
@Andy - u r right but in order to know what to expect on IE8 and MS in general its valuable to know their way of thinking… I am past the stage of of hating IE, I just deal with it.
I think that history already showed that MS underestimated the power of the community and their ability to enforce standards over proprietary solutions.
There is several talks about the issue in general on YUI theater, which I would highly recommend also for those interested.
EDIT: I also have to say, if “document.body.all” is shown in an example of caching a collection of DOM elements, the title of the presentation should have been “How to make AJAX applications scream on the IE” or “How to make AJAX applications whine on the client” ;-)
Some great tips there. I especially like the one about making references to function calls to use within for loops.
One thing that I do in my applications is use cookies to transfer data, rather than http requests. I’m surprised that this was not mentioned.
One concern I have about speculative downloads is that it could cause serious bandwidth problems, if what is loaded is not actually used.
When will people please stop spelling it “Ajax” when they mean to spell it “browser scripting”? We are programmers. Spelling counts.
What is it with Microsoft and the licensing for these tools. Again we have an example of a potentially very useful tool for web developers everywhere and then this bit of text in the license ruins it all:
“You may not use or distribute this Software or any derivative works in any form for commercial purposes. Examples of commercial purposes would be running business operations, licensing, leasing, or selling the Software, distributing the Software for use with commercial products, using the Software in the creation or use of commercial products or any other activity which purpose is to procure a commercial gain to you or others.”
WTH Microsoft? Why can’t I use this app where it would be the most useful?
Hi, I don’t understand why the with statement should be so costly. It should just add an object in front of the scope chain.
Is meant that any time an identifier is not present in the object used on the with statement there is one more object to check?
A function is more expensive than a with statement from this point of view.
What is meant with “use manual iterators”?