Rails or Sinatra: the best of both worlds?

From year to year, the world of Ruby has been blessed with an enviable number of web application development frameworks . However, two of them have recently become clear leaders in this field. 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 Mizerani in 2007, is a domain-specific language, which acts as a wrapper for the level of lightweight HTTP requests and responses over Rack. His minimalistic approach is elegant and elegant. Statistics on RubyGems.org clearly shows how popular both of these frameworks are: Rails was 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 need Sinatra along with several gems to build the application. It made me think about whether it is possible to master any project with Sinatra. When is the best time to use Sinatra, and when is the best choice for Rails? Trying to find the answer to this question, I asked famous Ruby developers what they thought about this.

Konstantin Haas , who is currently engaged in supporting Sinatra, believes that each of the tools meets the requirements of the applications of its own type:

Each of them solves a different series of problems, even though they are, in fact, mating 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 requests / responses, then Sinatra will be 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 Hönsson 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 minimalist, 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, explaining the rule of choice between Rails and Sinatra, which he acquired with experience:

If your application has 5-10 end points, then it is advantageous to use Sinatra for a handwritten solution. Especially when the structure of the controllers themselves can fit on 1-2 pages of code, it’s great if it can be run with a single file.

Rick Olson with Github confirms that Sinatra is truly an excellent choice for small projects:

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

David Heinemeyer Hönsson explains why Rails becomes such a good choice when it comes to building large web applications:

Rails allows people to choose between the best technologies (the “best” I dubbed them and the Rails community) and this is where most of its success lies ... I change Rails every week to better fit the ideal, in my view, framework.

Konstantin Haas shares his enthusiasm for Rails and its philosophy:

I love Rails. Rails created our understanding of web applications. Rails solves problems for you that Sinatra cannot solve because it can make more assumptions about your application. Everything is already set up for you, regardless of whether you need it or not, the biggest flaw in the Rails architecture is the assumption that everything must be solved with a single tool.

The resulting features, which you don’t need in Rails, are definitely accompanied by losses, which, however, are offset by the fact that you gain a large number of features that you really need. In the end, it can justify itself, especially when it comes to a large project. However, not everyone will agree that a large project can only be implemented on Rails. Joffrey Grozenbach of Peepcode Screencasts believes that this is “an outdated look that is valid only for Sinatra in 2008, but definitely not in our day.” He drew attention to the magnificent application Gaug.es , built on Sinatra, as an example, which proves that he (Sinatra) is more than suitable for creating large-scale operated sites.

Notwithstanding the foregoing, Konstantin Haas draws 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 treat this as an advantage if they prefer to strictly control what is happening in their application and realize how it all fits together. Geoffrey Grozenbach believes that this is a victim that justifies itself:

Stability is Sinatra's greatest advantage. You donate your own design solutions for the convenience of several Rails generators. Writing on Sinatra can give developers and 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 apps starts with Sinatra and, usually, I come to the conclusion that apart from Sinatra along with several Rack plugins, I don’t need anything else, a small CouchDB library and Backbone.js as a front end.

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

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

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

David Heinemeyer Hönsson does not see the point:

Dividing everything into small particles and forcing developers to hand-collect everything and everyone is the antithesis of everything for which Rails was created and how it won the framework game. Tens of thousands of man-hours were spent in order for us to achieve this goal. Attempting to reproduce is a futile idea.

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

The main disadvantage of Sinatra, which does not solve the problem for you, is that Sinatra does not solve it. You must deal with it yourself. This may result in you spending an unnecessarily large amount of time trying to solve it.

And if developers have a limited budget, then they may not have this time banal. David Heinemeyer Hönsson is concerned that the use of Sinatra when trying to reinvent the wheel is fraught with wasted time:

Most likely, all the work that you have to do to reproduce the solutions already provided in Rails will immediately eliminate the ease of use of Sinatra. I’m sorry for the man who alone is trying to build Basecamp, GitHub, Shopify, or any other major application in Sinatra. Rails is a huge and confusing tool, because it contains solutions to most of the problems that most people face when they work to create an application of this magnitude. An attempt to recreate all these solutions manually - anything, but not simplicity.

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

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

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

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

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 provide conventions that Sinatra does not provide.

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

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

