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: jQuery.support. More information about it, feature detection, and what this feature provides can be found in the jQuery.support 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).

dojox.gfx

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.

excludeStart(“webkitMobile”)

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");

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?