WebKit == Mobile

With the Pre/Mojo announcement, it’s becoming clear that WebKit has mobile all sewn up. It bears listing who’s betting on WebKit and where:

iPhone, Safari
Android, Chrome
Series 60 browser
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:

ShrinkSafe +gzip
Standard Build 79K 27K
webkitMobile=true 56K 20K
Savings 23K (29%) 7K (26%)

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.


  1. Posted January 22, 2009 at 1:06 pm | Permalink

    Sorry to be the bringer of bad news but the iPhone does not cache components larger than 25KB.


    This is *after* unzipping. Which is a shame.

    So to get really good performance on that platform you need to break your files up into 25KB chunks.

  2. Posted January 22, 2009 at 1:11 pm | Permalink

    Hey Dean:

    So yes, we know all about that problem too. I’ve got something in the works for that as well.

    All is not lost = )


  3. Posted January 22, 2009 at 3:40 pm | Permalink

    I ought to note Opera Mini, which has more installed phones than any other browser. However, they’re not smartphones. One interesting question is whether it’s worth catering to non-smartphone mobile browsers; Opera Mini is pretty good for the limited environment it’s used in (I use it all the time on my non-smartphone phone), but other non-smartphone browsers are horrid. There are way, way more of them than smartphones, though; “the mobile web” is actually two separate mobile webs, a high-end one (which as you note is almost all WebKit) and a low-end one (which won’t do most of the niceness that Dojo can provide anyway, so it doesn’t get the progressive enhancements).

  4. Posted January 22, 2009 at 4:39 pm | Permalink

    Hey Stuart:

    In this experiment, I’ve taken the position that non-smartphone browsers will usually get the “degraded” page (i.e., no scripting). Even as they pick up better and better CSS, those browsers really do kind of trail browser progress by a generation or so. That kind of split makes a lot of sense to how I think about building apps and I think that if you say “there’s webkit and there’s everyone else”, you can do a relatively good job of delivering the right experience to each. It’s one of those places where “progressive enhancement” isn’t so much a mantra or design philosophy as it is a high-functioning coping mechanism for folks who won’t build a site twice…which is most of us.


  5. Posted January 22, 2009 at 5:34 pm | Permalink

    You’d be surprised at how good Opera Mini is. There is also Fennec to consider — a mobile version of Firefox. I’m making my money building mobile sites at the moment. I’m not betting my living on webkit just yet.

    That said, I’m happy to use Ajax for Opera mobile but not CSS-based animations. There is some kind of weird re-rendering for Opera that screws with your JS.

    PS. Anyone who says that you can build a mobile site just by changing your style sheets is crazy.

  6. Posted January 22, 2009 at 7:04 pm | Permalink

    Alex: yeah, the smartphone/non-smartphone split seems a reasonable one to me, and smartphones are overwhelmingly WebKit or mobile IE.

    Dean: Opera Mini’s great, but you can’t really make it do interesting interactive stuff quite yet (although I admit I had to fall back to OM3 because OM4 doesn’t work right on my phone). I did ping the OM guys to say: is it possible to do iUI-style effects? Apparently all this sort of stuff is going to be possible in OM5, hopefully, which will probably bring OM5 up to par with mobile WebKit. That’s going to be a good day, then, because you can have smartphone-quality web browsing on any arbitrary phone. A pleasing day.

    I’d like to see Fennec take off, but I suspect it’ll be a while before it gets close enough to be viable, and by then WebKit may have eaten its lunch entirely in the mobile world. I hope not; I like Fennec (the little amount I’ve played with it) and Mozilla-based browsers have always had the most advanced JS support.

  7. Posted January 22, 2009 at 8:24 pm | Permalink

    Stuart, yeah that’s my point about Opera Mini. iUI style animations don’t really work. Ajax is fine so you can have some dynamic effects. But overall, it’s not worth it. CSS support is good but not as good as webkit.

    Mobile is new territory. There is an early leader but it’s still all about standards support in the long run. If Opera Mini worked just like its big brother then I’d take it more seriously. That’s not too far away.

  8. Posted January 23, 2009 at 12:18 am | Permalink

    On the Windows CE front http://torchmobile.com/ has a WebKit browser you can download.

  9. Posted January 23, 2009 at 5:10 am | Permalink

    PLAM? A new player in town!? Heh.

  10. dave
    Posted January 23, 2009 at 6:11 am | Permalink

    Why is it WebKit Mobile and not just Webkit.dojo?

    Is there some tradeoff that means this would reduce performance/functionality for Chrome, Safari etc.? Or would any performance increase be effectively unmeasurable on a proper desktop machine?

  11. Posted January 23, 2009 at 9:12 am | Permalink


    A fair question. Turns out that what’s good for mobile is good for Chrome and Safari too! All of the optimizations in this version are applicable to desktop webkit-based browsers. If you know you’re going to be targeting Safari/AIR/Chrome, then this is also the version of dojo.js you might want to be using. If nothing else, it’ll boot up faster due to the reduced parse time.


  12. Luis Alejandro Masan
    Posted January 23, 2009 at 9:30 pm | Permalink

    “PLAM? A new player in town!? Heh.”

    You have a “rendering problem”!

    Are you using WebKit? ;-(

  13. Matt
    Posted January 23, 2009 at 11:33 pm | Permalink

    >> The major outliers here are the WinCE devices, Blackberry, and whatever Sony’s doing this week …

    The browser on the latest BlackBerrys (i.e. Storm and I think even Bold) are using WebKit (with a much improved experience, I might add).

  14. Posted January 24, 2009 at 8:01 am | Permalink

    > but then you could reasonably assume that they pay me to say that.

    No, they pay *me* to say that. They pay *you* to make it true. :)

  15. sc
    Posted January 25, 2009 at 11:51 am | Permalink

    ucweb is the no.1 mobile browser in China.

3 Trackbacks

  1. By Ajaxian » webkitMobile.dojo.js: shrink it up on January 23, 2009 at 3:17 am

    […] turns out that Alex was scooped on his own work. He was playing around with the question: What would Dojo look like if it was WebKit […]

  2. […] web para móviles, ha dejado una puerta para crear uno especialmente para esto, como el WebKit Mobile de Dojo, esta, XUI quien tiene funcionalidades solo para navegadores que un dispositivo móvil […]

  3. […] 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 […]