On Cappuccino & Objective-J

By Holger Jahn, 12 July 2009

What are you talking about?

Objective-J is a programming language built on top of Javascript, the native programming language of all web browsers. Cappuccino is a framework (set of libraries) that provides high-level functionality for desktop-like user interface (UI) development.

The entire UI is being developed in Objective-J. The .j files are downloaded from the web server, and then the Objective-J code is translated to Javascript on the fly by the web browser. When the browser finally executes this Javascript code, the page content is being rendered. There is no need for HTML or CSS any more.

During development there is no compilation step required. You simply make changes to your UI code, then reload it in your browser by hitting the short cut key for a page refresh.

Go to the Cappuccino website to get a glimpse at the project, then read on here to learn something more about Cappuccino from a new user's perspective.

Why would I spend any time on that?

If you need web applications that offer the same user experience as a desktop app would, then Cappuccino is for you. If you truly believe that the classic web development "components" - the usual HTML/CSS/Javascript horror shop - simply stinks, then you are going to be delighted about Cappuccino, too.

On the other hand, if all you need is just a few HTML pages being sent back and forth between your web server and your users, then you might look elsewhere.

How does this Cappuccino UI look like?

Lucky you, I just finished a "showcase" project in Cappuccino to get my hands dirty. I took a very UI-centric web application of mine, and ported it to Cappuccino. Well, not the entire functionality, but at least I now have a feeling for the language, and a better understanding of the library concepts and its UI programming capabilities.

The "old school" link below is merely a screen shot of the current application developed using the traditional HTML/CSS/JS mix. It contains a lot of Javascript code to enable/disable input fields depending on checkbox states. It also hides/shows entire DIVs with modem feature sets, depending on the modem device selection. In other words, it is a provisioning and configuration software deployed at one of the biggest ISPs here in New Zealand.

"Old school" gets the job done, but that is already the only good thing I can say about it. If I compare the relatively simple functional requirements with the amount and messiness of the resulting code, it becomes clear to me that this kind of programming is not something I wish to do for the rest of my life.

"New school" has been developed in about one week. That means, I now have been exposed to Objective-J and Cappuccino for about two weeks in total.

Perhaps you are going to shed a tear or two while looking at the Cappuccino UI One source code, but please bear in mind that this kind of UI programming is as new to me as it probably is to you. Even if you are really upset about my code, I can assure you that there is absolutely no need to whack me on the head with your keyboard.

Here are instructions on how to run the demo application. Be aware that the Objective-J demo code has not been optimised, although, its deployment to this server has. The demo code has been precompiled with "press --flatten" (see Cappuccino Tools package), and tranparent text file compression has been activated on the Loomsday web server. Now the demo should be pretty fast loading, but if you think performance still leaves to be desired please let me know.

Anyway, I am going to share more of my thoughts on web UI development below. In the meantime, enjoy the ride...

Old school. Smells like old socks. Fresh Cup of Cappuccino.

Application Snapshot

Cappuccino Demo

What's wrong with the HTML/CSS/JS approach?

Everything. The dummies who came up with the idea of using HTML for their company websites back in the 90's all had a screw loose. Instead of trying to get the browser manufactures to integrate some decent graphics capabilities into the browsers, such as support for Postscript, they started to pixel around with HTML and embedded images. Then, after some days on rather exotic-but-expensive drugs, they spiced the whole thing up, and added Javascript and CSS to the stew. In restaurant context, it would be called "food poisoning".

Let's back up for a second, and think about the basics.

HTML is good for text with embedded links to other documents and pictures. That is what is was meant for. Great for documentation and newspapers, but a far cry away from anything like a programming language. It has nothing to do with programming, at all. It is content, not content-generating. Yet, HTML is still being used as the main means for developing websites, even complex ones. How come?

Technically, HTML pages are sent back and forth between the web server and the browser. This procedure is simple, but it takes ages. It also requires the whole page to be reloaded to update one piece of the browser window. Introducing AJAX (background server requests issued by the browser) to achieve the same without reloading the page looks great at first, but often takes a web project to "Libraria". That is the place where they use exactly one highly specific Javascript library for each new dynamic feature they wish to add to the website.

