I’ve been playing around with the coding mobile sites and webapps lately. Ironically, although Apple had first pushed for web apps with iOS 1.0 – it’s hard to remember that the iPhone did not let outside developers write apps for almost a year – mobile webapps are pretty immature compared to their native brethren. It’s like desktop applications versus the first-generation AJAX-enabled webapps, circa 2005.
Despite reports suggesting users are spending more time than ever inside apps, I’m still optimistic on mobile webapps and HTML5 eventually supplanting native apps in the far-flung future; the advantages of web development are just too much, and the problems now can be solved by technological iteration. That said, I’m knee-deep in mobile-optimized front-end code, and the general chaos in writing mobile web code has tampered my enthusiasm a bit. It’s going to be a hard-fought war to get the mobile web platform to a happy state.
The argument has been that HTML5 enables developers run the same code across multiple browsers and platforms. It’s true to an extent: web apps let us write clients in the same languages and frameworks1. With today’s coding infrastructure, our web controllers and AJAX code (in addition to the iOS/Android app, and third party devs) are front-ends to a private or public API which does the app’s real work. The web stack is becoming more and more of a client, with the business logic abstracted away into a backend service.
And while there’s a rich heritage and evolution of server-side development for websites – Perl, PHP, Python, Rails, node.js – HTML, CSS and Javascript have remained a browser’s lingua franca, yet are somehow are in a more chaotic state than the server-side posse.
For one, mobile browsers are still very limited. Javascript animations are slow, certain CSS3 and CSS2 rules don’t work or work differently, and both code size and screen size are restricting factors. Since the user interface expectation has risen significantly with desktop webapps and native mobile apps, the lack of processing power and finicky nature of mobile browsers2 frustrates users, developers, and makes for a subpar platform.
As to the perceived savings on cross-platform development time, it’s true up to a point; the wide range of mobile browsers, with varying capabilities and screen sizes, makes platform-inclusive development just as (if not more) painful as fixing up sites for IE6 compatibility3. Moreover, I haven’t seen a strong push for mobile webapps to define their own UI styling, so most are happy to emulate their target platform’s look-and-feel. There’s a little overlap in mobile code meant for Mobile Safari versus Android Browser (versus IE Mobile versus Opera Mini versus…), but targeting a platform this ways usually means rewriting a lot of front-end code, emulating the OS’s UI library, from scratch.
On the plus side though, the mobile web is an addendum onto a fairly mature desktop web platform. There’s a good number of us web front-end guys who have either made the move or are just waiting for the right tools and motivations to make the jump to mobile, and getting things up-and-running should be much easier than learning 3-4 separate languages on top of frameworks.
And the web is remains a fast platform: fast to write code, fast to deploy, fast to test and iterate. More than one company has recognized the web’s intrinsic advantages and are pushing forward with HTML-based clients. Though there will be more growing pains, I’m anticipating the day when mobile webapps are as easy to develop and use as, well, just webapps.
I’m counting HTML, CSS, Javascript, and whatever server-side language you use to serve templates.↩
Running out of memory trying to run Javascript code, not registering touches and swipes periodically, etc.↩
There aren’t that many mobile JS frameworks out there, and I’ve only seen jQuery Mobile even try to address mobile cross-browser compatibility issues.↩
