Mobile Web App 2: Picking a UI Framework… or Not

Now that I know roughly what I want to build in my app, it’s time to pick a UI framework.

Evaluating the libraries

I looked at 3 javascript frameworks that are geared toward mobile/touch development: YUI 3.2, Sencha Touch, and jQuery Mobile.

YUI 3.2

Pros: I use YUI 3 a lot at my day job, and in general I like it a lot. It’s a mature, capable library with some very smart folks working on it. They haven’t historically focused on mobile/touch, but in this recent release they added touch event support, gesture support, and support for css3 transitions. Also, the library is very modular, so it would be easy to keep the filesize small.

Cons: Has only one mobile UI widget – the ScrollView. And when I loaded up the ScrollView on my Droid Incredible (running Froyo), it didn’t work. I found this very disappointing, since Android would be a major target for my app.

They have no publicly available browser support policy for mobile devices, although I’ve been told they’re working on one.

Conclusion: It’s not ready yet, but has the potential to become a really good mobile library.

Sencha Touch

Pros: They’ve taken all of the visual elements of an iPhone app, and recreated them in javascript.

Cons: They’ve taken all of the visual elements of an iPhone app, and recreated them in javascript.

Ok, but seriously – Sencha is a very slick-looking framework. They have a full complement of UI widgets, and they look great, if a bit iPhone-specific for my tastes. All of the demos worked beautifully on my iPod Touch running iOS4.

But their stated browser support is pretty narrow: just iOS and Android, and some of their demos were buggy to non-functional on my Droid. Furthermore, there’s no possibility of progressive enhancement – the page is assembled completely from javascript, so it’s all or nothing. Either the user is on a device that Sencha supports, or they’re out of luck.

Conclusion: It’s not ready yet. Furthermore, it doesn’t really provide the breadth of support that I’m looking for. But iPhone developers will love it because it provides a familiar model, and it doubles the number of platforms they can target.

jQuery Mobile

Pros: Because it’s jQuery, there’s a huge developer community built in. Claims to support a huge variety of different browsers and devices. Full set of proposed UI widgets that look great.

Cons: Not actually released yet, so who knows if it will live up to the claims. Plus, jQuery is less modular than YUI, so I’m concerned about the size.

Conclusion: It’s not ready yet, but has the potential to become a really good mobile library.

After looking at these three, I’ve come to the conclusion that there’s no javascript library in existence right now that does exactly what I want. A lot of smart people are working on a lot of great stuff, and it’s all really early in development, and it’s just not ready.

Having come to this conclusion, I started to ask myself whether I really need a javascript library at all. On a desktop app it doesn’t matter as much – a few wasted kilobytes are no big deal over a high-speed connection, especially when the most popular libraries are likely to be cached. And the niceties that they provide make development a lot more fun.

But I think when you get to mobile the equation changes, for two reasons: browsers are more similar, and waste is much less tolerable.

A big part of the value that javascript libraries provide is normalizing between IE and everyone else. But there’s no IE in the mobile realm. (Well, there is, but it’s small enough that I can happily ignore its existence, and plan to continue doing so.) So it becomes a lot less annoying to work in plain javascript. There are still a lot of browser differences, but at least you don’t have to write everything twice.

But even more importantly: when you’re on a slow, spotty connection and every download drains your battery, any amount of waste becomes intolerable. And there’s waste when you use any javascript library – even with a modular one like YUI3, you’re never using every single line of code that you pull down.

If you want people to keep using your app, speed is the second most important thing you must have. (The most important thing, of course, is that it does something useful or entertaining.)

So, my conclusion is: none of the above. I’m going to develop BrewTracker (our working name) without relying on any javascript library or UI framework. (If I really get annoyed by this I might turn to a very bare-bones library like XUI, but I’m hoping I won’t need to at all.)

I’m going to attempt to be minimal and efficient in my javascript, and truly follow a strategy of progressive enhancement. I’m going to avoid making heroic efforts – like recreating momentum scrolling in javascript – for small design wins, like the ability to have a fixed-position bottom nav. And I’m prioritizing broad accessibility and usability over flash and flair. After all, everyone likes beer – even people who dare to use a Palm or a Blackberry!

Coming up next: I try to persuade Andrew and Dom to guest-blog about BrewTracker’s design.

One Response to “Mobile Web App 2: Picking a UI Framework… or Not”

  1. monk-eye Says:

    a PALM is also a beer :) very nice
    brewed by

    good luck with the progressive enhancing