Sinatra vs. Rails

Solution 1:

For Sinatra, it's really almost like a wrapper around Rack. So you first need to ask what the point of Rack is. Rack is basically a specification for how a framework should return a result, it can use what's returned with any web server that Rack supports. So it's really a compatibility layer that allows you to choose your framework/server combination at will, without worrying about whether they'll work together. If your framework is Rack-compliant, you should be able to deploy on practically any server via Rack.

Now, the thing is Rack is very low level. Frameworks such as Sinatra give you things like nice routing, helpers, before/after filters, and a lot more. You just need to look to the docs to see what you can get. Rails is much more featureful, and in many ways "magical". That is, you might write a single line in Rails that ends up doing quite a lot, which for some is a good thing, and for some too magical. I personally prefer Sinatra for this reason, at least before getting a decent understanding of Rails internals.

Solution 2:

The gain by Rails is ActionView/ActionPack. But you can just replace by Mongrel/Erb. It's something different.

It's all herlper you have in your view like name_route or error management in your form. It's all resources management and all plugin like InheritedResources. The advantage of Rails.

There are some tool like the Padrino environment to help you to have all of this helper. But It's really speeder after all plugin activate ? I don't think so.

With Rails 3, Rails is a complete Rack application with a lot of RackMiddleware. You can just drop off some middleware to increase your response.

Solution 3:

This question is still relevant until today. And with rails' features are increasing over the time, I want to add a new answer.

There are so many gems right now, so what you can achieve in Rails, most likely you can achieve it too in Sinatra. If we want to compare between Rails and Sinatra (or any other frameworks), we just need to compare the performance and the ease of use.

One of Rails doctrine is convention over configuration. When you create a project in Rails, automatically you get many gems included in your Gemfile. Not only gems, when you look at config directory, you'll see many things included. This doctrine is the reason why the magic can happen in the first place. Once you break the convention, you have to modify -or even create- your configuration.

When we want to have more flexibility but still not reinvent the wheel, we can use framework like Sinatra, where only not so many features is enabled when we first create the project. Even so, I've created mini rails from Sinatra: I just adopting rails' way, with libs/gems that I really need. Because I need to develop my own configuration, the development time was longer than using rails.

If you see this web frameworks benchmark, you'll see that Rails is so slow while other ruby framework, like Sinatra, can be found much higher than Rails.

So, when the best to use Rails?

• You need fast development time. Just follow the convention;
• The future features of your apps are still unknown.

When the best to use Sinatra?

• You don't need fast development time;
• Sinatra can be fast if you only work in mini project;
• You know that you won't add many features in the future.

What do you gain from Rails? Development speed.

What do you gain from Sinatra? Flexibility.