Cappuccino: Taking the “Web” Out of Web Development

The folks at 280slides.com announced their Objective-J framework Cappuccino which “aims to fundamentally change the way applications are written on the web,” and I’ve no doubt it’ll do just that – but does that mean you should use it?

There are as many tools to build web applications as there are developers in this world – Ruby, PHP, Java, JavaScript, jQuery, Prototype, Python, Lisp, SproutCore, Flash, Silverlight, Flex  – and now Cappuccino’s Objective-J. So what makes it different, where does it fit in, is all the hype true, and is Cappuccino right for you? These are all questions I hope this post will help you answer, and to start out, let me explain the title of this post…

Taking the “Web” out of Web Development

A quote from Cappuccino’s site:

With Cappuccino, you don’t need to know HTML. You’ll never write a line of CSS. You don’t ever have interact with DOM. We only ask developers to learn one technology, Objective-J, and one set of APIs.

If you’re anything like me – a million red flags just shot high into the air. If you’re building  a web application, I sincerely hope that you do know HTML and CSS and JavaScript and how to interact with the DOM. But Dion Almaer of Ajaxian gives us a bright side:

they are abstracting developers high up, so you don’t have to deal with [cross browser issues].

Now that doesn’t sound half bad at all! It’ll take more than a promise to convince me that Objective-J isn’t the FrontPage of web languages, but if they can keep that promise, then this could be a game changer indeed.

What Makes It Different?

So how does this work?

Cappuccino was implemented using a new programming language called Objective-J, which is modelled after Objective-C and built entirely on top of JavaScript. Programs written in Objective-J are interpreted in the client, so no compilation or plugins are required.

To clarify, there are two new things here: Objective-J and Cappuccino. Objective-J is a new language with it’s lexer, parser, and interpreter written entirely in traditional JavaScript. Cappuccino is a essentially Cocoa ported to Objective-J. Both of these together let you write new applications entirely in Objective-J on the Cappuccino framework.

There are a few things that come out of this, the first of which is that JavaScript does a lot of extra work. All of your Objective-J code will be tokenized, parsed, and interpreted entirely in JavaScript. Hopefully, with new JavaScript engines (and browsers like Chrome that actually compile JavaScript), speed will become less of an issue – but in the short term this is very much a concern.

Second, developers only need to learn 1 programming language, and Cocoa developers already have a head start with this new framework! This almost almost makes me wish I’d been building Mac apps for the past few years instead of web apps – but not quite :) In fact, Dion’s interview with 280 North a few months ago had some interesting tidbits about just that:

The guys talk a little about the toolchain an why they did this, and even how it enables future cool things such as generating a native Mac application from the same code.

That’s a future I want to live in.

Is the Hype True?

And now the fun part: 280 North make some bold statements with Cappuccino. Let’s take a look at the highlights:

Cappuccino is not designed for building web sites, or making existing sites more “dynamic”… Projects like Prototype and jQuery are excellent at those tasks, but they are forced by their nature to make compromises which render them ineffective at application development…

and

jQuery, Prototype, and others do a great job of making static web pages a little more interactive, but they weren’t designed for building full fledged applications.

Lies. Filthy lies.

Ben Sargent provides a fantastic counter-example to this exaggeration in the form of a re-implementation of Cappuccino’s sample Flickr app in only 45 lines of jQuery. Cappuccino’s code was hundreds of lines of Objective-J for the same (if not poorer) result. (Notice zooming photos in the jQuery version runs much smoother than in Cappuccino).

To be fair, the Flickr sample app is a very small application. So does jQuery fall apart with larger applications? Of course not! Especially since you’re already using a Model-View-Controller, right? :)

Comparing Cappuccino to jQuery is beginning to look like comparing Java to C. Each can be used with great effectiveness – and each for its own reasons: Java for abstraction and portability, and C for speed. This may be the beginning of similar arguments for and against Cappuccino and jQuery: Cappuccino for new language features, and jQuery for speed.

Which brings us to the next statement:

the real beauty of Objective-J is that it already works in every major browser and it is completely extendable at our descretion

This is mostly true, but not entirely. In their announcement post, they provide their motivation for building Objective-J vs waiting on the next-gen JavaScript:

Most JavaScript programmers today could list a number of features and bug fixes they’d like in JavaScript, such as classical inheritance, better media support, and access to the webcam.

And while Objective-J does solve some problems (classical inheritance) it does not and cannot solve others (better media support and access to the webcam). A new language that’s built in and runs in JavaScript cannot and will never provide more than what JavaScript provides.

Features like media and webcam support, offline access, persistent data storage, etc, will always be dependent on JavaScript’s foundation. Cappuccino can change how you accomplish things in JavaScript with new syntax and semantics, but can not change what you accomplish in JavaScript.

Performance

As I mentioned above, Ben’s Flickr app suggests that Cappuccino’s performance leaves a bit to be desired. To compare, load each app (link to jQuery and Cappuccino versions) and note how quickly the photos scale when using the slider – the jQuery version wins hands down.

In Cappuccino’s defense, the incredible speed improvements made by browsers will hopefully make this a non issue relatively soon.

This shouldn’t be too surprising. After all, a lot of work has to be done to transform all of the Objective-J code into JavaScript, and that clearly adds extra weight to your application.

Alternatives

Lightweight alternatives include jQuery, Prototype, and YUI, among others. Each of these can be used to build incredibly rich applications – especially if you follow the correct methodology ;)

Sproutcore is another option, although it’s certainly my least favorite of all of them, and for the same reasons as Cappuccino provides:

While SproutCore set out with similar goals to Cappuccino, it takes a distincly different approach. It still relies on HTML, CSS, JavaScript, Prototype, and an entirely new and unique set of APIs. It also requires special development software and a cumbersome compilation step. We think this is the wrong approach.

And last (and least preferred), you can roll your own foundation for your web app, as Buck and I did with Jotlet before there even were frameworks. (Well, we did use X, but Mike himself won’t call it a framework :)).

Is It the Best Option?

If you’re a Cocoa developer who wants to make apps on the web, this is a no brainer – Objective-J is a fantastic choice. There is a dark side though: at the cost of a graceful learning curve you’ll likely have to sacrifice some performance and optimization.

If you’re well established in jQuery (or similar library) and building with good methodolgy, then Objective-J may mean slower development cycles, more lines of code, and poorer performance. No one (certainly not me) will chastise you for staying with the proven ridiculously fast jQuery.

One thing is for certain, Cappuccino will change web development. This opens a huge door for Cocoa developers in particular to begin writing solid web apps in a comfortable developer environment. And another thing is certain, Cappuccino is not the only framework for building web applications – so don’t believe their lies. ;)