Rails or Sinatra: the best of two worlds?

From year to year, the blessing condescended to the world of Ruby - an enviable number of frameworks for developing web applications appeared here . However, two of them have recently become clear leaders in this area. Most readers of this site have heard about Ruby on Rails . It was developed by David Heinemeyer Hensson in 2004 and is an MVC framework that helps increase productivity and make developers happy. Sinatra was created by Blake Miserani in 2007 and is a domain-specific language that acts as a wrapper for the layer of lightweight HTTP requests and responses on top of Rack. His minimalist approach is graceful and elegant. Statistics on RubyGems.orgdemonstrates how popular both of these frameworks are: Rails has been downloaded 7 million times, and Sinatra 1.5 million. It was Rails that got me involved in Ruby web development, but over the past few years I have used Sinatra much more often (and here are 7 reasons I love it ). In fact, it turned out that I only needed Sinatra along with several gems to build the application. This made me reflect on whether it is possible to master any project with Sinatra. When is the best time to use Sinatra, and when is Rails the best choice? Trying to find the answer to this question, I asked the famous Ruby developers what they think about this.

Konstantin Haas, which currently supports Sinatra, believes that each of the tools meets the requirements of its own kind of application:

Each of them solves a different series of problems, even despite the fact that they, in fact, are interfaced in this field. While Rails is a framework that focuses on writing model-oriented web applications, Sinatra is a library for handling HTTP on the server side. If you think in terms of HTTP request / response, then Sinatra is the perfect tool. If you need full integration and as many library templates as possible, then Rails will be an excellent choice for you.

David Heinemeyer Hensson also believes that there is a place for each of them, but he believes that choosing between them should be guided by the size of his application:

Sinatra is great for micro-style, but Rails is not. As long as you are minimal, Sinatra is superior to Rails. If you go beyond that, then Rails beats Sinatra.

Indeed, most people would rather agree that Rails is more focused on large projects, while Sinatra is better suited for micro-applications and APIs. David continues by explaining the rule of choice between Rails and Sinatra that he has gained with experience:

If your application has 5-10 endpoints, then it is beneficial to use Sinatra for your own solution. Especially when the controller structure itself can fit on 1-2 pages of code - great if you can run it in one file.

Rick Olson from Github confirms that Sinatra is indeed a great choice for small projects:

Sinatra really works great as an API, as well as on small sites (internal applications, Github Jobs, etc.)

David Heinmeier Hensson explains why Rails is such a good choice when it comes to building large web applications:

Rails allows people to choose between the best technologies (I and the Rails community have dubbed them the “best”) and this is a big part of its success ... I change Rails every week to better fit the ideal, in my opinion, framework.

Konstantin Haas shares his enthusiasm for Rails and his philosophy:

I love Rails. Rails has built our vision for web applications. Rails solves problems for you that Sinatra cannot solve because it can make more assumptions about your application. Everything has already been set up for you, regardless of whether you need it or not, the biggest flaw in the Rails architecture is the acceptance that everything should be solved with one tool.

The opportunities that you receive, which you, in general, do not need in Rails, are definitely accompanied by losses; the latter, however, are compensated by the fact that you gain a large number of opportunities that you really need. In the end, it can justify itself, especially when it comes to a large project. However, not everyone agrees that a large project can only be implemented on Rails. Jeeprey Grozenbach of Peepcode Screencasts believes this is “an outdated look that only holds true for Sinatra in 2008, but certainly not these days.” He drew attention to the great app Gaug.es, built on Sinatra, as an example that proves that it (Sinatra) is more than suitable for creating exploitable large-scale sites.

Despite the above, Konstantin Haas pays attention to a potential problem when using Sinatra to create large applications:

Creating more complex applications on Sinatra (or rather, using Sinatra among other applications) will force the developer to spend much more time thinking about architecture and tools. This is both an advantage and a disadvantage.

Some developers will probably take this as an advantage if they prefer to strictly control what is happening in their application and realize how it all fits together. Joffrey Grozenbach believes this is a sacrifice that justifies itself:

Stability is Sinatra's greatest advantage. You sacrifice your own design decisions for the convenience of several Rails generators. Writing in Sinatra can give developers and the business API stability, as the framework rarely changes. You own your code, and you decide when to change it.

He goes on to explain why Sinatra is an excellent candidate for building applications:

