By Holger Jahn, 12 July 2009
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
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.
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
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
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.
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
"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
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...
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
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
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.
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.
Let us have another look at software development from orbit.
Generally, there is web development, which traditionally comprises of
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
namely the Objective-J language.
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
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
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.
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.
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
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.
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.
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
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
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
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.
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.
Here are some links I came across in the last few weeks:
Please use the contact page to send me a message
online, or send email to
Hope my Objective-J demo code can help you getting started with Objective-J.
Thanks for reading,