I’m not entirely sold that the right solution going forward is to use the toolkits we already have, but if you’re building a mobile app today and you’re going to use a toolkit, it looks like (as on desktop browsers), Dojo should be your first choice. The webkitMobile variant of Dojo points to one possible way out of the “what to do about mobile?” conundrum regarding size and IE-induced bloat, but I have some hope that WebKit will improve quickly enough to make the toolkits of today obsolete on mobile phones entirely. Time will tell.

Hat tip: the Uxebu blog

Apple

iPhone, Safari

Google

Android, Chrome

Nokia

Series 60 browser

Plam

WebOS

Adobe

AIR web runtime

From deep integration with the platform to being the platform, WebKit in various forms is how nearly every credible smartphone now “does” the web. The major outliers here are the WinCE devices, Blackberry, and whatever Sony’s doing this week, but the writing is on the wall for them too. Mobile IE is a joke and the Blackberry succeeds in spite of its web experience. iPhone, Android, and Pre have raised the bar. The sucky-web center will not hold.

For a sizable chunk of the mobile browsers that a web developer would like to target today, that means that WebKit == Mobile. As predicted, the mobile world has beaten the desktop to the web of the future. It doesn’t hurt that WebKit is making deep inroads into the desktop, either….but then you could reasonably assume that they pay me to say that.

So what does a WebKit-only world look like? And how portable are our desktop-web skills and tools? I did a quick set of experiments this past weekend to see how much of Dojo you’d still need and what we could leave behind. The results are encouraging. The headline numbers for dojo.js are roughly:

You can grab a copy of this pre-1.3.0 version here (webkitMobile.dojo.js).

The big size wins (in decreasing order) were:

1. Moving to a QSA-only version of dojo.query()
2. Being able to use intrinsics for dojo.forEach, etc.
3. Dropping IE and FF-specific rendering, XHR, and style hacks
4. Using a common closure wrapper for the entire core

And there’s even more fruit on the vine. I think without too much more work I’ll be able to drop the current animation system in favor of pure CSS animations and can significantly simplify the XHR code which doesn’t do the straightforward thing to avoid terrible memory leaks on IE and very old versions of FF.

All of this points to where we could be if the browsers just got collectively awesome all of a sudden. That’s the good news. The downside is that still leaves a lot of janktastic spec mistakes to be worked around at nearly every level of the platform. This experiment suggests that there is still a price to be paid just to get the platform to a usable state. If we look at the APIs of Dojo, Prototype, or jQuery as a set of suggestions for the APIs that the web should expose, then it becomes pretty clear that we’ve still got a long long way to go. But we can do at least 30% better in the short run, and I’m very glad of that.

My friends over at SitePen beat me to the punch on my own patches, but that’s how it goes sometimes. Props to them for that.

As far as I know, it was a total surprise to the Dojo community (myself included). I can’t wait to get started writing apps for this thing and see what device APIs Palm has surfaced.