GWT, Cappuccino, Sproutcore: AJAX-Framework-Shootout

How do you decide on a framework? Compare the features? This won’t help you too much, most of the time: You’re most likely not to need about 40% of the functionality in your project. And what’s even worse: You won’t know in advance, which of the features you really need in your project and which are missing from the framework you finally came to choose.

Assuming that mere mortals are still not able to take a peek into the future, what you’re gonna do? Most often, we end up with a gut-feeling: Decisions are made based upon the look&feel of the documentation, the expertise of the designer who has built the frontend for the examples, or the time of day you have evaluated the one or the other framework. Being engineers, we are very clever in disguising these gut-feelings with massive amounts of pro-contra-lists, excessive flame-wars that rant about why this tool is crap and this other tool is the best invention since sliced bread. If we’re honest, more often than not, these decisions boil down to this: I like it vs. I like it not.

GWT vs. Cappuccino vs. Sproutcore

Which brings us down to my problem at hand: For quite a while I’ve used several different approaches to developing AJAX-based applications. As we all know, AJAX is an ugly beast: The combination of server-side, client-side and layout-code usually creates a mess with your codebase. It looks like most people are starting with good intentions and end up with some sort of hackish approach. Prototype/Scriptaculous along with rjs is a natural choice for rails: But the mixture of client-side and server-side code soon gets out of hand, so we abandoned that route and tried to become more unobtrusive with jquery. jquery lacks some of the object-oriented features of javascript, but maybe OO and JavaScript isn’t such a good idea together?! Made a short excursion into ext.js, but what if your widget is not inside their (impressive!) set of widgets? I shied away from mootools or dojo: Maybe I was not ready for that great big widget in the sky that they promise you to reach after sufficient meditation about their object-model…

So I pretty much ended up with only jquery, some css and some json/restful-Interfaces. Which does the trick quite ok. Feels ok, looks ok, performs ok. Most of the time. That is, until things get bigger.

Let’s break the problem of growing-big down. These are the three areas of “big” I have encountered:

  • codebase
  • layout-code
  • event-routing/handling

Organizing your codebase

The mantra of ajax is: the page is the application. And the application gets big very soon. Events flying around, states have to be tracked, namespaces get polluted. Loading and un-loading of code, managing dependencies – all these become issues. In the end, it boils down to the question: Is JavaScript sufficient for doing this for any application of some serious size?

There are mixed answers to this. The jquery-folks say yes, sproutcore says almost, GWT[5] and Cappuccino both have different approaches to their NO.

Fact is: Javascript without any means to organize your fast growing codebase will get ugly.

Laying out your widgets

Not much of a problem you say: That’s what we have css for. And that’s the way you normally start out with good intentions: Write your code, then style your widgets. And then the next widget. And another, that almost the same. But not really. So you throw in another css. And end up with some centralized and some decentralized stuff. A grid-system like Blueprint or 960 goes a long a way, but it won’t help you to much with laying out buttons, button-bars, menues, windows, controls. You can throw in things like jquery-ui for theming and at least a little bit of common denominator – but face it: Laying out complex interfaces in a fast moving environment (always a designer at hand, when you style your admin-interfaces?!?) can get messy. Even when you start with good intentions, you may end up with a flea-circus of css and different approaches to markup.

From a developers standpoint, you just want some containers to throw your stuff into: Laying out buttons, bars, panels should happen automagically. Most sophisticated frameworks use some sort of layout-manager for that. Of course, you can try to remake/remodel this with your own set of mark-up conventions and css: This will give you the highest degree of flexibility. But that’s nothing for the faint of heart.

Event-Handling/Keeping track of state

As the number of knobs and sliders on a single page increases, so does the complexity of your event-handling-code. You have to keep track of what is shown in the interface, what is disabled, what shall be hidden. Throw in some eye-candy for sliding or fading or highlighting stuff, and you very soon get a problem with exponential complexity. Something should be there to prevent yourself from shooting you into the foot with event-handlers tied directly to div-events, the incurring scope-problems. Remember the days of Visual Basic or Oracle Forms? When logic was coded inside the handler-code of widgets? You’re very likely to see that in your average AJAX-application. Which is fine, if you only have two buttons ever on your page…

Given all that, I’m sure I need more than just jquery and css. Still not sure, what to choose.


