PhoneGap and JavaScript

I’ve been working on some pretty fun changes to PhoneGap recently, which hopefully will be merged into the main branch soon. (Brock? Any word on that? It’s now 12 days, and counting) In my branch of PhoneGap I added console logging support, I implemented queueing of commands so they don’t walk over each other, and finally (and perhaps more importantly) improved the JavaScript build system and infrastructure.

PhoneGap’s JavaScript Structure

PhoneGap is broken up into several different .js files, each of which implements a part of the PhoneGap API. And with recent changes to PhoneGap’s Objective-C code, the implementations of those commands are divided nicely into their own separate classes. Additionally, there’s platform-specific implementation hooks of those APIs which make the necessary calls in to the native code that implements those commands. At build time, a Rakefile is used to compile these together into one single “phonegap.js” file that can be included into your application.

But in the main branch currently there’s a number of bugs that prevents this system from working. The JavaScript files were being loaded in a bad order, causing prototype methods to be overwritten instead of extended.

I’ve hacked something together to improve on this, but this is really just a stop-gap measure. Really what should happen is an actual JavaScript framework should be adopted to help with class loading, extending classes, and implementing interfaces.

JavaScript Frameworks FTW

I’m a big fan of MooTools, so most of my day-to-day web work is in that framework. But really, most libraries solve the basic problem of “Here’s a base class, I want to either add to it, or subclass it to add more behaviour”. You never know how much you rely on something like that until you have to do without.

I found myself in the uncomfortable position of having to implement prototype-based inheritance by hand, and not in the fun way. This brings me to the main reason for this post, besides the subtle prod to Brock.

I want to see a client-side library that works well for light-weight apps, but still provides capabilities to extend classes, find elements using CSS selectors, provide helper functions for performing CSS-based animations, and provide event binding and closure-wrapping support.

I started toying with JQTouch, and while it’s certainly intriguing, it doesn’t solve some things just yet.

1. It’s still based on the stock jQuery, which is still pretty large, weighing in at 56KB
2. jQuery’s event object doesn’t support any of the iPhone’s touch and rotate/scale event properties. You can get at it by saying “event.context.”, but at that point why bother? The native event object is just fine.
3. It doesn’t address some basic issues I have such as function binding

So far I’ve managed to resolve my above issues with PhoneGap’s JavaScript API for the time being, but long term I think there’s some definite needs for the iPhone platform in general. We need to lose the platform-independant thinking of the standard frameworks (“Am I in IE? Am I in Opera?” needs to go). We need to have something that improves upon the already excellent CSS-based animation support of WebKit, and provide more abstract behaviours. And finally, we need to provide capabilities that let us define class-based applications with rich event and callback binding support.

The reason we’re developing applications under PhoneGap is because we want to build apps faster than we could if we developed in native Objective-C. So we need to have a JavaScript library that doesn’t get in our way, and actively solves the problems with JavaScript that WebKit doesn’t already solve.