Monday, June 25th, 2007

In defense of Ajax for the iPhone

Category: iPhone

Ryan Breen has been reading our coverage on the iPhone and has some opinions that he lays out in defense of Ajax for the iPhone.

He comments on the latency issues, how offline storage can come into play, the place for Ajax frameworks, access to “native” features, and community, finishing with:

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.

All good stuff. Although I bet some of the Nokia guys, with their WebKit phones and saying “look at me!”.

Posted by Dion Almaer at 12:19 am

4.1 rating from 18 votes


Comments feed TrackBack URI

Wise Words!

Comment by Калоян К. Цветков — June 25, 2007

Main factor is first, the open community and second, that if Safari is well-implemented most security issues are also gone when developing with evolved web-standards ;)

Comment by mg — June 25, 2007

These claims sound like iphone excuse making.

If any web app developer is automatically an iphone ajax developer, then any java developer is automatically a java mobile developer.

Web applications are ill-suited to mobile devices. J2ME works, and works well, for building mobile apps, and you don’t have to be (too) phone-specific. I can’t fathom how a browser-restricted model could be superior to that.

Phone-specific SDK’s tend to be used either because the app needs to have access to local resources beyond what J2ME offers, or because the app needs the raw performance.

Comment by Joeri — June 25, 2007

I don’t think anyone has anything against Ajax or has any doubts of its abilities. But it’s the fact that Steve Jobs is pushing it to be on par with a real SDK, is what people are not happy about.

Comment by Jordan — June 25, 2007

Yea, you wouldn’t want AJAX to be a REAL SDK – God Forbid! Let’s leave it like it is – implemented differently in different browsers from now until eternity. That’s what makes it fun! NOT!

Comment by Joe — June 25, 2007

Call me naive, but could someone articulate an argument for what an SDK on the iPhone would provide that you can not access through an AJAX web app?

So far all I have heard for an argument is “because,” which hardly seems like a well thought out argument for an SDK.

Comment by Elroy Jetson — June 25, 2007

Providing an SDK has the intrinsic value of causing developers to conform to specific standard. In the case of the iPhone using “AJAX” as the primary development platform makes those standards much more loose. Now some will argue that this is good, and others will argue that this is bad. However, I believe that having an SDK creates more value for the END-USER because the applications tend to be more dependable in the end. That’s what we’re here for right: to please the user…

Comment by Will Gillen — June 25, 2007

Basically, you can’t to anything that apple didn’t expect it to do… coming from a PalmOS background, I can tell you there are lots of things device manufacturers don’t expect you to do, for example on the UX50, there are programs to remap the keyboard, recreate the UI API to implement a different standard design, implement a different memory handline that allows programmers to use storage memory as if it was dynamic memory (which is not much slower, since storage is also RAM), change the battery settings, use antialiased fonts… so yes, there are lots of things you can’t do in a language that doesn’t provide direct hardware and API access.

However what’s probably more important is how Apple designs the JS API. For example, there’s no even remotely usable way for bitmap reading in JS… the only way is CANVAS, but that gives you a 3 dimensional array, so the overhead is really enourmus. Also, you’d need additional methods and data types to handle binary data. In fact, you’d need a whole array of native data types, since JS is not meant to handle files or any other kind of raw data. Also, you need interface classes if you want programs to look consistent, and a whole new security concept. I don’t think the problem is JS… the problem is that I don’t trust them to solve all these problems. To me it looks like they expected AJAX to be the “easiest” way to allow third-party apps, without thinking it through.

On the Plus side, JS is already running in a (relatively) secure environment and, more importantly: Since JS is an interpreted language, it can be paused and resumed at any time (not to mention that it simply cannot crash anything but the currently running script) which makes it a perfect “neglectable” citizen on the iPhone, who quietly disappears into the background whenever something urgent (say, a phone call) comes up.

Comment by Hans Schmucker — June 25, 2007

Without an SDK we can’t build useful tools like AdBlock, Greasemonkey, BugMeNot, Google Translator Toolbar, Linky, etc. And using AJAX it would be next to impossible to write applications like speech recognition software or video conferencing software (Skype).

Comment by Jordan — June 25, 2007

If the phone is a huge success, then one good side-effect will be that it will help produce better compliance, and it will be that much harder for a “developer” to get away with producing a site that relies on IE.

Comment by Clarence Odbody — June 25, 2007

Interesting input on the need for an SDK. Don’t all of these arguments presuppose that Apple would have made available these services, like hardware access for speech recognition or video conferencing? Or is it assumed that if you can put an application on the phone that the SDK is fairly irrelevant and you can by pass it to talk to the hardware directly?

Interesting list of apps Jordan. Adblock is already built into Safari. Greasemonkey is a plugin to firefox. None of those require an in SDK for the phone to use as they are dependent on the browser and its SDK. I am not as familiar with the other apps.

Comment by Elroy Jetson — June 25, 2007

The Javascript “SDK”, from what I can gather, will be stuff like “openGoogleMap()”, “onFlipScreen()”, etc.

Without an environment where you can talk to the device itself, how are we going to see apps like …

a) A VNC/RDP client
b) A DivX video player
c) Any game other than something that can be done in JS currently
d) An SSH client

The iPhone may or may not come with those example apps. The point is, the only “apps” that seem feasible are the typical web CRUD apps with a bit of AJAX goodness.

Look at all the interesting apps people have written for Nokia’s Symbian/J2ME platforms for more examples.

Comment by Russ — June 25, 2007

The Firefox extensions are just examples of ideas that would be useful if the iPhone was open up to developers. The details of the specific examples aren’t important (such as the fact that I choose Firefox extensions) but the spirit of having extensions is important. It shows that only with an open environment can developers be encouraged to make tools that truly maximize the potential of the underlying platform.

And yes, an SDK presupposes that certain services will be made accessible. It’s implied when people demand an SDK, they’re also demanding a pluggable architecture and public APIs. Conversely, it’s also implied that if a product were to offer an SDK, they will also offer some services that the SDK can call, or else they won’t really be offering anything at all won’t they?

Comment by Jordan — June 25, 2007

Apple: Buy our $500 web browser that fits in your pocket, and… has our logo.

World: Really!!!?? And I can use my fingers for everything?!! Wow, Apple, you are so cool!

:-) (sorry)

Comment by Ryan Gahl — June 25, 2007

Apple: Buy our $500 web browser that fits in your pocket, and… has our logo.

Where’s the Apple logo?

Comment by Trevor — June 25, 2007

“Apple: Buy our $500 web browser that fits in your pocket, and… has our logo.”

Last I checked, it was also an iPod and.. what else… didn’t it have some kind of, you know, PHONE capabilities too? Nah, that would be crazy.

Comment by Jerkface — June 25, 2007

This is simply a case of Apple wanting control over what goes on the phone. By not providing tools for devs to make typical device apps they are keeping the phone locked down and any apps have to play in the safari sandbox.
Maybe iPhone v2 will have a proper SDK that will allow apple to have control over what type of apps and how they look, but for now, it’s web only apps and an overpriced phone. I’ve done both handheld web apps and more traditional apps on a handheld device, I know which one I prefer and it ain’t a browser.

Comment by Kevin — June 25, 2007

Who’s going to write apps for iphone anyway? What’s the point? All these Apple fanboys rushing the stage. sad…

Comment by jorne — June 27, 2007

Leave a comment

You must be logged in to post a comment.