You cannot really do something wrong when you choose gwt. Java as a language is a little outdated and I’m not too sure, if the overly verbose syntax is even worse when you use it to layout your interface with it. There is an impressive tech-talk by the chief-developer of Wave – he stressed that it was not the language, that drew the wave-team to gwt… The technical background is impressive and of course – this baby certainly scales, both in performance and in sheer size of the codebase (check out GWT.runAsync). Given the fact, that most other projects are backed only by very tiny companies, the fact that you can’t get a bigger company than google to back up the development of the toolkit certainly is a factor…

  • codebase: Very much at home with java, having a true OO-language will certainly help you do that.
  • layout-code: I’m not overly impressed with the gwt-layout-managers. Very verbose, but this may get better with UI-Binder Does look a little bit too technical out of the box. Then again, the interfaces are working and are responsive, which is certainly an important part of the look&feel of an application.
  • event-routing/-handling: Not much there out-of-the-box, but there is lots of stuff going on. GWTx ports some missing APIs to gwt, including java.beans.PropertyChange* and associated listeners. You can work your way from there upward, it’s all java :)


After evaluating several frameworks, I’m not impressed anymore by the shere number of widgets they have. In the end, the widget you need is almost never present. That said, sproutcore only has a very limited set of widgets: But if you judge it by their widgets alone, you miss the point. The core of the frameworks is an MVC-approach to client-side development. It feels – at least superficially – very similar to rails: You get generators for controllers, models, views. Still using javascript, only surrounded by several enhancements, the frameworks is situated somewhere between lighweight-frameworks liek jquery and heavyweights like gwt and cappuccino. It’s a question of personal taste, but the fact, that you don’t have to jump through JSNI-hoops to call another javascript-library may help to ease the migration..

  • codebase: Namespacing built in, the packaging in the end makes sure, that the results are not bloated
  • layout-code: ok, but not amazing. You get some abstractions to lay out your widgets, but you’re likely to fall back to css every once in a while
  • event-routing/-handling: The MVC-model of sproutcore is a very tight costume. Which is good. Applications will most likely look quite uniformly, things have a place where they go and you get around fast. Very familiar model if you already know other MVC-frameworks.


I looked into this one quite a while ago and looked away at once. Another language (objective-j) interpreted via javascript in the client – are you kidding me? I came back to cappuccin after they announced Atlas, a WYSIWYG-tool for laying out your application. Impressive

  • codebase: Objective-J is closely modelled after Objective-C. You can have worse parents. You basically get all the language-constructs you came to know and love, plus some goodies surrounding your execution-environment (like proper dealing with DOM-references). The language is definitely not hard: It’s basically just javascript with some clarifications in terms of dealing with OO.
  • layout-code: This is where cappuccino really shines: The “Automatic Layout”-features are really impressive. It seems to be the very first framework that really has an idea on how to deal with fluid layouts. Even without Atlas (which appears to be stuck in beta for quite a while now…), you can hardly get more flexible than this. Huge Plus: Cappuccino looks great out-of-the-box. Given the huge amount of design-challenged developers out there(and in here), you can hardly stress this point enough.
  • event-routing/handling: Basically, everything is there to write proper code. That you can do it, does not necessarily mean that you will do it – cappucino does not enforce a certain style of structuring your application. You can check out this Tutorial on implementing Undo and Redo if you want some proper examples.


To sum it up: GWT is technically great, Sproutcore has the cleanest and tightest development model, and Cappuccino just looks freakin’ awesome.

Which brings me back to my introduction: Lots of data about the three frameworks, still undecided. I’m pretty sure, that you can go on and on evaluating frameworks – in the end, all (ok: most) frameworks are turing-complete: You will be able to get your job done, no matter what framework you choose. It comes down to a question of personal taste.

