Consider the following:
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
John Resig’s war on War on Browser Sniffing
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
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.”
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 && //>>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?