Rails vs Sinatra - use the right tool for the job

Rails vs Sinatra - use the right tool for the job

There is an old saying: „If your only tool is a hammer, every problem looks like a nail“.

This principle can be applied in every aspect of our lives – from doing house chores to starting a challenging work project. Using the right tool for a job sounds like common sense, but picking the tool that will allow us to achieve the highest quality of work in the shortest amount of time is one of the biggest challenges in most business niches, especially programming.

The most popular choice isn't always the best one

For example, every time we start implementing a new application in Devōt – one of the most important decisions to make right at the beginning is which technology we should use to facilitate the easiest implementation. If our goal is to create a web application, and Ruby is the pre-decided programming language – which framework will make our job the least complicated and most efficient?

If you've ever done any programming in Ruby, you must've come across the Ruby on Rails framework, but being the most popular doesn't make it the best choice for every app implementation in Ruby. A great programmer should know how to pick the best tool for a particular job – think of it this way: even though you could, you will not stir your stew with a hammer, you will use a cooking spatula.

Among many other choices, one framework particularly stands out when choosing the proper Ruby-based framework for app implementation – the Sinatra.

If you're one of the people who starts every project in Rails by default, this is a topic for you – because sometimes it's just overkill, and you could strongly benefit from trying out an alternative framework. The big question here is: how to decide which framework is the most reasonable solution in a specific situation? The answer lies in the specification of the application in question – more precisely, its complexity and project size. By the end of this read, the answer will be perfectly clear.

Sinatra vs Rails: similarities and differences

The Ruby on Rails framework was implemented in 2004 by David Heinmeier Hansson. Its main characteristics are the use of an MVC (Model-View-Controller) architecture and emphasis on the use of the DRY (Don't Repeat Yourself) principle, which aims to avoid repeating any part of the code or the Active Record, layer of the system responsible for representing business data and logic. This framework includes everything needed to create database-backed applications according to the Model-View-Controller pattern, and it works as a writing model framework.

On the other hand, Sinatra is a web framework and DSL (Domain Specific Language) which was implemented in Ruby by Blake Mizerany in 2007. It wraps a lightweight HTTP Request / Response layer on top of Rack, and it is actually a library for dealing with HTTP from the server-side.

Some of the well-known applications implemented in Rails are GitHub, Airbnb, Yellow Pages, MyFitnessPal, Twitch, while Sinatra has been used to implement Notable, Marley blog, and Follow Cost.

What do they have in common?

Before answering the question – when to use Rails, and when Sinatra; let's start with their similarities. What do they have in common? Apart from the obvious – the use of Ruby Programming language – they both use Rack, middleware which provides a minimal, modular and adaptable interface for developing Ruby-based web applications. Specifically, it is a way of filtering the requests and responses that come into the application, located between the client and the north.
Rack interface
So, what are the main differences? First, Sinatra is much more lightweight and requires fewer resources, which makes it an excellent choice for building smaller, lightweight apps - while Rails is packed with features, comes with a lot of code, and it's suitable for building complicated web applications.

Flexibility vs strict structure – the main differences

Because of its lightweight nature, Sinatra is very flexible and allows us to build and implement simple apps with much less effort. On the other hand, Ruby on Rails is full of various functionalities and comes with a large amount of code, so it's a decisive choice if we want to implement a complicated application in a short amount of time.

Further, when we look at the structure of the application in Sinatra and in Rails, the differences are apparent. In Rails, the application is strictly structured, the layout of files is pre-defined, and the MVC architecture is used by default.

On the contrary, almost nothing is pre-defined in Sinatra, and each application can be structured in a way we deem best for the project. Therefore, we can conclude that Sinatra is the better choice when we don't want to commit to a strictly defined layout of files and folders but want to adapt it to our application – while Rails is more appropriate if it's important that the application has the MVC architecture.

Rails vs. Sinatra
After looking at the main similarities and differences, we can conclude that it's somewhat natural to use Sinatra when we want to implement simpler, smaller apps, while larger and more complex applications are reserved for Rails. But, of course, we shouldn't be fooled by such simplification – because every Ruby developer is familiar with Ruby gems. These open-source libraries contain Ruby code and are packaged with a little extra data that gives pure Ruby additional functionalities. Therefore, by adding ruby gems to the Sinatra application, we can easily add functionalities we need to Sinatra – those which are available in Rails by default.

Getting the work done faster vs understanding the background – the guide for beginner developers

This leads us to a new realization – that even in Sinatra, we can implement more complicated applications, but, obviously – it's easier to do that in Rails since it already has extra functionalities implemented and requires no additional work to add them.

One of the most important points when comparing Rails to Sinatra is the time factor. When we look at the beginner developers making the decision about a more suitable framework to use, we have to consider two possible goals. If the goal is for the person to start the app implementation as soon as possible, but without a proper understanding of the framework and its logic – Rails is definitely the way to go. It has plenty of functionalities already implemented, and it saves a lot of time - we can say Rails is „convention over configuration“, it allows „the magic“ to happen . Since it contains much more libraries, Rails has a significantly higher rate of dependencies and security risks. The pure number of gems included in the app implies a higher chance of security flaw in some of them, as well as the possibility of a certain gem becoming unavailable – which can literary break your project, as we recently saw with mimemagic gem.

When we talk about the time factor - Rails enables a beginner to enter the world of programming much faster. Although, we must emphasize that they will hardly understand what is happening in the background.

On the other hand, if our goal is for a beginner to understand the background and all of the „behind the scenes“ finesses of programming – such as connecting a project to a database or configuring servers, Sinatra is definitely our framework of choice. The reason is quite simple – as previously stated, to achieve the functionalities the Rails has by default, Sinatra needs to use numerous Ruby gems – and the developer needs to be skilled enough to connect all these added functionalities in Sinatra.

So, what is the right tool for the job?

Finally, we came to the part where we answer the question from the introduction - which framework will make our job least complicated and most efficient? Of course, Rails will make the implementation of Ruby easier for the developers in time-sensitive and complex projects, and it's an excellent choice for training the beginners to start programming a soon as possible - assuming they will learn the background processes over time. However, Sinatra makes our job much easier in cases of the implementation of smaller apps or apps in which we want a customized document structure instead of imposed MVC architecture, and it is undoubtedly a better choice when we want a beginner to learn from scratch how all the essential parts of the application in the background actually work.
Here in Devōt, we regularly use both frameworks – depending on the project scope and our goals. Therefore, if you have any questions about the two frameworks or have trouble choosing between the two, feel free to contact us, and we will try to help.

Author:


Manuela P