Alex MacCaw commented that “Rails is just an API”:
The answer is simple. Rails isn’t going away anytime soon. It makes excellent CRUD REST APIs, and the asset pipeline ensures serving up JavaScript Web Apps is pretty straightforward. Rails has a good ORM, excellent libraries and lacks the callback hell that Node sometimes suffers from. There’s nothing wrong with relegating Rails to the API layer.
For legacy apps, this is true. My company started using Rails back in 2007 and it was enlightening because it introduced seemingly forgotten concepts in web development like MVC, REST, and included some really nice helpers that made it easy to render stuff client-side. It was a breath of fresh air.
Today things have changed. More view logic is handled client side by Javascript and the server is nothing more than a fancy JSON pump that handles authorization, shared global state, and a bunch of other resource integrations. What sucks about Rails is that its a horribly inefficient JSON pump in terms of memory usage; its just not the right tool for the job.
What Rails does have is an awesome tool-chain that includes Sprockets, HAML, SaSS, CoffeeScript, and some really handy helpers. The good news is that these tool-chains are trivially easy to integrate (if its not already integrated) into other fantastic Ruby frameworks like Renee, Sinatra, and Middleman.
My company is taking an approach where we build out our view layouts and logic using Middleman, CoffeeScript, Backbone.js, HAML, Compass, and SaSS. We compile the app into an HTML, Javascript, and CSS file, then rsync them to an nginx server for our “deployments”. It talks to our Rails app via CORS XHTTP requests. Its beautifully simple, but more importantly, its insanely fast and highly cacheable, which lends itself really well to distribution via a CDN.
Its not too far fetched to think that down the road we’ll get rid of Rails for the API server and go with something faster and more “slim”.