views:

585

answers:

4

Hi folks, i was wondering if any of you had insights about which one is better, and what factors should be taken into consideration when using one of these

+1  A: 

I'm writing a somewhat non-trivial web app using Rails (3) and Cramp together at the moment. I don't have any experience with Node.js, and I only just started using Cramp as it is, but it looks promising. And in my opinion, being able to use Ruby is a big plus! (I started with Tornado (Python) and couldn't bear the language. Sorry Python fans!)

The downside is that I have found very, very little third-party material on Cramp. I guess that's not surprising considering how new it is, but you're more or less on your own. If you need your hand held, you probably shouldn't use Cramp.

Twisol
+2  A: 

I played around with cramp and rails 3 a while back. Was trying to build a view with dynamic updates using WebSockets to channel data back and forth between clients and the server. It worked perfectly with Chrome, but Safari 5 and FF implement a more recent version of the websocket protocol and Cramp does not so I couldn't get it to work there.

I agree that using Ruby for the whole stack is nice, but I feat that Cramp right now is lagging slightly behind the curve in some aspects.

I decided to bite the bullet and use node.js (and the SocketIO package) for my stuff.

Good luck!

dvdplm
+1  A: 

Check out different repos of cramp. WebSockets are moving target, and living on the edge isn't that easy. github.com/maccman/cramp fork works with rescent websockets implementation, while original cramp is not up to date and under refactoring. Also take a look at eventmachine-websockets. Anyway - be prepeared to use thin+eventmachine on serverside. With cramp you should run thin in production mode , cramp is not that good yet.

Andriy Tyurnikov
+1  A: 

I can speak more from the other (Node.js) side. I just wrote a gem that integrates with Rails 3 that uses a Node.js back-end for listening to Redis PUBSUB messages and updates the Rails front-end accordingly.

Socket.IO + Node is not hard to integrate with a Rails app (especially if working with jQuery), but depending on your targeted browser base (like IE7), it can be tricky to get working right in all cases, namely because of some weird cases when using Flash Socket as a fallback (usually where WebSockets don't work).

That said, I highly recommend Node.js + Socket.IO. It is super light-weight with a lot of options and flexibility to extend to do almost anything you could want. In my opinion, Rails is a fantastic web framework for building bigger apps that need a computationally heavy front-end. I would not choose to use it for small, event driven applications simply because it uses so much memory for the framework alone. I love Ruby/Rails, but when it comes to needing something for quick and clean event processing/message handling, Node has my vote.

If you need more concrete examples, my project Kthxbye (a Resque-esque clone) communicates with Redis which in turn is listened to by Node.JS which in turn can update a web application.

Plugin: http://github.com/plukevdh/kthxbye (see: http://github.com/plukevdh/kthxbye/blob/master/lib/generators/kthxbye/templates/kthxbye.js)

Node Backend: http://github.com/plukevdh/kthxbye-node (see: http://github.com/plukevdh/kthxbye-node/blob/master/poll.js)

(Apologies for the complete lack of documentation on the node project. Coming soon...)

Lukas