Hacker News Reader

Comment by masomenos | Hacker News Reader

Even if your UI is all in JS, Rails still saves a ton of work as an API server compared to Sinatra.

Any examples? My experience with Rails and Sinatra on a daily basis for the last two years has proven the exact opposite.

https://github.com/rails-api/rails-api#why-use-rails-for-jso...

That's definitely a decent list, but the problem for me is that you are also forced to have EVERYTHING ELSE! It's all nicely required in the for you in your app and there aren't straightforward ways to remove 90% of the stuff you don't want.

I work with rails every day for the last 6+ years and it was a revelation when I started. Now I still think it works decently well for large web-apps, but it's just grown way to big over the years. Basecamp is awesome and a great proving ground, but I'd wager the vast majority of apps written in RoR come no where close to needing most of what's included today.

I'm curious as to why having that stuff available is a bad thing?

memory overhead (both for the machine and human), modifying core classes unnecessarily, complexity of third party software, setting defaults to on that aren't applicable to 90% of apps (see turbolinks which breaks the way the web and browsers work).

I'll admit to being on a hard-core minimalist, simplicity, explicit coding kick recently, so I'm already biased against behemoth frameworks. Rails is wonderful if you need that level of complexity/features. I don't think most apps do and we're "forcing" everyone to write basecamp when that is overengineering for most apps.

I'd add security to that list. Rails' most notorious vulnerability was the result of an on-by-default feature that 90% of developers never even needed. I'm not suggesting that Rails is inherently insecure or that Sinatra/Rack cannot be exploited, but less unnecessary code leaves less potential for vulnerabilities; this is especially true in the Ruby world where many developers are eager to `gem install` anything with a few stars on github.

meh, I'm not convinced. I've written some very complex APIs and sinatra-contrib covers most ancillary needs. I'm not saying Rails is always the wrong choice for an API, but most of the bullet points listed in this guide are covered or unnecessary. If you have tons of sprawling back-end logic that is exposed through your API, Rails makes sense, but time and time again I've seen first-hand how much more quickly Sinatra gets us up and going and it's always less work for new developers to grok the application flow.

Reply on news.ycombinator.com