In other words, to the aforementioned mush-heads it looked like a simple solution for creating their company marketing websites ("HTML? Hey, great! No programming required!"... yeah, right). That is what must have happened back then, and by now most of us have arranged ourselves with the circumstances.

Why is this ancient web stuff still alive?

Software technology, once introduced, can hardly be eradicated after it has "infected" a certain critical number of computer systems and administrators (something I like to call "code base inertia"). The effort of getting rid of all the bad stuff seems to be too hard by then. Just think of the many years it took to bury Sendmail on Unix, and that was not even rocket science, but just a software to send pieces of plain-text messages around. Worse, even if there is a consensus among the affected users to replace some piece of nasty software, the usual big companies will soon after stack the standardisation boards with their representatives to secure themselves a big piece of the upcoming new market.

Thank goodness, there are market niches. If people have good ideas, they can make a difference. Also, not every problem can be simply solved by throwing a random amount of money at it. Otherwise, the big players would have quelled every independent software firm by now.

Is there a better way of developing web UIs?

Let us have another look at software development from orbit.

Generally, there is web development, which traditionally comprises of HTML + CSS + Javascript code to be run in the browser, plus some server-side code (Perl/Ruby/Python, you name it). The server-side code generates HTML pages and provides the data source to the browser. This approach is bearable only as long as the project's UI is simple (or as long as your project has enough financial resources to employ enough soon-to-be grumpy web developers). This classic approach has been, however, conceptually always been ugly as hell. Web projects usually grow more complex quickly, especially when there are requests to add more "dynamic fire power" to the UI. This is when things get really messy, unmaintainable, and unfunny.

"Real" web applications, i.e. applications that run in a browser, but behave like a desktop application, are almost impossible to develop using these standard development methodologies.

There are only two ways to bail out of this trap. One way is browser plugin-based development (e.g. Adobe AIR/Flex, Microsoft Silverlight). Another one is facilitating common browser support for Javascript (Cappuccino, SproutCore, Google Web Toolkit).

GWT applications are developed in Java, then compiled to Javascript. SproutCore is entirely written in Javascript. Cappuccino, however, takes another leap and provides an even higher abstraction level over Javascript, namely the Objective-J language.

So, why not use Javascript directly? Why another language, like Objective-J? I needed to take a deep look into the Cappuccino architecture, and its history, to understand the reason:

When we are looking at desktop-like web applications, then again there are only two possible options to tackle the required development tools. Start from scratch, or use proven development tools and methodologies. Starting from scratch would be pretty stupid. It would mean to reinvent a very complicated wheel, and it would also mean to replicate all the mistakes that have been made in desktop UI development long ago. After all, the web application should behave the same way inside a browser window, as it would on the desktop (UI is UI is UI). At least, for the greatest part.

Cappuccino (the framework itself) is, by and large, "Cocoa on the Web". The Cocoa framework is the UI foundation on Apple Mac OS X. Cocoa provides all the functionality to develop good looking user interfaces on Apple computers and iPhones. Cocoa is proven technology. It is actively used on OS X... - and that means, there is an existing developer base. Now, these developers develop in the Objective-C language in order to make use of the Cocoa framework. To them the transition from Objective-C to Objective-J is painless, thanks to the common language syntax. In other words, inventing Objective-J allowed for hiding al the nasty Javascript cross-browser compatibility issues, and provides a programming environment many people are familiar with. Plus, it adds all the goodies from Objective-C to the game, lastly providing ONE language and framework for everything, rather than having to deal with a plethora of languages and concepts (HTML, CSS, DOM, various Javascript libraries, the box model, etc).

That is what makes Cappuccino so appealing. Instead of trying to reinvent the wheel, or to come up with another obscure screen layout/rendering methodology, they ported a proven framework from the desktop to the web. If this is all about user interfaces that behave the same way inside a browser than they do on the desktop, then Cappuccino can do the UI job for the web, simply because Cocoa has already laid a solid, comprehensive UI development foundation on the desktop.

What about browser plugins, Java, and pure Javascript?

