Ajax Performance

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.

Leave it to Apple to make web performance sexy

Surfin’ Safari just announced a new Web Inspector, and boy, does it sport a sexy network waterfall:

Look at that iTunesy widget for displaying the contribution of different content types to page weight. So sexy. The network details pane also provides access to all request and response headers.

This is a great way to catch up with the functionality provided by Firebug since 1.0 (with a much nicer UI, I would argue). Coupled with availability of Safari on Windows, Apple is making a clear play to remove any excuses a developer may have not to support Safari. Eagle-eyed readers may have noticed that the above screenshot, furnished by Apple, is of Web Inspector running on Windows.

Upcoming Presentation: The Ajax Experience, Boston

The first presentation I ever gave was at TAE Boston last year, and I’ll be there when it returns October 24-26 of this year. I live in Boston, so this is certainly the easiest for me to attend, and the Ajaxian guys bring in a great crowd.

Ajax Experience schedule finalized

According to the schedule, my presentation is slated for the late afternoon of the first day: Wednesday, July 25. Immediately before my presentation, in the same room no less, fellow Gomezian Patrick Lightbody will be presenting on Ajax testing with Selenium.

Also of note for readers of Ajax Performance will be a Thursday afternoon presentation by Steve Souders, Chief Performance Yahoo! I’ve had the honor of working with Steve from time to time over the years, and his team continues to be thought leaders on web performance. His talk is on performance best practices and the super secret YSlow project, a Yahoo! effort to build performance tools on top of Firebug.

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.

jsLex

By way of Ajaxian (and really, what isn’t, these days), I found JsLex, an interesting performance instrumentation project. The approach offers function level instrumentation of an entire project as opposed to the discreet, manual instrumentation you can hand-code using dojo.profile. While Firebug users have had access to comparable functionality since 1.0, this approach allows data to be collected, without plugins, from any browser.

jsLex offers two approaches to instrumentation. In the first, an ant task spiders through your build tree, injecting instrumentation calls into each method. Alternately, a web frontend to a compression and injection facility is provided.

Once instrumentation has been added, jsLex also offers some well developed utilities for digging through the data. Slicing and dicing of the profiler data is exposed through a web front-end embedded in the application. Custom metrics, comparisons of profile data between pages, and dojo.profile visualization are all provided, to name a few of the features that jumped out at me. The full list is available here.

I haven’t played with jsLex, but the biggest downside with this type of approach is the overhead: there must be a lot of it. I’m always concerned that a high overhead profiling tool, such as early versions of OptimizeIt and other Java tools back in the day, will have so much impact on an application that it distorts the true performance picture.

At this point, that’s just a concern without justification, but I would love to hear from anyone who has used jsLex. It looks like an impressive tool.

After my TAE Boston presentation, I spoke with some folks at Nexaweb about a very similar sounding project they were working on. I assume this is the same initiative as it builds on Nexaweb’s Universal Client Framework.

I got jacked :-(

In the great Dreamhost password leak of early June ‘07, some clowns replaced my happy Wordpress install with some trash. Looks like we were offline from some time this afternoon until now. All better, and it gave me an excuse to upgrade to WP 2.2.

GWT 1.4 provides easy, native support of image concatenation with special sauce

The RC for GWT 1.4 provides native support for image concatenation in a feature called ImageBundle. If you’ll recall, I discussed image concatenation in a round up last month, and it’s a key embodiment of our “First Principal of Performance Optimization” — reduce network requests as much as possible.

Given that this is Google, they had to take things to that next level. And by that, I of course mean that their implementation has a few twists and refinements so brilliant and elegant that they seem obvious in retrospect and make the rest of us feel unworthy. Because we are.

The aspect of ImageBundle that jumps out at me is the infinite cacheability of the images: the file name includes an MD5 of the image contents, so there is no need for even periodic HTTP round trips for if-modified-since or if-none-match checks. You can set the expiration date to the expected heat death of the universe, or beyond. Thus, network requests are only made when they are absolutely necessary. Only one network round trip is made at that time. Everything is as simple as possible, but not one bit simpler.

And to those naysayers who may suggest a pathological case where minor modifications to one or two contained images cause frequent downloads of the larger, concatenated image: it just doesn’t matter. As this post at edgeblog explores, it’s still the latency, stupid. The real cost of object downloads is the round tripping. Establishing a connection, sending a request, and waiting for the first byte dominate network times. The added marginal cost of additional contents is always a fraction of those setup costs as the bytes of the reply are in flight by the time you begin receiving the reply. And as bandwidth increases while latency remains relatively flat, the dominance of latency will only increase.