Ruby is a dynamic interpreted programming language written for simplicity and power, but it’s just a language. It is not a dedicated web development technology, and, as such, you need a little help to make websites in Ruby. This is where Ruby web frameworks come in. They come in different sizes and levels of complexity, so it’s important to select the right framework for your project.

Of course, technically, you can make any framework viable for any job. The biggest frameworks could be used for the smallest jobs. It will just be overkill, and probably take much longer than needed. In the same way, the smallest frameworks could be used for the bigger projects, but you’ll need to write a lot more code than you should.

The small: Sinatra

There are a number of “micro frameworks” for Ruby (some of which are downright tiny), but I’ve chosen Sinatra because it’s nicely representative of this category of frameworks. Sinatra’s website describes it as “a DSL for quickly creating web applications in Ruby”, which is exactly what it is, and, as the description of a DSL (domain-specific language) implies, it does not concern itself directly with how you want to structure your project.

Basically, what Sinatra offers is the ability to listen for and respond to HTTP calls — that’s its most basic function. It does not impose or attempt to supply an architecture. It just does what it says on the tin.

At this point, anyone who has used Sinatra will be getting ready to comment that “Sinatra does a whole lot more than that!” And they’re right; it does offer a selection of helpers and supports a solid collection of the template languages, and that’s before you get to all the available extensions!

The trouble is, if you start adding a lot of extensions to a small framework, it’s no longer small — enter the medium.

The medium: Padrino

I chose Padrino to represent the medium-scale frameworks because it is a logical progression from Sinatra. In fact, it is Sinatra.

To quote the Padrino website: “Padrino is by default a full-stack framework which provides a large number of enhancements to Sinatra.”

You can think of it as “Sinatra with benefits”.

One of the most useful design features of Padrino is the ability to “mount” apps inside other apps. This allows you build discrete sub-applications containing domain-specific functionality, and then share these across your entire web project. Building parts of your web applications as sub-apps not only helps in code management and reuse, it also makes testing easier.

Padrino also offers mailer, caching, and logging services, as well as form, tag, asset, and text helpers to make it easy to produce fast, consistent code.

Routes (the paths to which the web app responds) are easy to create in Padrino, and can be defined in any controller file while still being globally accessible. Of course, on larger projects, this raises the potential for management difficulties.

Best of all, you don’t need to use Padrino to use Padrino — the modules that make up Padrino can be loaded individually into Sinatra.

The large: Rails

This is the standard, in as much as it’s the framework that most quickly comes to mind when people think of Ruby web development.

Rails is a CoC (convention over configuration) framework. It comes from the perspective that you don’t have to specify everything. Where you put something is as meaningful as what you put there. There are exceptions, of course; routes in Rails tend to be “configured” in the routes.rb file, but this is to centralise common resources for ease of management.

A demonstration of CoC is that Rails has places already assigned for you to locate your style sheets and JavaScript files so it can compile them into cached files to be included in your project. It’s a great feature if you have lots of JS resources to manage, but overkill if you’re working on a small project. It also means you have to “pre-compile” your assets on deploy.

Rails offers all the functionality that you see in Padrino, and adds benefits like built-in database abstraction and background tasks (such as may be used for housekeeping, data integrity checks, off-session processing, etc).

When you create a new Rails project, it lands with about 10 top-level directories, several with sub-directories, and a whole of .rb files ready for your code. It will also assume that you’ll need a database, and include that in the initial setup. This is the convention. It will seem over-complex if you’re just building a small site or a light web service, but in larger projects, you’ll find yourself using all those resources.


It all comes down to management and feature scope; the smaller frameworks offer more granular control, but do less for you, while the larger frameworks take a lot of the load off, but that only has real benefit if your project has the kind of scale to take advantage of it.

My recommendation is to use Sinatra if you’re just trying to get a feel for Ruby development, use Padrino if you’re building anything real, and step up to Rails if you have a lot of people working on the same code or if there are specific functional requirements that make it a better choice.