I have seen great "eye candy" implemented in Flex. Nonetheless, I am generally not a fan of plugin-based UI development. Firstly, most of these technologies are proprietary. When ever Adobe or Microsoft (don't get me started) decide to change direction of their plugin/engine development, all users have to follow. No matter what. The same goes for bugs. If they are simply unwilling to fix their bloody software, it will be your blood pressure that hits the ceiling.

Using open-source software, such as Cappuccino, we can always fork or amend if we don't like part of it. Even better, of course, it is to provide patches and to add new features ourselves. Furthermore, open discussions - rather than commercial market motivations - usually ensure that the majority of users of a decent OSS project is benefiting from ongoing development.

What about Google's GWT, and their Java-to-Javascript compilation idea, you might ask? Well, for starters, I even don't like Java on the desktop. So, why would I use it for web development? Personal dislike aside, the language has no particular characteristics for web development, which makes this whole thing look like the early attempts of dynamically generating Javascript code from server-side Perl scripts. Of course, if I had sympathies for Java, then I might be interested in developing both server and client code in Java, as well. Then, again, despite being a great Perl fan myself, I generally think generating client code from server code is a waste of time. Hypothetically, even if there were such things as browser-integrated Perl or Java interpreters, the biggest part of the UI development job still would be dealing with the browser's UI functionality. And to that end, the question of "what programming language" would be pretty pointless anyway.

Finally, what about SproutCore's pure Javascript approach? Frankly, I don't have an opinion. I have read good things about this project, but I did not look into it. From what I have read so far, SproutCore seems to be the only interesting, non-plugin-based alternative to Cappuccino at this time.

How hard is it to learn Objective-J & Cappuccino?

If you have previous programming experience on Mac OS X you will be having a warm, welcoming feeling, I guess. The language syntax looks identical to Objective-C, as far as I can tell, except for the fact that the "subclassed" core language is Javascript, not C.

The Cappuccino framework classes look like their Cocoa counterparts. The classes just have a "CP" prefix, instead of "NS" ("CPView" vs "NSView").

For developers without Objective-C/Cocoa background - like me - things are harder. I found the learning curve to be steep. Not so much due to unusual complexity, or weirdness, of the language and the framework, but rather because of the sheer amount of framework methods to be learned.

After having written a few thousand lines of code in Objective-J, I really do like the language. To me, Objective-J is elegant, transparent, and makes it easy to keep things in order and maintainable. Despite the fact that I have been exposed to Javascript for many years, as long as I have a choice, from now on I will always prefer Objective-J.

The Cappuccino framework, however, needs more time to understand. Its graphics capabilities are enormous, and so is the list of available methods, classes, selectors, nuts, and bolts. Francisco Tolmasky (Cappuccino lead developer) recommended Aaron Hillegass' book "Cocoa Programming for Mac OS X" to me, and I am looking forward to read it when it finally arrives at the office.

I now have about two weeks of Cappuccino under my belt, and that exposure was sufficient enough to write my first ~1500 line demo application, Cappuccino UI One, from scratch (well, to be frank, I ransacked all demo codes I could lay hands on).

I still have not played with all the whistles and bells the Cappuccino framework offers, but by now I feel confident enough to develop the user interfaces on new client projects in Objective-J.

What else is in the Cappuccino pipe?

A thing called "Atlas", which will be released soon, hopefully. Atlas is a UI builder written in Objective-J that runs inside a browser window. Intuitively use your mouse to create user interfaces, instead of typing all the programming code by hand.

By the way, if you have access to an Apple computer, you can use Interface Builder today already. IB is a graphical software tool to create UIs on Mac OS X, which can then be converted to Cappuccino/Objective-J by the "nib2cib" tool (part of the Cappuccino Tools). You may think of it as "pre-manufactured" UI development: Create the UI on Mac OS X, convert it to Cappuccino, and finish the application logic on your web development server.

Where on Earth can I find more information?

Here are some links I came across in the last few weeks:

How can I contact the author of this page?

Please use the contact page to send me a message online, or send email to .

Have fun!

Hope my Objective-J demo code can help you getting started with Objective-J.

Thanks for reading,