Each person has a preference on where they thought something should be. Days were spent arguing over the location of mundane things. Each team member had a different understanding of REST, so without the rails routing we argued about what we thought an ideal API would look like. We argued about which view engine we should introduce. We argued about how to handle our JS/CS. We argued some more about routes and how to make them more discoverable. On and on. Not intentional, but something new would come up and we would need to figure out where to put it.

This, more than anything, hammered home for me the strength of rails. Rails is great at getting you up and running, but it's greatest strength is that it's idioms are well documented. That gives developers a strong impression of how things are going to be and where things go. This saves you so much time by not having to argue and reach consensus on every little thing.

However, Rails is just too fng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing imperative programming which sucks. Programmers want to actually know and control what they are doing.

I once dealt with a legacy Rails app that had really complex Models. ("Fat models, thin controllers") Of course the original designers hadn't thought about every corner case, and of course not thought about what AR is actually able to deal with seriously. The app was just slow and not maintainable.

But to say something good about Rails: creating standard web pages with it is a peace of cake. All standard tasks are automatized.

Great when building but it sucks when debugging and maintaining.

There was a recent post on HN regarding /usr/local that seemed to suggest some programmers do not understand what a partition is nor should they need to become acquainted with such unimportant details. I hope I'm wrong in that interpretation. Because if true, that is just sad.

It provides generators, basic helpers (link_to etc.) and, most importantly, it gives project a sane structure. Oh, and it does not tie you to any fixed set of components. Using Padrino and Sequel is a bliss!

But your app remains a sinatra app, small and elegant. Also, the documentation is excellent.

That's just the bad workman blaming his tools for the faults of the toolbags he works with.

Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go?

You don't need all the ceremony and structure of Sinatra to write a JSON API, you just don't.

One of the main benefits of using frameworks like Sinatra and Rails is that you often don't need to re-write and re-implement all the same boilerplate code (like parsing JSON post bodies) over and over again.

And the difference with rails and sinatra vs most other open source projects is the size and activity community, and as a result, the overall stability of those projects.

So, in theory, do you need all that "ceremony and structure"? No, but I can't think of a good reason why you'd go implement all that stuff yourself.

https://gist.github.com/3719513

Did I miss something?

Rack is "env variable goes in, array of [code, headers, body] comes out, here are some handy utils for handling grunt work". That's it. That's Rack. You can do whatever you please with it in the middle. That's all that a middleware is, and Rails itself is basically just a collection of Rack middlewares (procs) with some support libraries stapled on. That's a gross simplification, but at the end of the day, that's basically the heart and soul of the framework.

My point is that there are multiple levels of abstraction. Of course you don't have to re-write and re-implement boilerplate when you use Sinatra over Rack, just like you don't have to re-write and re-implement when you use Rails over Sinatra. "Rails bad, Sinatra good" is just silly, because it all boils down to what kind of tradeoff you're willing to make between what's done in framework versus what's done in your application.

I agree with the parent, that I have no use for the complexity of Rails and Sinatra is convenient. Other people are free to choose as they wish, and Rails might be the more appropriate library is some cases regardless of preference (like in the sibling post about teams).

But there's a ton of utility on the spectrum from Rack to Rails and it's perfectly reasonable to choose a midpoint, and perfectly reasonable to choose it because you think Rails is too much but Rack is not enough.

When you look at Rails as a collection of middlewares (which you can choose!) and support libraries (require 'rails/all' may not be needed!), instead of looking it as a monolithic black box that can't be configured to fit your needs, it's suddenly a lot less "heavy" and a lot more "wow, okay, buffet-style app composition sort of rocks". People seem to have this idea that Rails is on the far end of the "magical and heavy" spectrum, when it can be just about anywhere along the spectrum that you want it to be, based on your selection of middlewares and libraries to use.

I have production apps that range from small one-off Rack apps (my dynamic asset server, for example) to Sinatra to full-blown Rails, and they're all very similar beasts. Rails isn't some mystical black box, and Rack isn't just some RFC somewhere, and I think it does a grave disservice to both to marginalize them.

There's a continuum of "more manual work" <----> "more framework", and there's no one right answer, even for something like a JSON API.

The choice between Sinatra and Rails can reasonably be debated, but there's little reason to write a JSON API in Rack unless you need control of protocol details that neither abstraction provides. Sinatra/Rails are frameworks, Rack is middleware.

Why wouldn't you just do a 50-line Rails app instead, and slot in any other Rails niceties when you feel like you need them?

Problem solved.