Platform Optimization Strategies for Ajax Toolkits

By on January 22, 2009 12:05 am

With the proliferation of real web browsers on mobile devices (iPhone, Android, Palm Pre, Nokia), an increasing number of browsers (Chrome) or browser-like platforms (AIR, Titanium, Jaxer), portal standards for widgets and gadgets (Caja, AdSafe, work by the OpenAjax Alliance, and much more), are the days numbered for a JavaScript toolkit that uses the same code base across all platforms without a compile step numbered?

Consider the following:

PhoneGap XUI

“We hear your words. Why another JavaScript framework?! When development of PhoneGap was under way we noticed slow load times for modern JavaScript frameworks (such as Prototype, MooTools, YUI, Ext and (yes) even jQuery. A big reason why these libraries are so big is because is mostly they contain a great deal of cross browser compatability code. The mobile space has less browser implementations (so far) and different needs. Thus XUI.

XUI strives to be a framework for first class mobile device browsers such as WebKit, Fennec and Opera with future support under consideration for IE Mobile and BlackBerry.”

Joe Hewitt’s iUI

“First and foremost, iUI is not meant as a “JavaScript library”. Its goal is simply to turn ordinary standards-based HTML into a polished, usable interface that meets the high standards set by Apple’s own native iPhone apps.”

John Resig’s war on War on Browser Sniffing

“As of 1.3, jQuery no longer uses any form of browser/userAgent sniffing internally – and is the first major JavaScript library to do so.

Browser sniffing is a technique in which you make assumptions about how a piece of code will work in the future. Generally this means making an assumption that a specific browser bug will always be there – which frequently leads to code breaking when browsers make changes and fix bugs.

Instead we use a technique called feature detection where we simulate a particular browser feature or bug to verify its existence. We’ve encapsulated all the checks that we use in jQuery into a single object: More information about it, feature detection, and what this feature provides can be found in the documentation.”

Sizzle, a micro-toolkit for CSS Selectors that is now part of the Dojo Foundation

“Sizzle is a pure-JavaScript CSS selector engine designed to be easily dropped in to a host library.

A completely standalone selector engine (no library dependencies), Sizzle provides competitive performance for the most frequently used CSS selectors. At only 3KB minified and gzipped, it is highly extensible with an easy-to-use API.

Sizzle is designed for optimal performance with event delegation, provides meaningful error messages for syntax problems, uses a single code path (no XPath), uses no browser-sniffing (feature-detection only), and is Caja-compatible.”

TIBCO General Interface

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


GFX supports SVG, VML, Canvas, Silverlight, and Flash with the same simple procedural drawing API, so you can target native and plugin rendering environments with one simple API. In order to make this possible, dojox.gfx selectively loads only the code it needs based on the target rendering environment. Loading the code for all platforms would be prohibitively expensive from a performance perspective.


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

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

./ 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?


  • Pingback: Ajaxian » Platform Optimization Strategies for Ajax Toolkits()

  • Like Dojo, Cappuccino has a build process for the core frameworks, and uses a similar technique for excluding unnecessary code for specific platforms. It uses the C preprocessor (and #define environment variables). Right now we use it to build a Rhino friendly version of the frameworks that won’t talk to window, document, etc.

  • In the qooxdoo framework there are variants which allows you to build specific sets out of the original code. A set may be a combination of a browser variant with a debug variant e.g. you may have these variant sets:


    The browser variants are already defined all over the source code and may be easily used by an application developer. It is even easily possible to define own variants for e.g. product differences like a pro and a free application.

  • Forgot to mention that variants may also have an influence on the dependency tree. qooxdoo comes with an automatic dependency tracking feature to optimally link an application for distribution. This is a new feature since 0.8 and automatically detects classes not needed by another class when a specific variant is selected. For example a vector graphics layer do not need do not need the VML renderer in Gecko based browsers. The class could easily make use of this VML class in the own code as needed. As long as the statements are positioned inside a variant statement it is automatically detected to omit the whole dependency at application link time.

    It looks like the following:

    drawLine : function(pointA, pointB)
    if (qx.core.Variant.isSet(“qx.client”, “mshtml”)) {
    qx.gfx.vml.Line.draw(pointA, pointB);
    } else {
    qx.gfx.svg.Line.draw(pointA, pointB);

    In “mshtml” (IE) the class “qx.gfx.vml.Line”, in all other browser the class “qx.gfx.svg.Line” is added to the dependency tree.

  • Pingback: WebKit == Mobile | Continuing Intermittent Incoherency()

  • The Real Napster

    What “real web browsers” are you referring to on iPhone OS? Slider controls, DHTML scroll bars, or any other kind of drag-n-drop interface that works in regular browsers should work in Safari (or Opera Mini or Aquari or some other browser) on iPhone OS if they’re “real browsers”. But they’re not.

    (P.S. In case anyone was thinking of replying with the assertion that the touch interface precludes browser drag-n-drop, Steve Jobs has a bridge he wants to sell you.)