[bascule]

None of this is true. Single-page apps need great JSON APIs. Rails is awesome at making great JSON APIs. With Ember Data on the front end and ActiveModel::Serializers on the backend, you can completely free yourself from writing JSON serialization code.

For websockets-based applications, check out Cramp. And note that as both Rails and Cramp are Rack-based, you can combine them.

"Go or Node or Erlang"

One of these things is not like the others...

[malandrew]

Rails works just fine for REST, but you've forgotten the other side of this and that is the part of the framework that handles the javascript assets, i.e. Sprockets.

The difference between handling the single page app in Rails and node.js is night and day. Sprockets is a nightmare to deal with.

[PetrolMan]

Please explain.

I've actually had a pretty good time dealing with Sprockets. There are the occasional deployment issues but the benefits tend to more than make up for any frustrations.

[malandrew]

Problems:

(1) Slow

(2) Sprockets' C-style require directives because the people working with ruby don't want to get their hands dirty with crawling the javascript AST and parsing out commonjs or even Harmony-ES module system requires.

(3) Incompatibilities between various JS-focused gems because of sprockets issues. Getting Require.js to work took a long time and then it took a lot longer to get the require.js gem to work with jasmine.js, and even then it ended up being a jerryrigged approach.

In general, sprockets is a mess with respect to Javascript handling versus what you can do in node.js.

[bascule]

It's pretty slow, among other things

[bascule]

Nobody's forcing you to use Sprockets. You can use e.g. rake-pipeline instead

[cageface]

Knocking up a REST API in any decent web framework is easy. Rails makes it slightly easier.

It's good that things like cramp exist but async is really something you want to design into your language and framework from day one and not bolt on via libraries later.