Thursday, January 22nd, 2009

Platform Optimization Strategies for Ajax Toolkits

Category: Ajax, Editorial, Examples, Library

<>p>Dylan Schiemann has posted on Platform Optimization Strategies for Ajax Toolkits which covers techniques for having code run on multiple platforms effectively.

He talks about how some frameworks have code paths for specific browsers to shorten the if (foo) type overhead. Having a compile step like GWT does makes this easy. TIBCO GI “builds an optimized code tree for each major browser release (the opposite of the approach jQuery 1.3 and others have taken, as code only makes it into a build for that browser if that browser is known to support that functionality).”

excludeStart(”webkitMobile”)

Dylan then discusses what is happening in the Dojo community:

In recent discussions on the Dojo mailing list, discussions turned to how to make Dojo faster for mobile users. In most cases, this involves removing code and features that are not needed on that platform given the precious resources available on mobile devices and over mobile networks.

Alex Russell checked in some work he started last year that looks like this:

//>>excludeStart(“webkitMobile”, kwArgs.webkitMobile);
!dojo.isIE &&
//>>excludeEnd(“webkitMobile”);
[./javascript]

The syntax is a bit verbose, but it excludes the code between the start and end in a Dojo build created for webkitMobile:

./build.sh profile=base action=clean,release webkitMobile=true

While we would love to switch to pure feature detection over browser version detection like John has done with jQuery 1.3, version detection is generally more concise and precise, and does not necessarily make Dojo any less forwards compatible.

Version detection also makes it easy to exclude code created solely for browsers that require major workarounds, such as IE 6. To get the most out of this though would require doing something similar for each major browser, which would make Dojo more challenging to understand and maintain, would probably require a build step even during development (not just in production to improve performance).

At this point, there are no clear answers, just a lot of questions on how to create a toolkit that offers edge of the web features for desktop users, and still preserves performance for mobile web users. What approach do you think is best?

Related Content:

Posted by Dion Almaer at 2:14 am
1 Comment

+++--
3.5 rating from 33 votes

1 Comment »

Comments feed TrackBack URI

The Dojo developers are obviously clueless. Browser sniffing is “more precise” than what exactly?

And last I checked, jQuery’s latest attempt at competence fell way short. At least he is trying now though (hasn’t been a year since he scoffed at the idea that his reliance on browser sniffing was a major problem.)

The answer is simple. A single framework for every Web app is a ridiculous idea. That’s it. The last few years of babbling about Framework A vs. Framework B has been a lot of wasted keystrokes. Those who know better are moving right along with mobile devices, set top boxes, etc., without a whisper of trouble. Those who wasted the last few years learning a specific framework would do well to start over.

Comment by DavidMark — January 29, 2009

Leave a comment

You must be logged in to post a comment.