undefined | Better HN

0 pointsbascule13y ago0 comments

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...

0 comments

malandrew13y ago

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.

PetrolMan13y ago

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.

malandrew13y ago

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.

basculeOP13y ago

It's pretty slow, among other things

basculeOP13y ago

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

cageface13y ago

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.

j / k navigate · click thread line to collapse

0 pointsbascule13y ago0 comments

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...

0 comments

malandrew13y ago

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.

PetrolMan13y ago

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.

malandrew13y ago

Problems:

(1) Slow

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

basculeOP13y ago

It's pretty slow, among other things

basculeOP13y ago

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

cageface13y ago

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.

j / k navigate · click thread line to collapse