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.
I wish they had advertised it as an alternative rather than a replacement framework.
The idea is good, the app perhaps isn’t.
Great article. Dugg it.
Another fun exercise is firing up a Cappuccino app and exploring the generated DOM with a tool such as FireBug. Aside from the slowness introduced by Objective-J, the sheer volume of nested divs and inline styles used to abstract away the browser creates overhead as well.
V8, Tracemonkey, etc have introduced great improvements in JavaScript execution speed, but it appears DOM manipulation is still a bottleneck. (see http://ejohn.org/blog/javascript-performance-rundown/)
Man, we can see you’re a windows fanboy that never has seen how productive a cocoa developer can be and how much he can accomplish.
If you’re a real OO programmer you can get Obj-J in a matter of hours, and be proficient in a framework like Cappuccino after a little while. After that point the sky is the limit in terms of desktop class apps in the cloud.
I profoundly doubt that anyone can achieve the high level of productivity with any framework as we can with an Cocoa inspired environment.
All hands down to 280N guys in bringing that to the web!
Untouchable –
Nicely done in getting the author’s credentials completely wrong. He’s a Mac user and was well on his way to a CS doctorate specializing in OO studies before pursuing his own business endeavors.
Anyway, Adam has provided the pros and cons of each method, so I can’t possibly fathom how you’re able to argue anything he’s said.
Cappuccino abstracts the developer too far away from HTML / CSS / JS for my tastes, but that doesn’t mean someone else can’t be productive with it. Just expect quite a bit of frustration if you can’t get the enormous markup it provides to work exactly how you want it to.
@untouchable
The perks, as you noted, are the same takeaways I mentioned in the conclusion of the post – except you ignored the trade-offs.
While you may be adept at Cocoa, that’s certainly not true of all web developers – the learning curve, development time, and ‘wordiness’ of Objective-J all need to be taken into consideration.
And even will all the perks of Objective-J’s abstraction, the performance tradeoff is still very real. For the jQuery savvy and performance conscious – jQuery is still a solid choice for web app development.
In terms of performance are you only concerned with the initial loading of the application? Sure the jQuery version loads a lot quicker, but I did not see a performance issue once the Cappuccino app was loaded.
Also notice when you resize the images and then change photo lists in the jQuery app the slider retains is position, but the size of the photos in the new photo list do not reflect the slider value. Try the same thing in the Cappuccino version.
Also there is a lot that can and will be done to speed Cappuccino up. Like spriting images to get less file loads. You can compile it if you wish.
The performance comparison is off-base. Cappuccino is not simply zooming the photo in and out:
“- The Cappuccino example works just like iPhoto, when you drag the slider, it does not just resize the images by increasing relative height and width like your jQuery script does, it zooms the images in keeping them centered (both vertically and horizontally) in their own “cell” and each row of cells in its column, until the bounds of the image (and cell) are bigger than the column’s width, therefore moving the image to a new column so it fits. I think that’s a more complex calculation and so takes more time to be processed by the JS engine”
quote from comment by Fernando Lins on another blog
I should highlight that the JQuery re-implementation DOESN’T re-implement properly the behavior of the cappuccino app.
First, I was like “uh, it doesn’t feel as neat at the cappuccino app”, then I noticed how resizing and pictures disposition was handled with JQuery (look closely).
Cappuccino behave like iPhoto, which might consume more resources and explain some speed difference.