On June 11th, 2007, Apple held the WWDC Keynote where they talked about three things. Leopard, Safari for Windows, and iPhone apps. I don’t need to replay this for you all, but I will anyway – the Leopard announcements were for the most part rehashes, and Safari for Windows was simply fantastic news, both for users of Safari and for web developers. But the iPhone announcement definitely left a sour taste in many mouths, mine included. Not so much the lack of a true iPhone SDK, as I wasn’t really anticipating seeing that at WWDC (as hopeful as I was), but rather the buildup of the announcement.

One of those sour sour mouths is that of Wil Shipley, one of the founders of Delicious Monster. In his latest blog post, he decrys the idea of using JavaScript and Safari as a platform for developing iPhone applications. Many of his reasons, such as a lack of Keychain and difficulty in monetization, are valid. However, there are a couple things that I, as both a Cocoa and web developer, disagree with. Furthermore, it’s completely plausible that the iPhone SDK that we all want soooo bad will be something that runs in the iPhone’s JavaScript interpreter, which I’ll talk more about in a bit.

First, he spends a good time railing against JavaScript. Specifically:

JavaScript was thrown together by some dudes a couple years ago to make web pages kind of, like, do shit and stuff. It’s famous for being slow, hard to read, hard to program, and incompatible across different platforms.

This statement is pretty wrong on all counts, both with respect to JavaScript as a language and a platform for writing the client-side logic of iPhone applications.

  1. Hard to read/write. JavaScript isn’t any harder to read or write once you get used to it. In fact, it’s arguably easier to read, as JavaScript’s method calling syntax is significantly closer to C than Objective-C’s is. Someone with experience can read a function like:
Foo.prototype.bar = function(baz) {
	var foobar = document.getElementById("ohsnap");
	foobar.style.backgroundColor = "black";
};

…pretty easily. Compared to the same ObjC method:

-(void)bar:(id)baz{
   id foobar = [document getElementById:@"ohsnap"];
   [[foobar style] setBackgroundColor:@"black"];
}

There isn’t really a readability difference. Once you get used to the prototype syntax in JavaScript, it’s completely a non-issue – and I went from knowing zero JavaScript to doing full OO stuff in less than a weekend.

  1. Slow execution. This is mostly a per-browser thing (IE, I’m looking at you). And while I agree that, in generic web development, this is an issue, you don’t have to worry about any of that. Because the iPhone doesn’t run Firefox, Opera, or IE. It runs Safari, and specifically JavaScriptCore (which is part of the WebKit framework on OS X that runs as a JavaScript interpreter), which is the fastest out of any of them for most tasks.

Furthermore, the speed of JavaScript interpreters across the board (with the exception of Internet Explorer, as it’s pretty obvious that Microsoft, with Windows and Office, feels very threatened by web applications) is bound to increase significantly in the next couple years. With the rise of more JavaScript-heavy web apps, the optimizations should definitely continue as they have for the past couple of years. Stuff like JIT compilation of code will help a lot.

And all that being said, JavaScriptCore is already pretty damn fast. You can pull off some decent framerates with even full-screen animations on the iPhone’s version of Safari. It’s no Core Animation, but it’s usable.

  1. Incompatible across platforms. JavaScript as a language is pretty standardized. The DOM bindings in the browsers are where the incompatibilities lie. It’s fairly easy to spot where to workaround browser incompatibilities.

And besides, if you’re not concerned with generic web development and are only focused on writing iPhone apps, who cares?! You’ve got one target, Safari. Period. You don’t have to do the cryptic tests, like checking for the existence of document.all, to determine what browser you’re running on.

Apple’s got a decision to make: it can try to fix all the myriad problems with developers actually trying to deploy non-free applications using AJAX, OR it can say, “Look, this isn’t going to be easy, but we’re smarter than hell, and we’re going to make a secure, tight, mini-Cocoa for the iPhone — this is our chance to start fresh and do everything right. No NSCells, everything animated, resolution-independent from the start, no CF stacks under and NS stacks, always garbage-collected, all database-driven…”

And now we come to the crux of my argument. Who’s to say that this new mini-Cocoa couldn’t be written as a set of JavaScript calls embedded in the interpreter? JavaScript is already all garbage collected. Apple could embed technologies such as Core Animation right into JavaScriptCore, so creating an animation with CA could be as simple as a couple JavaScript functions, exposed to John Q. Developer in a similar fashion as the window and document objects.

Here’s the kicker – since these functions and properties would be compiled into the interpreter, they would be running as native, (I’m assuming) Cocoa code, so any possibility of slowdown would come from the JavaScript lexer and not from the actual JavaScript code. Therefore, your only speed limitation is that of JavaScriptCore’s ability to quickly process code.

If Apple’s claim of security threats presented by Cocoa/Obj-C apps is real, then it completely makes sense for them to want to sandbox it. That’s not stopping them, however, from implementing an entire application framework into iPhone’s JavaScriptCore. Throw in SQLite storage and the ability to save the app to the iPhone’s app launcher, and you’ve got yourself a pretty rock solid, secure application platform. And it wouldn’t surprise me if this is the compromise that Apple comes up with.

Granted, there are definitely speed issues to contend with; Apple’s only got a 620 MHz ARM processor in the iPhone, so it may just not be fast enough. But languages like Python have much faster interpreters, and may be investigated rather than JavaScript. But if Apple really needs the sandboxing that something like Safari requires in order to open up to native application code, well, I’ll take what I can get.

Also, someone please tell Shipley that you can’t do “programming in AJAX”. 🙂