GWT vs. Cappuccino [closed]

Question

I'm in the planning stage of a web application and I'm trying to choose between GWT and Cappuccino. I have an idea of which one I think is better, but my partner is sold on the other choice. I was hoping to get some feedback on pros and cons for each from people who have used one or the other or both. Thanks in advance for any insight you might have.

Allister

Without any detailed requirements for the project you want to do, this sort of question can't be answered. And even then you'd mostly get opinions from either side of the fence - everyone has their favourites. I'd recommend trying both frameworks to get the "feel" of them and pick the one that suits your style best. – Kibosh

I agree that the answers to this question are just going to be opinion or personal preferences, but I'd still like to know what people like and dislike about both frameworks. Thanks! – Allister

Answer 1

Toolkit v/s Framework

GWT is a toolkit. Its strength lies in the tools it provides to create an application. It doesn't provide a framework though. Developers usually build a small framework over GWT to suit their needs. There has been a lot of emphasis on MVP pattern to build apps, but it isn't the only way to use GWT.

Cappuccino is a Framework. It has a prescribed way of building applications. Additionally, it provides libraries to perform high level tasks like animation, drag-and-drop undo/redo etc. GWT doesn't provide any libraries for such tasks, though third party libraries are available.

This means that Cappuccino apps tend to be richer than corresponding GWT apps.

Offline Compilation v/s Runtime Translation

GWT believes in making decisions at compile time. Browser detection, I18N, image inlining, generation of sprites, uibinder template evaluation are all performed at compile time. Deferred Binding allows developers to leverage this concept in their own applications.

EDIT

Cappuccino, by default, does not need compilation. The browser downloads objective-j files, and then the framework translates/interprets them directly at runtime. However, it is possible to compile using jake. You can choose from several minifiers/compressors, including google's closure compiler.

As a result of this architectural decision, GWT apps tend to be faster at runtime than equivalent Cappuccino apps. However, because of the compile time cost, development tends to be slower than Cappuccino. GWT development plugin somewhat eases this pain, but the cost doesn't go away entirely.

Since GWT is a closed-world compiler, it can remove unused code, inline method calls, intern strings and optimize code in ways Cappuccino cannot. If Cappuccino were to introduce a compilation step, it could perform the same optimizations; but to the best of my knowledge there is no way to do the translation at compile time.

With the optional compilation step, this point becomes moot. However, cappuccino applications that do not perform such a compilation will have a poor performance as compared to a GWT app.

Type Safety

GWT is java - and is therefore type safe. Objective J is javascript, and therefore dynamically typed. This has its own advantages and disadvantages, and since it is a religious discussion, I will refrain from making a judgement.

Debugging

GWT provides a browser plugin that helps developers directly debug Java code. In development mode, developers get to see java stack traces. At runtime, however, the generated JS code is obfuscated, and very difficult to debug (though there is a way to tell GWT 'don't obfuscate my code').

Using the super-dev-mode it is now possible to debug the Java code directly from the web-browser.

Cappuccino doesn't have a development mode, which means you have to use existing tools like firebug to debug. Errors are reported by the browser, and to debug code you have to use JS debuggers.

Unit Testing

With GWT, you can write pure java unit test cases that do not require a browser to run. This has obvious advantages - speed and ability to reuse existing infrastructure are some of them. When you do need a browser to test, you can choose from GWTTestCase or HTMLUnit. Its also possible to test using Selenium.

Cappuccino apps can be tested using OJTest. Unfortunately, I couldn't find much documentation on the subject, so can't comment much. Of course, you can always use Selenium to test your webapp.

Interoperability with Javascript

GWT provides a way to talk to existing JS libraries - its called Javascript Native Interface. It is mature and works well, but isn't really intuitive. Objective J is javascript, so you don't have to do anything special to inter-operate with Javascript.

Vision

I can't back this argument, but GWT tends to focus on creating high-performance web applications without caring much about look and feel. They never compromise on performance. Cappuccino on the other hand tends to focus on higher level features and frameworks, and compromise on run time performance.

As a result, Cappuccino apps look richer, but take a while to load. GWT apps load and respond faster, but look boring. You can get around both the problems, I am sure - but that's the way it is out-of-the-box.

Community Support and Backing

GWT is backed by Google. Their commitment to GWT is pretty strong. Newer applications (Wave, Adwords, Orkut) from Google are built on GWT. Google IO has had several sessions on GWT. The user forum is pretty active and responsive, and the toolkit itself is actively developed and maintained by Google and the open source community. The Cappuccino user group isn't as active, and has far fewer members.

Islamize

Sri, that is a ton of good information! Thank you for the comparison! – Allister

Great summary. However, "Offline Compilation v/s Runtime Translation" is incorrect. Cappuccino provides an offline compiler. While developing your application you may choose to not use it to save yourself the compile step, and Cappuccino will then transparently compile your code in the runtime. Before deployment you would normally compile offline before minimizing and running optimizers such as the dead code removal tool 'flatten'. – Directly

There is an experimental type safety flag in Cappuccino although it's a runtime check rather than a compile time one. It's not very useful at this time. – Directly

@Alexander - Thanks for the pointer. Updated my answer to mention jake. – Islamize

There seems to be debug support in Cappucino at the moment. So you can print Objective-J stacktraces etc. – Nibelung

Answer 2

I am much more experienced with Cappuccino than GWT, but from the looks of it GWT looks blazingly fast and fairly robust. It is after all backed by a fairly large player in the internet field. The demonstration at Google IO was impressive. Although this might change, GWT apps totally leave Cappuccino in the dust when it comes to load times and deployment size today.

That said, I went with Cappuccino for two reasons: first, while GWT is a classical 'good enough' engineering solution, Cappuccino is squarely targeted at 'only the best is good enough' crowd. I believe that with Cappuccino you can achieve a standard rarely seen on the web before. Not only in pretty pixels, but in raw functionality and power where everything just works at a 'desktop quality' level. Drag and drop, undo stack, fluid scrolling and resizing, split panes, and on and on. GWT is catching up, as seen in Google Wave, but it has a long way to go and Google has not traditionally cared much about polish. This is visible, for instance, in Gmail which is still not only drab looking but clunky in the user interaction after this many years.

The second reason I went with Cappuccino is that Java drives me insane with its inflexible, ridiculously verbose and unreadable style. But that might only be me.

Directly

you went with Objective-J because of Java's ridiculously verbose and unreadable style?? – Adulterer

Objective-J is verbose in the sense that it has long method names, Java is verbose in the sense that you have to write more lines of code. To me that makes a big difference. – Directly

i notice more Objective-J's unreadable style. thats what matters most to me. – Adulterer

I'll agree with Java's inflexibility and verbosity, and I appreciate what Cappuccino is doing, but I think Objective-J is far more unreadable than Java... But that's my opinion. – Rampart

If you're experienced with Objective-C, you find find Objective-J unreadable at all. I find it perfectly readable but thats just me – Makepeace

@Brock: I guess you mean "If you're experienced with Objective-C, you don't find Objective-J unreadable at all." – Thwack

@Thwack yeah that's what I mean. Brain must have stopped working mid sentence – Makepeace

Answer 3

You might be interested in my new GWT UI Framework, CappuccinoGWT

Vaporous