"So this is basically a JavaScript wrapper for Cocoa on the iPhone?"

I could be wrong but I don't think so. I think it's more akin to http://www.tiddlywiki.com/ where it's just all javascript/html/css running in a browser locally and data storage is done by saving files or by adding more xml entries to an existing file.

davidw is right. Stuff like not having to manually manage memory is a big deal (not to mention not having to deal with stuff like pointers or waiting for Apple's SDK to come out)...

I think you're wrong :)

"Jiggy" is a native iPhone app that hosts these little Jiggy apps, which are written in JavaScript but have nothing to do with HTML/CSS. The site talks about "Jigglins" which are written in Objective-C and add functionality to Jiggy, like the one they wrote that exposes part of UIKit (the iPhone's GUI API).

So you need these little Jigglins wrappers for every Cocoa API you want to use. They do mention a code generator that I assume is for this purpose though. I assume that's how PyObjC and RubyCocoa do it to.

All in all, this is an interesting idea, and it might be nice for simple apps and experimenting. But I've written some iPhone apps, and I can tell you this just doesn't seem worth the trouble. I did try installing it, and it seg faulted, so I gave up. We'll see once it matures a bit, but by then Apple's iPhone SDK will most likely be out (hopefully with Objective-C 2.0's garbage collection).

Plus, the fact that javascript is garbage collected doesn't mean that jiggy is. If they are really just calling out to objective-c libraries, than either they are doing their own really tricky memory management, or they'll have to force it up to javascript.

"not to mention not having to deal with stuff like pointers or waiting for Apple's SDK to come out"

Well, you don't have to wait, as evidenced by every iPhone app, Jiggy included.

And since when did garbage collection mean not having to deal with pointers? Not having to deal with memory management is not the same thing. In Java, everything is basically a pointer.

If it's done right: easier to do simple things with, faster development cycle, run time evaluation of code... all the usual reasons why people use interpreted languages instead of compiled ones.

I take it you've never used Objective-C and Cocoa.

Objective-C is a very dynamic language, especially among compiled languages. It was based on Smalltalk, the same language Python and Ruby were influenced by.

There is really very little room for JavaScript to improve upon Objective-C.

Javascript is simpler - but more importantly, much more popular than Objective-C. It's also garbage collected, a feature that Objective-C may also have these days, but not when I last used it a couple of years ago.

Javascript's also a hell of a lot more popular than ruby, haskel, lisp, <insert your favorite dynamic language here>, etc. But nobody here is saying "Let's give up ruby and switch to Javascript!" Popularity is not everything.

(It's also worth noting that Objective-C itself may well be as popular, or more so, than most of those same languages. It is, of course, a difficult thing to measure, but there is some evidence to suggest its at least more popular than languages like Lisp)

API's count a lot too. You'd have to look at two equivalent bits of code and see what things look like.

Still, though, you can do some interesting things with interpreted languages, like eval()...