September 12, 2008.
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.
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.
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.
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.
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).
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.
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.
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.