In contrast, Sinatra has no limitations, Rubish Learning 's Satish Talim quoted Aron Quint with a magnificent quote that explains:

“Sinatra follows an abstract pattern: NNNVSh (We Do Not Need Smelly Patterns). NNVS means that Sinatra is more than flexible and does not predetermine how you will organize a domain or business logic. It has no explicitly defined folder structure, no default database abstraction, and no restrictions on where and how to use it. ”

Sinatra is most attractive there, which allows you to determine how and how to structure an 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, web application or pack your code in the gem.
')
Perhaps some will be surprised by the fact that David Heinemeyer Hensson also adores the simplicity of Sinatra:

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

So does Sinatra have the advantage that he would like to transfer to Rails?

In fact, in Sinatra there is nothing like that because of what I would want to redo Rails in a different way.

However, he does recognize that one of the coolest features of Sinatra is almost completely copied in Rails:

We wanted to add a single-file mode to Rails, but we didn’t, why do we need to optimize what Sinatra does well?

Without a doubt, Rails provides a huge number of possibilities, but often there are some of them that you don’t need or don’t work exactly as you need. In Rails 3, an attempt was made to smooth it out as much as possible - by decoupling some of the capabilities of a different kind, which could result in a lighter and more configurable product, which Chad Fowler draws attention to:

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

Rails 3 brought a lot of configuration options to fine-tune the application for the task you are performing. Despite the fact that there is an opportunity to get rid of the trash, Konstantin Haas warns that it is often too tempting to leave everything as it is, which leads to bloating:

In my practice, Rails applications often become a single monolithic application. [Failure from Rails] results in modularity, flexibility, speed on tests and scalability. However, you can achieve the same architecture if you carefully construct Rails applications, the fact is that it is too tempting to do otherwise (not to do this).

David Heinemeyer Hönsson doesn’t see a problem in this and believes that regardless of whether you are using all the features or not, Rails will do in any case:

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

Rails becomes easier, and Sinatra has shown that it can cope with heavy tasks, which means that they are increasingly mating. 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, it is a subjective choice.

In general, everyone agrees that “a suitable tool must be chosen for work”, but their conjugation means that the decision often comes down to personal choice. Sinatra can give more control over the architecture, but will additional efforts be a worthy waste of your time (or your client, more importantly)? Ryan Bates summarizes the personality types and the framework they choose:

I suppose 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.

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

I think that among Ruby developers there is a significant difference: there are those who prefer small size, lightness, speed, explicitness and explicitness of extensibility; and there are those who prefer full-featured frameworks. Sinatra satisfies the requests first, and Rails - the second. So I don't think Sinatra will supplant Rails. It's just another philosophy that appeals to a certain type of developer.

But perhaps you do not need to make a choice between them. The author, Dave Kennedy , a member of Ruby Source, notes that Rails and Sinatra generally work quite well together:

If in the process of developing 2 frameworks we began to complement each other, this indicates that I am currently working on a multi-tenant application that is intensively exploiting Sinatra inside Rails, a cool thing. Sinatra allowed me to add modularity to my application, before it was so easy for me to do it.

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

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

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

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

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

You might even have a microapp on Sinatra inside the Rails structure. This is applied 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 are so tightly integrated with [Rails]. Instead of adjusting Rails to your will for a specific opportunity, you can redirect the request to Sinatra or the Rack endpoint and do exactly what you need.

Everyone agrees that there is a specific place for each of these two frameworks in the Ruby ecosystem. In essence, they work together excellently, and to a certain extent complement each other in many ways. It seems that quite a few people believe that the two frameworks work in the best possible way together, and satisfy different needs in general terms. 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 he does well, and each is an exceptional example of good practice; so good that these tools were copied to other languages ​​countless times. John Nunemaker with GitHub beautifully and succinctly summarized it:

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

As a community, we are incredibly lucky that we have such well-developed tools, with such good support, and even in open source. Both Rails and Sinatra perfectly cope with 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 thought about creating your own framework as an alternative to Rails? Leave a comment below.

The original article can be found here .