Thursday, November 26, 2009

Introduction to Cappuccino

For many years I have been waiting for real web application software toolsets to arrive. Widespread abuse of HTML, CSS and scripting has created a slew of messy web applications written in technologies that were never designed to be used for such a purpose. They are well suited to web content, but not to building rich applications.

In the 90's, I was building rich client applications for the desktop that were far more usable and responsive than many modern web applications, but the reach and simplicity of deployment for the web model was too great and (almost) everyone jumped on the bandwagon.

Well, the guys over at 280north have been working hard on Cappuccino - a web development framework with a difference. This one provides a rich, object-oriented way of developing applications for the web that run in the browser without the need for plug-ins.

It has its own language called Objective-J the syntax of which is similar to Objective-C. It adds the use of classes instead of relying on Javascripts pure prototype based approach to OO. Unlike Objective-C, it only runs in garbage collected mode, and loses the reference counting model. Other changes includes the dropping of the pointer syntax and moving source code to one .j file instead of requiring a separate header. Classes in Objective-J have a 'CP' prefix instead of 'NS' used by Objective-C. See this tutorial for a quick overview. Since the language is dynamically typed, unit testing and the discipline of keeping code clean are a must to retain one's sanity - but these are good things regardless IMHO.

Programs written in Objective-J are preprocessed into pure Javascript which can be executed in the browser or on the desktop - more on this in a later post.

If you're interested, go over to the cappuccino web site and look into it more detail.

Although there are some incomplete features at this time, it's a lot of fun to work with - I have never been this excited about writing applications for the web before.

1 comment:

Paul said...

Hi Andrew,

"What no DOM ?" :) I've never liked the idea of web programming precisely because of the DOM. The DOM is just one big global data structure which the browser engine interprets. So programming the DOM (whether in HTML or Javascript) always felt like the antithesis to OO to me.

In his 1997 keynote speech at OOPSLA Alan Kay makes the same point. He says something like "never make physicists do programming" or something like that. A reference to the inventor of the web :)

He as got a point. Data and behaviour should travel together and data should be encapsulated. The current web explicitly separates the two. The data is embedded in HTML and the behaviour is hard-coded in the browser. This leads to inflexibility and all those browser versioning and incompatibility issues. Much better send down the behaviour and the data together at the same time. No versioning or incompatibility problems then. Javascript writing to a canvas instead of a DOM allows this.

The unanswered question for me is how do these Cappuccino guys get access to the "canvas" within the browser? I thought that a user accessible canvas was an HTML 5.0 feature?

Good luck. If you get an answer to this one please let us know.