Ajax Performance

iPhone developers are cranking

Greetings from Denver, where I’ll be until tomorrow evening for a wedding. With the trip, I haven’t had as much time to post, but I have enjoyed showing off my iPhone to my wife’s family. It definitely shows well.

I have been able to keep up with my reading, and as always there are a slew of iPhone development news items. First and foremost, Apple released their development documentation, a good sized collection of articles on device specific design and development information.

Building on top of personal experience and the help of this documentation, the development community continues to push ahead. And Joe Hewitt is among the leaders as always, recently releasing a native iPhone skin that puts web apps on a similar visual footing with native apps. This is achieved in part by using the WebKit CSS extension -webkit-border-image to lay out horizontally scalable buttons composed from a single image. This technique is covered in great detail in an article by Matthew Krivanek, where the performance benefit of the approach (fewer network round trips, our First Principle of Performance Optimization) is discussed.

Matthew’s example demonstrates 3 different buttons of different colors, but each is backed by a separate image. I wonder if you could expand on this image concatenation trick to place all 3 buttons in the same image (as discussed here) for even more EDGE round-trip avoidance.

A few thoughts on the iPhone, plus a news round-up

So I spent most of my first weekend with the iPhone enjoying the experience, just playing with the new toy. I was having so much fun that I almost forgot the 20 painful hours I spent waiting for the thing to activate. I’m not sure who is most to blame, but from following the thread on Macrumors it seems like people porting from Verizon were the most afflicted. AT&T certainly deserves a stern scolding for the extent to which their procedures fell down over the weekend (hour long waits on customer service lines, crashing activation servers which made their call center staff even more clueless, etc).

After that rough patch, it’s been an almost completely enjoyable time playing with the device. It’s a fantastic iPod, a better-than-expected phone (call quality has been great, but maybe my old Verizon phone just sucked that much more), and an amazing little computing device with a better-than-expected typing experience. Mobile web and mail are great, but it’s clear that we are in the very early days of the software:

• Safari has not been updated to 3.0 yet. I was hoping to repeat my Dojo Chart benchmark, but the lack of SVG support makes this impossible.
• SMS support is really nice, and it looks a lot like iChat for iPhone should look. Here’s hoping rumors of iChat in a forthcoming update are true (and let’s make sure it’s multi-protocol while we’re at it).
• JS performance looks pretty bad, according to numbers collected by fellow New Englander John Murch. The purely client-side JS numbers seem to be about two orders of magnitude worse than numbers pulled from Safari on a MacBook Pro. Assuming these numbers hold up, they put the 5 second limit on JS execution in a new light. Anecdotally, JS heavy apps like Google Mail feel slower (but not painfully so) than when running on a laptop, even when loaded over wifi.
• The inimitable Joe Hewitt has built the first beta of Firebug for the iPhone. It proxies console.log() calls over the network to be viewed in a Firebug console on another system. I would imagine that whatever SDK Apple releases will use a similar mechanism for debugging code running on the device, though I hope they also provide an iPhone emulator.

The big lesson here is to profile that Ajax code. Hopefully there are some performance tweaks coming in Safari 3, but the nature of this device means that some of the comfortable assumptions we tend to make in Ajax development are no longer true. The combination of a slow network (when not on Wifi) and a slower JS engine means that we need to be especially careful of how much code and data we send over the network as well as how much executes on the device. Attention to performance may well prove the difference between a usable iPhone app and an annoying one.

I got it!

Activating my iPhone now. I will post some observations once I make them. Some of them may even be performance related.

Ajax developers rush to support the iPhone

Just a quick post in follow-up to my previous iPhone-Ajax lovefest: a couple of links from Ajaxian about already released Ajax SDK’s from Aptana and Morfik. Morfik even has an app ready for consumption: iChess.

With any luck I’ll be playing some iChess by 7PM tomorrow.

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.

It’s official — Ajax for the iPhone!

As I discussed way back in January, Ajax seems like the perfect development methodology for the iPhone. Apple is reluctant to ship native 3rd party apps on the platform, but the device runs a full-featured Safari browser.

Well, according to the Mac Rumors reporting of the WWDC keynote address, Apple agrees. The third party development toolkit for the iPhone is Web 2.0 / Ajax. More details as they become available.

Update: Here’s a bit more from AppleInsider.

Ajax for the iPhone

While I’ve never really talked about platform preferences here, I should in the interest of full disclosure mention that I’m an Apple fan. Like many, I’m a relatively recent convert, and I came to Apple by way of Linux. OS X seemed like a perfect fit — everything Just Works, but you can drop down to a terminal and geek out if you so desire. So naturally I was following along closely with the Macworld keynote to see what Steve Jobs would sell me next. And since we have about 5 months until I can buy it, let’s consider briefly the implications of a few key design decisions, specifically as they relate to Ajax.

The demos of Safari were what impressed me most, and I agree in principle with the Safari developers when they talk about the impending end of the ‘mobile web.’ At least, I agree that Safari on the iPhone represents the end of an era where it was necessary to apologize for the mobile web. However, immediately after the keynote, potential early adopters started getting some bad news as word spread that 3rd party apps would not be welcome on the iPhone. Today, this was confirmed by Jobs.

The silver lining for those of us in the Ajax space is that we will have a captive audience of users hungry for innovative 3rd party software, and there’s no other way to deliver it than through Safari. We have the opportunity to create powerful new browsing experiences for mobile users, potentially using techniques such as Brad Neuberg’s incredibly cool work on the Dojo Offline Toolkit to provide seamless operation when a connection is unavailable.

So, while I agree with the Safari developers that the mobile web will hopefully no longer be the ugly stepchild, I don’t think the mobile web as a separate concept is necessarily going away. There will still be specialization of mobile apps, but instead of specialization to work around the inherent limitations of the platform, it will be specialization to build applications with all the richness and vitality of native applications. Ajax will play a huge role there.