views:

370

answers:

3

Rails is a very great backend framework keeping everything clean and structured.

I guess that you all have thought about doing the same for the frontend.

  • Sproutcore
  • Cappuccino

Do you use one of thes MVC javascript frameworks for the frontend with Rails?

In case you do, do you feel satisfied with it?

How did you code before and how has it changed?

Isn't Sproutcore more suitable for Rails cause it uses js+css+html which Rails also does. In Cappuccino you don't use either of these.

Share your thoughts and experience cause I'm all green to this field and don't know which one I should use with Rails.

I just know I better have a MVC framework on the frontend to get DRY-structure and best practices.

+1  A: 

I used Rails with Cappuccino and it was really a pain for me, although this opinion has a strong personal bias. First of all i simply don't feel comfortable with objective-j; I didn't have any objective-c previous experience and simply don't like the whole smalltalk-like message sending thing (I'm more of a functional-oriented programmer).

Moreover, if you want to integrate Rails and Cappuccino you are forced to use JSON everywhere, so get ready to refactor almost everything for responding to many formats (you may want to respond to plain HTML too, in case the user's browser does not work with cappuccino - or js in general).

Also, you will be stuck on problems for a quite longer time than usual, because there aren't many Rails + Cappuccino applications and developers around (afaik) and everything is poorly documented on the internet.

Last, but not least, you're going to spend a huge amount of time on building every single piece of the interface in objective-j; as you might expect it's much more like writing a cocoa ui than a web one (this is a downside to me!) and I'm not aware of any software/ide to help you in the process (280atlas has been announced a couple of years ago, but never opened to public use).

In sum, I wouldn't recommend Rails + Cappuccino at this stage, unless you're using it just for fun and/or to learn something new about web programming.

Alberto
280 atlas has an open beta that you can sign up for $20. Additionally, nib2cib has always been a free way to create interfaces for Cappuccino apps (it allows you to use Apple's Interface Builder and then convert those files to ones usable by Cappuccino). Responding specifically to creating things with Cappuccino, its very much the case that in the Cappuccino world the client "rules", and the server is meant to be "dumber", more of a datastore than anything else, thus a lot of what Rails provides probably won't be useful. I believe the same is true of SproutCore, but I am not an expert.
Francisco Ryan Tolmasky I
+1  A: 

I already said this in a comment but you asked me to post it as an answer, so here it is. :)

Rails won't really offer you much if you're building a rich client application. Client-side web development frameworks usually put most of the hard work on the client, and use the server only for storage and possibly some heavy computation (if needed). So I would personally argue that you don't even need Rails--you could go with something much more simple such as Sinatra. Since the client is the "meat" of your application, you will be doing most of your development there, so focus on finding a good client-side library/framework first, then worry about the server-side.

That said, I would try both and see which you like more. Cappuccino is very...different, and a lot of people are put off by it (mostly because of Objective-J I think). In my limited testing it also seemed to load much more slowly than other frameworks that I've used. I recommend you try writing a small application in it, and if you feel like it's not for you, then cross it off your list.

Personally, I would choose SproutCore hands down on this one, because you already know JavaScript (I'm assuming?) and the development style will be way more familiar to you. It will also allow you to use any server-side framework you want.

I don't know if you've looked at it, but there's also ExtJS, which is another very popular framework for creating rich web applications. I've used it and it's great, but the license requires you to either release your software as open source or buy a commercial license--I don't know about your situation, but this was a deal-breaker for me.

In the end I'd recommend you just try them. I can't tell you whether a framework will suit your personal taste.


Disclaimer: I have never seriously used SproutCore or Cappuccino for anything other than testing, so take everything I say with a grain of salt.

musicfreak
@musicfreak: Isn't ExtJS more like jQuery/jQuery UI cause it is giving you nice animations but not a MVC-framework and build-tools?
never_had_a_name
@ajsie: Nope, ExtJS is a full-blown widget-based framework. It isn't MVC but you can make it follow such a pattern. If you are looking for something that's strictly MVC, go with SproutCore.
musicfreak
@musicfreak: is it possible to use extjs together with jquery and sproutcore?
never_had_a_name
@ajsie: It can be set up to use jQuery, yes, but I'm not sure why you'd want to use it together with SproutCore. That's like asking if you can use Rails and Django together. So no, probably not, because they're both pretty exclusive. I'd say just go with SproutCore, it seems better aligned with what you want. The only advantage of ExtJS over it is the vast amount of widgets written for it--but you could always write those yourself in SproutCore with little trouble.
musicfreak
+6  A: 

When looking at MVC frameworks at work, we considered SproutCore and Cappuccino. They both draw an enormous amount of inspiration from Apple's Cocoa framework and Objective C.

We chose to use SproutCore because:

  • It leverages JavaScript in a manner that is aligned with Douglas Crockford's view of JavaScript as described in JavaScript: the Good Parts.
  • Good MVC framework that produces fast applications.
  • Good community backing the project. Charles Jolley, SproutCore's daddy, worked at Apple until recently, and now is working full time on SproutCore. Apple contributes a lot of code to SproutCore's base, and is making good use out of it, as evidenced by the fact that iWork.com was build using SproutCore.
  • SproutCore was designed for very heavy applications that have thousands of elements, using optimized techniques like recycling list items in large lists à la Google Wave or Google Maps.

We didn't choose Cappuccino because:

  • It creates a different language in which you run your application in. This is non-intuitive, makes you think in Objective J, which does provide benefits in the fact that you don't bring nasty JavaScript hacky habits, but neglects the fact that JavaScript is beautiful, extensible, and powerful. (I am in no way 'slamming' Objective J, just providing insight to the fact that you run JavaScript in the browser, not Objective J. If you do run another language in your browser, it can get confusing since you're interpreting an interpreted language using an interpreted language.)
  • However, Objective J and Cappuccino make beautiful applications and leverage Objective C's language architecture, which is a good model to look at in the world of MVC.

(Keep in mind, I don't have a great deal of experience in Cappuccino and Objective J, so if I make broad and naïve claims, tell me!)

You need to look more at what you want as a frontend framework rather than what "works best" with Rails. Both frameworks are good. We chose SproutCore because it fit our needs that we had for our application more, and fit our ideology.

From experience from wading through SproutCore's source, I can say that it's fairly independent of the server implementation that you're using. We use Prosody, a BOSH server written in Lua. You want to use Rails. SproutCore offers this out of the box:

  • DataSources for Rails deploys. FYI- DataStores are SproutCore's low-end model layer for hooking into web services. This is most likely the meeting point between your SproutCore app and your Rails app. SproutCore is not really meant to run in Rails, but you certainly could do it!
  • DataStore for RESTful Rails services. Or any REST API for that matter. It also allows for server-side push, if you have a need for that.

As for your DRY requirement- that's all up to you! You can leverage the framework to make your code independent and DRY, or have tight dependencies and repeat. Either framework is good, it just depends on your needs. Don't be nervous- dive in and get to know the communities and what's going on in each of them! We don't bite... too much.

Tim
+1 objective-J looks horrible. No offense meant.
NullUserException
I don't think it looks horrible. The idea seems foreign to me, but I don't want to taint the discussion with flame wars. I want to remain as objective (no pun intended) as possible about the frameworks to give the best view on why either framework is good for ajsie.
Tim