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
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:
Organizing your codebase
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
- 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.
- 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…