First Look at Cappuccino and Objective-J

You've probably heard of 280 Slides, which is an exceptionally polished Keynote-like presentation app for the web. The creators, 280 North, today published the framework and language used to create it, called Cappuccino and Objective-J, respectively. I only had a few hours to play with both, so keep in mind this is a very early review.

The executive summary is that Cappuccino is re-implementation of many of the basic parts of Cocoa, and Objective-J is a language which looks nearly identical to Objective-C and "compiles down" into JavaScript. You can also use JavaScript right inline with Objective-J, similar to how you can use C in Objective-C.

Mac OS X Leopard has 82 built-in frameworks, and Cappuccino implements portions of only two of them: Foundation and AppKit. There is an implementation of certain data structures of Core Animation as well, but I think it's misleading to call it a port because there's no OpenGL underlying it so none of the fancy 3D effects are available.

There is a lot of one-to-one mapping of common classes, such as CPString being equivalent to NSString, CPTextField being equivalent to NSTextField, and so on. Some of the CoreGraphics/Quartz API is implemented as well. Browsing the Cappuccino class documentation gives you a pretty good idea of what's going on. 280 North has done an incredible amount of work here.

That said, you generally won't be able to take a modern, multi-framework Mac app and "recompile" it for Cappuccino. Some small apps might be able to pull it off with a bit of renaming and reshuffling, but any moderately complex app would be stranded. As a simple example, there isn't a CPTableView, but there is a CPCollectionView, which I assume is close to NSCollectionView.

This isn't a knock against 280 North — all of this is really, really difficult to do. It's just important to understand that this doesn't mean all Mac apps can suddenly run on the web.

What it does mean is that Xcode and Interface Builder are now reasonable prototyping tools for web apps based on Cappuccino, and Mac programmers can now quickly become very effective client-side web developers. The transition is somewhat similar to developing for iPhone — fundamentally similar concepts, but a slightly different inventory in the utility belt.

What's most shocking initially is how practically anyone could mistake Objective-J for Objective-C:

@implementation AppController : CPObject { }



- (void)applicationDidFinishLaunching:(CPNotification)note

{

    theWindow = [[CPWindow alloc] initWithContentRect:CGRectMakeZero()

                styleMask:CPBorderlessBridgeWindowMask];

                                            

    contentView = [theWindow contentView];    

    var label = [[CPTextField alloc] initWithFrame:CGRectMakeZero()];    

    [label setStringValue:@"Hello World!"];

    [label setFont:[CPFont boldSystemFontOfSize:24.0]];    

    [label sizeToFit];    

    [label setAutoresizingMask:CPViewMinXMargin | CPViewMaxXMargin];

    [label setFrameOrigin:CGRectMake(100,100)];

    

    [contentView addSubview:label];

    

    [theWindow orderFront:self];

}



@end

If you change the @implementation line and rename everything from CP to NS, this would probably compile as Objective-C. In my experiments, I did run into some obvious missing methods, such as +stringWithFormat:, but a ton of it is already here in the first release.

As a Cocoa/Objective-C programmer, it's easily to forget that you're writing a web app. For example, here's some code I wrote today to make a draggable box (a subclass of CPView):

- (void)mouseDown:(CPEvent)event

{

   mouseDownPoint = [self convertPoint:[event locationInWindow]

                              fromView:nil];

}



- (void)mouseDragged:(CPEvent)event

{

    var newPoint = [event locationInWindow];

    newPoint.x -= mouseDownPoint.x;

    newPoint.y -= mouseDownPoint.y;

    [self setFrameOrigin:newPoint];

}

Other than replacing CPEvent with NSEvent* and var with NSPoint, this is, verbatim, how you'd do it in Cocoa. You don't have to think about any sort of DOM queries or JavaScript of any sort. For Mac and iPhone developers, this is beginning of something very big.

One question that occurred to me immediately is how to incorporate server-side frameworks into the stack. Cappuccino is, after all, a client-side framework, so you'll need need a separate server-side piece (more on that here) in most cases. I haven't had much time to look at this, but the Cappuccino Flickr demo seems to use an asynchronous JSON request to fetch data and display it as it arrives. I'll need to spend more time with it to figure out the details.

One side note here: Cappuccino seems to like to take over the whole browser window. I experimented with adding my own bare CSS-styled DIVs at arbitrary locations in the canvas and I didn't have a lot of success. Not sure if this is by design I was doing something wrong. The documentation does make it clear that Cappuccino is intended to create web-based applications, though, not web pages.

The biggest technical hurdle right now is the size of the framework. The AppKit implementation is 18k lines long, and Foundation is about 5k. When I asked the 280 North guys about this earlier in the year, they seemed to think server-side compression was a reasonable solution. This isn't my area of speciality, though, so I can't really comment on it.

A few quick things I figured out today:

1. The coordinate system appears to be "flipped" by AppKit standards, so the origin is in the upper-left.


2. Even though the APIs may have the same names, they may not behave the same. For example, [view setWantsLayer:YES] isn't enough in Cappuccino. You need to actually instantiate a CALayer yourself and add it to the view.


3. Cappuccino seems to intercept all key events by default, so I found ⌘-N wouldn't open new windows in Safari with a Cappuccino app running in the window


4. The syntax is currently Objective-C 1.x, so none of the new 2.x syntax is available

One last note: there are a set of tools provided to improve the development process, including a pre-interpreter (basically a compile-to-JavaScript tool) and plug-ins for TextMate and SubEthaEdit.

Overall, a very big day for Cocoa and iPhone developers looking to deploy web apps. Major kudos to 280 North.

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.