Ruby became famous with the rise of the Ruby on Rails framework. It still is one of the biggest players in the web framework area — even if you compare it with frameworks for other languages. So the rise of Rails helped Ruby (the language) a lot. But this came with a downside: These days, Ruby is mainly associated with Rails and nothing else.

Are there other options as well?

Disclaimer: I started working on this article before the big controversy about Basecamp happened. I don’t want to make any point about this in the article. Regardless of what DHH and others are saying on different topics, Ruby on Rails is still a great piece of software and will continue to be. But there are some great alternatives as well that I would like to highlight.

Sinatra

Sinatra is one of the oldest web frameworks for Ruby. It was initially released in 2007 (Rails was released in 2004). Sinatra is a microframework that inspired a lot of other small frameworks the way Rails inspired full-stack frameworks. For example, the famous Express.js framework was inspired by Sinatra as well as some parts of Laravel.

Sinatra itself comes with just a DSL that you can use to route your apps to your business objects. It doesn’t require a way to determine where the files should be placed and it doesn’t even care for an ORM. This lets the developer choose the best tools for the job but also requires us to think about a lot of the stuff that we wouldn’t have to if we would stick with a full-stack framework.

Sinatra is used in production by companies such as the BBC, Heroku, Stripe, Runtastic, and a lot more.

Compared to other alternatives, Sinatra is quite slow these days. Roda and Hanami can handle a lot more requests per second while also needing less memory.

Roda

Roda is a microframework inspired by Sinatra. As such, it doesn’t come with an ORM, but Roda is developed by the same developer as Sequel and has a plugin that will make it easy to set up Sequel as your ORM of choice.

The main difference between Roda and Sinatra lies in the underlying architecture. Roda uses a routing tree to achieve this high performance, whereas Sinatra uses a sequential search for the matching route. Also, Roda has a lot of performance-optimized code. Jeremy Evans, the maintainer, is really great at this.

Sidenote: If you want to learn from him, I highly recommend watching this video.

Another big advantage of Roda is the documentation. Since Roda is a microframework, there are a lot of things that it can’t do compared to Rails. But what it can do is really well documented and there are enough resources out there that explain how to do things with Roda.

Hanami

Hanami is a full-stack web framework. It is currently in a breakover phase, as the “rewrite” for version 2 is in progress.

Hanami used to be called Lotus, but because of some copyright issues with IBM, it was renamed Hanami. The main developer, Luca Guidi, announced a big collaboration with the team of dry-rb and rom-rb more than a year ago. Now the teams from these projects are working on improving the framework. If you want to follow their progress, I recommend following Tim Riley and Piotr Solnica on Twitter. Tim releases a blog post once a month in which he writes down the progress he’s made.

So, what are the features/differentiators of the new Hanami 2 framework? One of the big differences with Rails is that Hanami 2 makes it easy to create boundaries in your application with the help of so-called slices. A slice is a container for a subpart of the project. It contains the business logic as well as the views and database repository for that subpart.

What is an example of this? Suppose you are working on a ticketing system. A slice in such a system could handle all the logic connected to a ticket (i.e. the workflow for the ticket, the state it has, and stuff like that). Another slice would handle the projects your tickets are connected to. This way, you have a clear separation of responsibility for these two concepts and can define a clear interface to work with. Therefore, the two systems are decoupled and you are free to refactor one without disturbing the other as long as the interface stays the same.

The developers of Hanami also put quite some effort into making it easy to write tests. For this they added a feature called “Auto-injection mixin”. With this it is possible to include dependencies into your objects — this can be a controller or a business object or any other object you use. During development and production this loads the real dependency but when you run the tests and you gave some mock object to your instance it is using this object. Another nice thing is that this makes it really easy to see what depends on what.

Another big difference is the database layer. As a full-stack framework, Hanami comes with a database abstraction layer included (rom-rb). The core concept of rom-rb is quite different than the one Active Record is using. Rom-rb implements a Repository pattern. With this, you have a class in which you create your queries and you get an instance back from a domain object. Of course, the Repository pattern that rom implements is more sophisticated than this! If you want to learn more about this, I highly recommend taking a look at the documentation.

Because of the collaboration with the dry-rb project, Hanami also has quite a few goodies from that project. It uses the dry-validation DSL for validating controller parameters as well as other parameters that need to be validated. Also, it uses the dry-view gem. With this, it is easy to create views that are isolated and reusable. In fact the view is some of the biggest improvements compared to Rails.

A view in Hanami has an object that handles dependencies for the view and also exposes dynamic data to the template to work with. If needed you can also create a view part class that is responsible to attach view specific behavior to your domain objects.

EDIT: The newest Hanami alpha 2 was released just a few hours after this post was published. If you want to go more into the details here is the blog post that highlights some features and also shows how to get your hands wet with Hanami. If you want to learn more about Hanami and the libraries it builds uppon take a look into Hanami Mastery.

If you know the Elixir framework Phoenix, then many concepts of Hanami will sound familiar to you. This is because both of these projects have been inspired by the SOLID principles and put a lot of attention on the maintainability of a growing project.

Conclusion

As we have seen, there are some interesting options out there to use Ruby with a different web framework. All of the frameworks mentioned in this article are already used in production. In the case of Hanami, there are already some version 2 production apps up and running. If you have some experience with any of these frameworks, I would love to read about them in the comments.

In a future article, I will highlight some gems that are great if you want to use Ruby for areas other than web development as well.