SproutCore vs. Cappuccino

Aside from the language differences Javascript vs. Objective-J what benefits does Cappuccino provide over SproutCore and vice-versa in your experiences?

In terms of a long-term forecast, is SproutCore more "supported" than Cappuccino because it is backed by Apple?

I am trying to choose between the two. I am both familiar with JavaScript and Objective-C.

Solution 1:

This is an interesting question, and one that has been popping up fairly frequently on various messages groups, twitter, and even IRC. There's a couple of ways to evaluate SproutCore versus Cappuccino, but, perhaps, some of the immediate caparisons that people look at are the following:

1) Their respective feature set
2) Ease of use
3) Community support and documentation

Let's look at the first point -- there respective feature set. By "feature set" there's a couple of ways to look at it. From the number of UI widgets they have; the foundational support to connect things together and communicate with some kind of back-end; the framework's general architectural approach, although not necessarily a "feature", but still important; and, yes, even the language you can use.

Regarding language, I think it's important that you do not dismiss what is being used (JS versus Obj-J). Why? Because of adoption and where you are coming from. SproutCore came from the perspective that JavaScript is indeed the language of the web, so it's what you use to program against the framework. Where JavaScript lacks in language OO completeness (proper object-object inheritance, etc) it makes up for in the framework (e.g. MyApp.Foo = SC.Object.extend({...})). Cappuccino comes in from a different angle. They use Obj-J as a primary language enhancement to JS in order to inject language features that JS is missing; this instead of injecting those language features directly into the framework (Cappuccino) itself. Of course, as the folks over at Cappuccino have noted before, you can still use JS to program against Cappuccino proper, but, then, you miss out on what Obj-J provides. Note to the Cappuccino community: Please correct me if I'm wrong :-). Finally, if you're someone who is already familiar with Obj-C then Obj-J may be more your cup of tea. Hey, even Sony is apparently now jumping on the whole Obj-C bandwagon to develop against their mobile platform :-P.

Looking at the architecture of the two frameworks, they both looked at Apple's Cocoa framework for guidance/inspiration in one form or another. Cappuccino took Cocoa fully to heart and basically ported Cocoas API. Again, if you're coming from developing apps in Apple using Cocoa then you're probably going to feel right at home. SproutCore on the other hand took inspiration from Cocoa where it felt right. As for pure architecture, they both follow MVC, they both make use of Cocoa-style bindings, they both have a data store mechanism, and they both have their own respective style of rendering and composing UI widgets/views.

The rendering of views is, to me, a particular area of importance. Both frameworks have some level abstraction in order to remove you from directly dealing with CSS and HTML even though at the end of the day they have to render to what the web browser ultimately understands.

On the Cappuccino side, they completely abstract away CSS and HTML from you. Instead, you use the framework's various rendering primitives to "draw" your views. Because of this level of abstraction, Cappuccino can make use of the best rendering approach available instead of coupling you, to some degree, with CSS and HTML.

As for SproutCore, you are rendering closer to the "metal" so to speak. When doing a pure rendering of a view, you make use of a rendering context object that provides a certain degree of abstraction, but, ultimately, you are directly injecting HTML and adding class names to apply CSS. Even after your view has been rendered and you want to manipulate certain parts of the view based on an event, you can directly access to the DOM elements and manipulate their properties. Depending on where you are coming from this may seem good or bad. Good for those who are used to working with CSS and HTML and like the more direct control over how the views are rendered and styled. Bad if you want to generically render a view in order to make use of the best render approach based on what the browser allows (HTML/CSS, SVG, HTML5 canvas, etc). But, note, there are future plans to make SproutCore have a more abstract rendering approach but still allow you to directly work with HTML and CSS if you so choose. So you'll eventually get the best of both worlds.

Now, as for the stock UI widgets/views the two frameworks come with -- they both have a lot right out of the box in order to get you going. Buttons, labels, lists, segmented views, radio buttons, scrollers, etc -- they're all there. Therefore, it's safe to say you're fine in both camps.

Going all the way back, let's now discuss the ease of use. To me, ease of use is based on you own personal experience working with JavaScript, HTML, Obj-C, Cocoa, other MVC frameworks, documentation, and community support. If you've never worked with Cocoa, or never built a decktop- or iPad-like app, then it's fair to say you're going to have a bit of a learning curve no matter what framework you choose. That being said, what you don't know and want to learn can be acquired through each framework's respective community and docs. Both have active communities in one for or another, so you won't be left out in the cold if you get stuck somewhere. As for docs, Cappuccino, admittedly, has the upper hand. The docs for SproutCore are lacking, but the code base is at least fully commented. The SproutCore community is fully aware of the docs needing to be updated, and it is currently something that is being dealt with, so keep checking.

Finally, you mentioned the long-term forecast for the two frameworks. It's public knowledge that Motorola bought the Cappuccino framework, so you certainly have a big company backing its growth and longevity, or at least it seems like that way for now. As for Apple and SproutCore, I personally can't speak for them, but Apple does not own the framework. There are many companies and various individuals that all use and contribute back to the framework in some way. That might give some people and companies pause or discomfort for those who are looking at SproutCore due to the more organic nature of the framework's development, but I don't see that as a problem. My feeling is that both frameworks will be around for a long time, especially now that more are looking at developing next generation desktop and iPad apps using open source frameworks. And, hey, competition between the frameworks is good -- keeps everyone on their respective toes :-).

Hope this information helps you out with your decision!

Cheers,

Mike

Solution 2:

I'd like to touch on the comments made about objective-j Michael.

You're not going to lose anything if you drop down to JavaScript instead of objective-j. In all actuality the distinction is kind of difficult to make, especially in cases where we have toll-free bridged classes (more on that in a bit).

Objective-j is really just a thin wrapper over js. It provides classical inheritance something that has traditionally been implemented as a language feature, which sproutcore implements as a framework feature, it also provides code importing, accessor generation, static scoping, and support for messaging nil.

Objective-j instance variables are accessible via the traditional dot syntax if you want... I like to think of it like this: once you start writing a method, you're mostly writing JavaScript. That is, loops, variables, functions, closures, etc are all just javascript. You're not losing anything by dropping down, that's exactly how the language is designed.

We take it a step further by "toll-free bridging" some of our classes CPDate, CPArray, CPException, CPString and perhaps more that I can't recall. Toll free bridging just means a CPArray IS a native js array, and a native js array is a CPArray, so you can use methods and functions of both world interchangeably.

So for example would could do:

var foo = [];
[foo addObject:"bar"];
foo.push("2nd push");
var value = foo[0];
var value2 = [foo objectAtIndex:0];

alert(value === value2); //true

As you can see I'm using objective-j syntax and js syntax together... You can imagine the power if this.

The final thing I want to put out ther, just to make sure there is no confusion: objective-j gets parsed in the browser. It doesn't need to be compiled before hand (although we provide compilation tools for when you're ready to deploy your app).

I think some people are needlessly put off by objective-j as if it's some monstrous beast that will take time to learn, and while objective-j adds a lot of great features to js, to actually learn them won't really take you the better part of a day if you're already familiar with object oriented programming, and obviously if you're coming from cocoa you'll be able to jump right in.