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?
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.
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?
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…
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
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.
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:
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.
9 thoughts on “Cappuccino: Taking the “Web” Out of Web Development”
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.
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!
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.
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.