In most organisations the non-technical aspects will overrule all these considerations: GWT has by far the most traction, which leads to more documentation, blog-entries, people digging up errors and fixing them, more testing, more books, more conference-speaks and in the end: more jobs. So, the choice is obvious. If only cappuccino didn’t look so freakin’ good…

  • Matt

    Although I don’t doubt the number of GWT resources outnumber those of Cappuccino, Cocoa resources are frequently helpful in answering questions that are otherwise unanswered in current Cappuccino documentation.

  • Johnny

    Good writeup. If you’d like to see what we have been able to do with GWT, I invite you to take a look at TeamPostgreSQL (

    It is a fairly complex AJAX application, both in terms of UI and functionality, written and maintained by essentially a single developer. This is a great testament to the ease of creating and managing a big AJAX application with GWT.

    In our entire code base there is not a single line of JavaScript – it is all regular Java classes. There has, however, been liberal amounts of CSS tweaking to get the GUI just right.

  • Ray

    I’d be curious to know how you felt qooxdoo did relative to your selected criteria.

    Like Sproutcore, it is a pure JavaScript approach.

  • stf

    @Matt: Yes, sure you’re right – cappuccino gets a huge amount of backup from Cocoa, both in terms of documentation and in tools (eg. nib2cib). But I guess there are many people coming to cappuccino from a web/non-cocoa-world: For them, it’s hard to sort out what’s relevant for cappucino. And you’re literally swamped with examples, books, forum-entries, blogs about gwt. google is pushing gwt so loud and hard, that it’s very difficult to compete against them: Especially when they are not only big, but they are also good…

    @Johnny: thx! Interesting tool, I’m always thinking about switching from mysql to postgress, maybe this tool helps me make the jump :) I have made similar experiences: Using gwt you can get away with almost no javascript at all (overlay-types for json being the noticeable exception, but I’l leave that for another post…) – but styling still leaves me a bit confused: Could you elaborate a little on the strategies you used for styling? I always used the standard-panels, now everything looks google’ish (cappuccino looks much more polished right out of the box…): And I found almost no articles on arriving at really good-looking layouts by mixing css&panels. I only recently stumbled upon

    DOM.setElementAttribute(panel.getElement(), "id", "footer");
    which helped a lot, but I would really like to hear some stories about styling real-world projects…

  • stf

    @Ray It looks like there is another AJAX-Framework popping up every day. I find it very hard to keep track of their existence, let alone being able to know them good enough to make at least an informed guess about their value for a given project. I know qooxdoo only by their documentation, never felt the urge to play with it for an extended period of time. Not becaus it is not good (I bet it is) – just because I think there is only very limited space in this area. Which one of them survives will not be decided on their technical qualities alone: Marketing goes a long way (getting people to write books about it, appearing on conferences, being showcased in high-volume-sites, pretty pictures and documentation on your website). That being said, I don’t think frameworks like qooxdoo will get a significant marketshare outside their inner circle. Shame, yes, but I’m afraid, that there are many excellent projects out there, that don’t get their share of followers.

    And beyond this verbose preamble: I like it, I think it addresses lots of the things that are currently lacking in “pure” JavaScript-frameworks (like project-structure, imports, dependency-management) – but they are not doing it in a significantly different way than say Dojo – and to me they just seem too small, too much niche to be considered seriously for a project…

  • Johnny

    @stf: We started out with the completed graphical HTML prototype, then gradually replaced the dummy widgets with live GWT ones. For styling these we simply took the complete GWT stylesheet (with all the default Google-ish settings) and tweaked each new widget as we went until it looked like the prototype.

    This approach gets you 80% of the way. The rest includes DOM fiddling as you mentioned and sometimes gets rather nasty when you want pixel perfect styling. Luckily GWT is extremely hackable, so we have yet to come across a challenge that could not be fixed by (mostly trivial) hacks and workarounds.

  • abhi

    Have a look at CSS injector in gwt incubator for styling.

  • thomas sabo

    a h:commandLink Tag and close it with s:link?

  • Vivien de Saint pern

    Dude, I don’t want to be rude but how can you say that Java is outdated when objective-c has been created 10 years before Java…? Objective-C is outdated. Java is much more interesting in lots of respects…!

    And how many millions of people have Java skills vs Objective-C skills?

    • Anonymous

      with the huge popularity of iPads and iPhones i’ll say “alot”  TIOBE ranks Objective-C at #6 and Java #1 in terms of popularity of programming languages. 

  • Anonymous

    280North was bought out by Motorola and then nothing happened it went quite. Now motorola is being bought out by Google. Cappucino GWT clash waiting to happen. You can guess who will get the axe. Cappucino is opensource but won’t be supported by Google. Cappucino is also very slow moving compared to both Sproutcore and GWT.

    Apple’s iCloud is build on Sproutcore. Lets wait and see how good it is. It will testify for Sproutcore.