Yes, You Do Care About Cappuccino

cappuccino (5)

The Cappuccino JavaScript framework has been open source for an entire week. You've glanced at the tutorials, and tried to get 280 Slides to break while feverishly mumbling about the JavaScript Rock Star that desecrated the JQuery website.

In the back of your head, though, you have a question. And its an important question. Actually, damn it, you have more than one question, but I don't know who ate the last slice of cheesecake or why it isn't lunch time yet. I'm here to answer a different quetion: Do you care about Cappuccino?

Why, yes, you do. That isn't to say that you'll ever use Cappuccino. You probably won't, but you do care.

A picture of baby crickets in Yamanomura.

Why You Care

  1. Cappuccino not only encourages, but demands API-centered development. Because the majority of application logic is handled client side, your server only needs to implement a simple API for serving the limited aspects of your application that cannot be handled client side.

    Consider an application that retrieves Flickr images and then allows users to rate them. You can retrieve the Flickr images on the client side, display the images client side, and handle rating client side. The only thing your server needs to do is record the image's rating.

    An API to accomplish that would be remarkably simple (a POST request with an image's id, the rating score, and a value to track the user), and would require far less server power than a traditional web application.

    Also, this API-centric approach supports developing applications on multiple platforms. The API could support a Cappuccino application as well as an iPhone application. Flexibility is a good thing.

  2. Cappuccino promotes code reuse. By making it easier to separate code into multiple files--and making traditional OO inheritance easy to take advantage of--Cappuccino makes it easier to design reusable swathes of code.

    This means it's easy to reuse your components in other projects, but also that it is easier to incorporate others' work into your projects as well. JavaScript's single namespace--and lack of an import mechanism beyond simply loading the file--are lacking in this regard, and Cappuccino is a valuable step forward in this regard.

  3. More than just promoting code reuse, Cappuccino helps manage complexity. Large JavaScript projects can become unwieldly, and you often end up writing custom build scripts to manage that complexity, but Cappuccino will help you reduce complexity.

    Cocoa--the Objective-C framework that Cappuccino was based on--uses a handful of design patterns over and over to ruthlessly manage complexity. Delegation helps reduce the amount of subclassing you need to perform, singletons provide easy access to important instances even without a direct reference, and rich superclasses expose numerous methods for overriding to customize behavior. Together these make living by Once and Only Once much easier than in traditional JavaScript.

    Cappuccino will shine when dealing with large projects that become unwieldly when approached with traditional JavaScript.

  4. The angle that the 280North creators have focused on in Cappuccino is that Cappuccino allows bypassing CSS and HTML cross-browser hell. This is an important asset, but personally I don't consider it to be the most compelling benefit.

    Managing cross-platform issues is frustrating, but as more designers and companies begin to ignore IE6, the process is becoming signifigantly less burdensome. Cappuccino is about the future, and cross-platform issues are part of the receeding past, so focusing on them too heavily seems a diservice to Cappuccino's appeals.

  5. Although many have traditionally felt uncomfortable with JavaScript heavy frameworks (YUI or ExtJS), we're finally reaching a point where impressively quick JavaScript performance is becoming ubiquitous. Even a year ago the issue of slow JavaScript implementations would have been far more threatening, but Firefox, WebKit and Chrome sport excellent JavaScript implementations, and are getting faster every month.

    Internet Explorer's JavaScript implementation still lags a bit in raw speed, but IE8 appears to have some exciting promise in that direction as well (and Windows users have the option of using WebKit or Firefox as well), so it seems safe to declare that JavaScript has become fast enough.

Why You Probably Won't Use It

There are a number of compelling reasons to use Cappuccino, but nonethless I suspect that most developers will never come in contact with it (beyond some experimention in their personal time).

  1. The biggest reason you'll never use Cappuccino is because its too different from what everyone else is using. This is one of the key reasons why Lisps have never caught on in the main stream, and in the end I suspect it will prevent Cappuccino from crossing over from niche to ordinary.

  2. One of the side-affects of modeling Cappuccino after a desktop application toolkit is that functionality is cheap, but presentation is expensive. For its sundry problems, HTML and CSS are masterful at displaying content, and desktop applications generally have a much simpler approach to displaying content.

    I'd go so far as to say that the standard for web design has continued to grow higher and more nuanced over the past decade, but desktop application design has grown in much smaller steps, and presently the expectations for desktop applications are far below that of websites.

    With the high standards for design on the web, cheap functionality can only go so far, most projects require cheap presentation as well.

  3. HTML and CSS are the lingua franca of the web, and many existing services provide their data in them. Because Cappuccino doesn't speak the lingua franca fluently, it is less able to reuse existing code and less able to interoperate with existing services (although it handles JSON quite well, so services which are data--but not formatted data--heavy will interoperate nicely).

Like I told you, you do care about Cappuccino. It's exciting, and it will inspire a number of copycat projects in the coming months and years. Whether or not these projects come into mainstream usage will likely depend on their ability to coexist with the existing HTML/CSS infrastructure.

Along that route exists a balance between ease of functionality and ease of presentation, and potent new avenues of web development.