Ajax Performance

In defense of Ajax for the iPhone

I suppose I have a more Ajax-centric view of the world than most, but I’ve been somewhat surprised over the past few weeks by the overwhelmingly negative reception to the iPhone development model I’ve seen around the blogosphere and from sites I love. The call for a ‘Real SDK’ is galling, and I think it reflects a prejudice against web applications and a lack of understanding of the progress achieved by the Ajax community in recent years.

I believe that Ajax on the iPhone represents nothing less than the future of mobile development, and we’ll look back on Apple’s decision to forsake a ‘Real SDK’ as an articulation of a bold and correct vision that perfectly fits where the market is heading. This isn’t the Newton; Apple is not ahead of its time.

To see why, let’s dive into the recent news and analysis, first catching up with our good friends at Ajaxian who continue to cover the Ajax angle as we near the iPhone release. Saturday they posted a roundup of articles by Joe Hewitt of Firebug fame and Robert X. Cringely.

I was happy to see Cringely’s article cover Safari on Windows as a move to improve developer support. Most of the discussion I’ve read elsewhere has focused on Apple’s slim chance of picking up significant market share. Coupled with the iPhone development environment, it’s clear that the real goal is to provide access to the WebKit platform to all developers to encourage first class support of Safari. The new Inspector released a few days ago is another (again, I’ll say it: sexy) part of that strategy.

Where I depart from Cringley is with his conclusion that, due to the difficulty of building applications that work consistently across browsers, Apple needs GWT as it is the easiest way for a developer of an existing web application to support Safari. This strikes me as almost silly as it assumes that everyone building Ajax applications is more comfortable with server side Java development. It’s far more likely that the easiest way to support a new browser is to test for it and make sure whatever framework you are using provides proper support. Chances are it does, and now you can do your Safari testing on Windows if you don’t have a Mac.

When you look at the momentum and commercial adoption of Ajax, it’s clear that the market for development frameworks is determined to overcome these challenges, and that says something profound about the advantages of the Ajax approach. That is, if developers are willing to deal with the annoyance of building complex apps on something as brittle as cross-browser JavaScript, there must be a damn good reason for it. And there is.

Flipping Cringely’s argument on its head, Ajax is successful because, despite the headaches of supporting applications across multiple browsers, it’s still a hell of a lot easier than writing and deploying applications natively on multiple platforms. The on demand software delivery model is compelling for reasons both economic and technical, and you need only look at the difficulty Microsoft had releasing a monolithic software package like Vista as opposed to the agility with which Google has pumped out release after release of Mail, Maps, and others. Ajax allows more applications which would traditionally have been only possible as thick client software to be moved to the on demand model, treating the browser as a VM for software delivery and execution.

The next logical stage of that evolution is offline access and syncing of code and data. Offline is necessary to solve the ‘What do I do when I’m flying cross-country and want to use my apps’ problem which has this far constrained Ajax to use cases that imply consistent connectivity. Offline support will also address one of the concerns Dion mention in the Ajaxian coverage — the latency of connections. Offline support is essentially a more robust and tunable caching model, so offline-enabled iPhone Ajax applications would be able to make connections across the network only as often as strictly necessary (and fundamentally, that’s the point of the Ajax model to begin with).

So, what Apple really needs from Google is Gears. With Gears, Google is very well positioned to address the offline question, and they have the partnership with Apple to deliver the native component necessary for proper offline support.

As I see it, the only other technical component necessary to make the iPhone SDK successful is access to unique iPhone functionality. As Joe Hewitt discussed on his blog, Apple will almost certainly provide access to iPhone specific features in the scripting engine of WebKit, and those features will allow developers to take full advantage of the rich interaction model provided by the platform.

Related is the concern that non-native iPhone apps will not have the look and feel of native code. However, Safari has long provided CSS3 features and enhancements to provide fine control of the presentation layer. This functionality was long overlooked in mainstream development because there was little reason to expend effort optimizing for Safari, but expect to see that change as developers target the iPhone.

This brings us back around to the criticism leveled by Cringley and others: developing for the iPhone, and the web in general, is difficult due to browser variation. Some worry about a return to the browser wars where the market fragments into competing, incompatible browsers and developers are forced to pick sides. This is not a compelling argument: at worst, a fragmented mobile browser market is only as bad as the fragmented market for mobile development we have currently. Also, these inconsistencies are precisely the niche that Ajax frameworks have rushed to fill, and there’s no reason to believe that analogues to YUI and Scriptaculuous will evolve to make interface design between mobile browsers as seamless as possible.

The web space is also very different than it was in those days — control is far more in the hands of the users and the web developers than the browser or device manufacturers. In fact, we are at the exact inverse of that situation; instead of web developers struggling to ensure that their application works well in whatever dominant browser they choose to support, browser developers now worry that Youtube, Google Maps, or any of the myriad other must have applications will work in their software.

But perhaps the most important factor behind the inevitability of Ajax for the iPhone is the way it opens development to such a broad community. Traditional mobile application development, with its ‘Real SDKs,’ is restricted to the few with the time or inclination to develop for a specific device. The iPhone’s model means that anyone with the time and inclination to build a web application is an iPhone developer. Certainly there will be a spectrum of applications, from web applications you happen to use on an iPhone to those that have been tuned for the interaction model and presentational features of the iPhone, but again, frameworks should make it easy for all developers to move towards the end of the spectrum that approximates native applications.

The iPhone is one of the first mobile devices, and definitely the first with a cell phone form factor, to provide a true browsing experience. But in a few years I expect all mobile devices to provide the same browsing experience. With that, the line between traditional and mobile web development will further blur, with Ajax frameworks helping developers deliver consistent and appropriate experiences on each.