It’s been an exciting year for the mobile Web. Adoption of HTML5 and CSS3, improved performance in mobile browsers, and an explosion of mobile app frameworks mean it’s more feasible than ever to create rich, interactive Web experiences for mobile devices. Using a wrapper like PhoneGap, you can distribute them via the native app stores for iPhone, iPad, and Android —targeting multiple platforms with a single codebase.
Or can you?
I needed a platform for Pints — a mobile app that answers answer the question, “Which beer should I order?” As someone who works in Web technologies on a daily basis I saw HTML5 & friends as an alluring option.
Pints isn’t complicated: a home screen, a few lists screens, a few forms. Its greatest complexity lies at the data level: as an iPhone app destined for San Francisco bars it can’t possibly rely on an Internet connection, so it has to keep a local copy of the beer database and sync it with the server when that’s available. HTML5 has the necessary building blocks in the form of several offline storage options; it’s just a question of writing the synchronization code.
Mobile Web developers have a plethora of frameworks to do the heavy lifting for them: animated transitions, toolbars, buttons, list views, even offline storage. Most of these are new and the landscape is shifting rapidly. I started Pints in jQTouch, then migrated to jQuery Mobile, and finally rewrote the whole app (now in private beta) in Sencha Touch. Along the way I also investigated Appcelerator’s Titanium Mobile. Here’s what I found:
But even in my simple test app there were performance issues. Page transitions can be jumpy or missing, and there are periodic delays in responding to tap events. And while the project is technically active, the original author has moved on and development seems to have slowed.
jQTouch is available under the permissive MIT License, one of my favorite open source licenses.
jQuery Mobile is the new kid on the block. Announced in August 2010, it’s quickly progressed to a very functional Alpha 2. It takes a similar – but more standards-compliant – approach to jQTouch and feels very much like that framework’s successor, with a broader array of UI controls and styles.
jQuery Mobile’s performance is variable (though better than that of jQTouch), particularly in responding to tap events rendering animations. It also lacks a small number of key programmatic hooks that would permit easy creation of more dynamic apps. For instance, there’s an event that triggers when a page is about to load (i.e. slide into view) but no way to tell the associated handler code what UI element resulted in the page switch, or to pass additional information to that handler. I was able to create workarounds but hope that future versions will take a cue from jQTouch and build out this functionality a little more.
jQuery Mobile’s documentation is a little scattered but improving; I’m hopeful that it will become as robust as that of the core jQuery library. (Note that jQuery Mobile is really a mobile counterpart for jQuery UI, not for jQuery itself, on which it builds.)
jQuery Mobile is available under either the MIT or the GPL2 license.
Sencha is far more extensive than its competitors, with a vast array of UI components, explicit iPad support, storage and data binding facilities using JSON and HTML5 offline storage, and more. (It’s very cool to manipulate app data in one of Sencha’s data structures and watch the corresponding list update in real time.) It’s also the only Web framework I’ve seen with built-in support for objects that stay put (like a toolbar) while others scroll (like a list).
For all that apparent extra weight, Sencha performed noticeably better and more reliably than either jQTouch or jQuery Mobile in my tests, with the exception of initial load time.
When working with a library or framework, it’s usually counterproductive to “fight the framework” and do things your own way. Given how extensive Sencha Touch is, that means your app will probably end up doing just about everything the Sencha way. I’d originally used WebKit’s built-in SQLite database for offline storage but ultimately eliminated both complexity and bugs by moving that functionality into Sencha’s data stores.
The documentation, while extensive, has odd holes. Between those and the sheer size of the framework, I spent a lot of time fighting bugs that were difficult to trace and to understand. Responses to my questions in the developer forums were more frequent and helpful than with the other frameworks, but still ultimately insufficient. Sencha provides paid support starting at $300/year; I strongly considered purchasing it but oddly, their response to my sales support inquiries was incredibly underwhelming given my interest in sending them money.
Sencha Touch is available under the GPL3; under a somewhat confusing set of exceptions to the GPL that seem similar to the LGPL; or under a free commercial license.
But that advantage is also its greatest disadvantage: you can only target the platforms Titanium supports, and you’re tied to their developer tools. As if to prove this point, my test app quickly got into a state where it wouldn’t launch on the iPhone. Titanium doesn’t include much of a debugger; Titanium projects can’t be run and debugged in XCode; and it ran fine in the simulator, leaving me with no real way to attack the problem.
Rebuilding my app on three of these four frameworks was tedious but educational. I like jQTouch but have trouble believing it will evolve much from here. I’m rooting for jQuery Mobile for its simplicity and its very Web-centric approach to development…but it lacks a few key features and doesn’t perform as well as Sencha Touch.
It’s unfair to compare an Alpha 2 product with a 1.0 one, except in one respect: I need something now. Which brings me to Sencha Touch. I was initially impressed with its performance and breadth, but put off by its development style. As I’ve dug in, the holes in its documentation have been frustrating but the breadth has continued to impress me, and I’ve gotten more used to the coding style. The option for paid support is tempting, and I’d probably buy it if they’d answer my emails. But for now, Pints is a Sencha-based app.
I haven’t answered the big question: can a Web-based app really hold its own alongside native apps? And if so, are the challenges of getting it there worth the benefit of a single codebase?
Two weeks ago I was leaning toward no. Pints was in performance and bug hell, hanging for 10-15 seconds at a time; scrolling was choppy; and other animations were inconsistent.
But I’m hopeful again. In my next post I’ll discuss why, what I’ve learned, and my perspective on mobile Web apps today. I’ll also cover PhoneGap and other methods of distributing a Web app in a native wrapper. Stay tuned.