Each of my new applications starts with Sinatra and, as a rule, I come to the conclusion that in addition to Sinatra along with several Rack plugins, I don’t need anything else, a small CouchDB library and Backbone.js as the front-end.

Sow Sheong Chang from Yahoo and author of Cloning Internet Applications with Ruby adheres to a simple development model:

Sinatra does everything I need on a basic platform, and everything else is either already provided with cloud platforms and services (for example, Heroku and its ecosystem of add-ons), or I can implement it using gems. And for the rest, I can write the code myself.

In fact, this idea could be used as a more advanced approach in the application of Sinatra - creating your own special framework that fully meets your needs. Start with Sinatra, and then add gems that realize the features you need to create your own personalized framework. Something similar is implemented in the Padrino project .

David Heinmeier Hensson doesn't see the point:

Dividing everything into small particles and forcing developers to collect everything and everything with their own hands is the antithesis of all that Rails was created for and how he won the game of frameworks. Tens of thousands of man-hours were spent in order for us to achieve this goal. Trying to reproduce this is an empty idea.

Although controlling what is going on inside your application may be a good idea, Konstantin Haase warns that this can take a lot of your time:

The main drawback of Sinatra, which does not solve the problem for you, is that Sinatra does not solve it. You must deal with it yourself. This can lead to the fact that you spend an unreasonably large amount of time trying to solve it.

And if developers have a limited budget, then they may not have this time corny. David Heinmeier Hensson is concerned that using Sinatra while trying to reinvent the wheel is fraught with wasting a huge amount of time wasted:

Most likely, all the work that you have to do, for the sake of reproducing the solutions already provided in Rails, will immediately erase the ease of use of Sinatra. I am sorry for the person who is trying to build Basecamp, GitHub, Shopify or any other large applications in Sinatra alone. Rails is a huge and confusing tool, because it contains solutions to most of the problems that most people who are working on creating an application of this scale face. Trying to recreate all of these solutions manually is anything but simplicity.

Ryan Bates, lead Railcasts, believes that the advantage of using Rails is to save time when the project starts from scratch:

The standard Rails application provides much of what I need and which would require additional installations in Sinatra. And this gives extra speed when developing on Rails.

The same opinion is expressed by Rick Olson, who believes that Rails facilitated the implementation of the GitHub project.

I think that during the first year, Rails was the main tool for the founders of [GitHub]. They were able to take advantage of some of the higher-level features of Rails and iterate quickly.

Chad Fowler (co-founder of RubyConf) cites the Rails mantra of “configuration agreement” as another reason why Rails speeds up the development of large projects:

Rails generators and structures give conventions that Sinatra does not provide.

The problem is that these agreements are sometimes akin to a straitjacket, Rick Olson pays attention to such cases:

Rails is good if its dogmatic conventions are acceptable to you and you adhere to the “golden path”.

Unlike him, Sinatra has no limitations; Satish Talim of Ruby Learning cited a magnificent quote from Aron Quint that explains this:

“Sinatra follows an abstract template: NNNVS (We Don't Need Smelly Templates). NNNSH means that Sinatra is more than flexible and does not determine how you organize your domain or business logic. It does not have an explicit folder structure, there is no default database abstraction, and there are no restrictions on where and how to apply it. ”

Sinatra is most attractive there, which allows you to determine how and how to structure the application from and to. Building on Sinatra can give freedom, because you are not limited in size, structure or work flow. You can build an API, a web application, or pack your code in a gem.

Perhaps it will surprise some that David Heinmeier Hensson also loves the simplicity of Sinatra:

In the past I used Sinatra and I really liked it. He offers a completely different approach, which is great for solving tasks of a much smaller circle, but it solves them really well.

So does Sinatra have such an advantage that he would like to port to Rails?

In fact, there is nothing in Sinatra that makes me want to remake Rails differently.

However, he still admits that Rails has almost completely copied one of Sinatra's coolest features:

We wanted to add single-file mode to Rails, but we refused, why do we need to optimize what Sinatra does so well?

Without a doubt, Rails provides a huge number of opportunities, but often among them there are those that you do not need or they do not work exactly as you need. In Rails 3, an attempt was made to smooth this out as much as possible - by disconnecting some of the features of a different kind, which could result in a lighter and more configurable product, as Chad Fowler points out:

Rails itself is not so “heavy”, especially if you take into account its current ability to reduce in size at its discretion.

Rails 3 brought a lot of configuration options that allow you to tailor the application to your task. Despite the fact that there is an opportunity to get rid of trash, Konstantin Haas warns that leaving everything as is often seems too tempting, which leads to bloating:

In my practice, Rails applications often become a single monolithic application. [Rails abandonment] results in modularity, flexibility, test speed, and scalability. However, you can achieve the same architecture if you carefully design Rails applications, the fact is that doing otherwise (not doing this) is too tempting.

David Heinmeier Hensson does not see this as a problem and believes that regardless of whether you use all the features or not, Rails will do anyway:

By physically deleting a portion of the Rails code that you are not using, you will not get anything useful. Nobody forces you to use all the features. [Many of the features of Rails] are completely optional and can be completely disabled if they bother you so much.

Rails is getting easier, and Sinatra has shown that it can cope with difficult tasks, which means that they are increasingly interfaced. Chad Fowler believes that in fact, both Sinatra and Rails can be used in a wide range of projects:

I think that in fact each of them can be used in any of the opposite cases. I believe that in the end, this is a subjective choice.

In general, everyone will agree that “a suitable tool must be selected for the job”, but pairing them means that the solution often comes down to personal choice. Sinatra can give more control over architecture, but will the extra effort be a worthy waste of your time (or your client, more importantly)? Ryan Bates sums up about personality types and which framework they choose:

I believe that in the end it depends on what you prefer: start light and add as needed, or start with a heavy one, and then remove something if you need to lose weight.

Joffrey Grozenbach suggests that there are two completely different types of developers:

I think that there is a significant difference among Ruby developers: there are those who prefer small size, lightness, speed, explicitness and extensibility; and there are those who prefer frameworks with a full range of features. Sinatra satisfies the requests of the first, and Rails - the second. So I don’t think Sinatra will supersede Rails. It’s just another philosophy that a certain kind of developers likes.

But you may not need to make a choice between them. The author, Dave Kennedy , a member of Ruby Source, points out that Rails and Sinatra generally work pretty well together:

If during the development process 2 frameworks began to complement each other, then this suggests that I am currently working on a multi-tenant application that intensively runs Sinatra inside Rails, a cool thing. Sinatra allowed me to add modularity to my application, before it was so easy to do it.

Many people have realized that thanks to the ability to embed Sinatra in Rails 3+ applications, you can really get the best of what the two worlds offer. Chad Fowler believes that the concept of a choice between one and the other is meaningless in itself:

You don’t have to worry too much about the choice, it is done for you thanks to the ability to embed Sinatra applications in Rails 3 applications.

Joffrey Grozenbach believes that this will give applications a more modular look:

Many people embed Sinatra applications in Rails applications. This imitates the design of the Django framework, where the (main) application consists of many smaller applications, each of which is responsible for a certain part in it (and can often be reused by other applications).

David Heinmeier Hensson also believes that this would be a good way to accomplish tasks:

You can even have a micro-application on Sinatra inside a Rails structure. This is used on Github to solve several problems. Wonderful model.

Rick Olson explains how often this pair is used in tandem on GitHub:

I am very pleased that Rack and Sinatra integrate so closely with [Rails]. Instead of tailoring Rails to your liking for a specific opportunity, you can redirect the request to Sinatra or the Rack endpoint and do exactly what you need.

Everyone will agree that there is a place for each of these two frameworks in the Ruby ecosystem. In essence, they work perfectly together, and to a certain extent complement each other in many ways. It seems that a lot of people think that the two frameworks work best together, and satisfy different needs in general. Different types of developers make their choice to taste if the solution lies in the field of pairing tools. Each of the two does only what it does well, and each is an exceptional example of good practice; so good that these tools have been copied to other languages ​​countless times. John Nunemaker with GitHub summed it up nicely and succinctly:

Each of them has its own place. Rails will be the best option if you just need to deal with the task. For simple things, Sinatra is the best choice, as well as when you want to control everything and keep your own views.

We, as a community, are incredibly lucky that we have such well-developed tools, with such good support, and even in open source. Both Rails and Sinatra do an excellent job of all aspects of the tasks, so it’s safe to say that thanks to them we have the best of both worlds.

What do you think - do you use each of them, or prefer one to the other? Have you considered creating your own framework as an alternative to Rails? Leave a comment below.

The original article can be viewed here .