By Darren Jones

Rails or Sinatra: The Best of Both Worlds?

By Darren Jones

The Ruby world has been blessed with more than its fair share of frameworks for developing web applications over the years. Recently, though, two of them have emerged as the clear leaders in the field. Most readers of this site will have heard of Ruby on Rails. It was created by in 2004 by David Heinemeier Hansson and provides a MVC framework that helps to boost productivity whilst keeping developers happy. Sinatra was created by Blake Mizerany in 2007 and is a domain-specific language that wraps a lightweight HTTP request and response layer on top of Rack. It’s minimalistic approach is both elegant and classy. The stats at certainly show how popular both of these frameworks are: Rails has 7 million downloads and Sinatra has 1.5 million.

Rails was the reason I got into Ruby web development, but in recent years I’ve been using Sinatra much more (and here are 7 reasons why I love it). In fact I have found that Sinatra, along with a few gems, is usually all I need when building an app. This led me to wonder whether Sinatra is suitable for tackling any project. When is is best to use Sinatra and when is Rails the right choice? To answer my question, I asked for the thoughts of some prominent Ruby developers.

Konstantin Haase is the current maintainer of Sinatra and feels that they both cater for different types of application:


They are both solving a different set of issues, even though they indeed overlap. While Rails is a framework focused on writing model driven web applications, Sinatra is a library for dealing with HTTP from the server side. If you think in terms of HTTP requests/responses, Sinatra is the ideal tool. If you need full integration and as much boilerplate as possible, Rails is the way to go.

David Heinemeier Hansson also believes that there was room for both of them, but feels that is is size of your app that should influence which one to use:

Sinatra is great for the micro-style, Rails is not. As long as you stay micro, Sinatra will beat Rails. If you go beyond micro, Rails will beat Sinatra.

In fact, most people tend to agree that Rails is better suited to big projects whereas Sinatra is a better fit for small micro apps or apis. David goes on to point out a general rule of thumb for choosing whether to use Rails or Sinatra:

If your app has 5-10 end points, there’s a real benefit to just rolling your own with Sinatra. Essentially if your entire controller structure can fit in a page or two of code, running it in a single file is great.

Rick Olson of Github confirms that Sinatra does indeed make a great choice for the smaller stuff:

Sinatra works really well for the API, and smaller sites (internal apps, GitHub Jobs, etc).

David Heinemeier Hansson explains why Rails is such a good choice when it comes to building big web applications:

A large part of Rails’ success is by giving people a curated selection of the best technologies (“best” defined by me and the Rails community) ….
I change Rails every week to better fit what I’d want the perfect framework to be.

Konstantin Haase shares his enthusiasm for Rails and its philosophy:

I love Rails. Rails has been pushing the way we think about web applications. Rails is solving issues for you Sinatra never can, since it can make more assumptions about your application. You get everything set up for you, if you might need it or not, the biggest flaw in Rails’ architecture is to assume everything should be solved by a single tool.

There does seem to be a trade off when getting some features that you don’t really need in Rails, offset by the fact that you get lots of features that you DO need. This can be ultimately worth it, especially when it comes to creating a big project. Not everyone agrees that Rails is the only choice for a big project, however. Geoffrey Grosenbach of Peepcode Screencasts feels that this was ‘an outdated view that was only barely true of Sinatra in 2008 but certainly is not now.’ He highlighted the excellent app, which was built with Sinatra as an example that proves that it is more than capable of building a large-scale production site.

Despite this, Konstantin Haase highlights a potential problem with using Sinatra to create big applications:

Writing a more complex Sinatra application (or rather, an application using, amongst other things, Sinatra) requires the developer to spend way more time thinking about architecture and tooling. This is both an advantage a disadvantage.

Some developers would certainly see this as an advantage as they prefer the tight control over what goes into their application and understanding of how it all fits together. Geoffrey Grosenbach thinks that this is a trade off that is definitely worth it:

A huge benefit of Sinatra is its stability. You trade the convenience of a few Rails generators for your own design decisions. Writing in Sinatra can give developers and businesses API stability because the framework rarely changes. You own your code and you decide when it should change.

He goes on to say that Sinatra is the perfect candidate when it comes to building an application:

I start all my new applications in Sinatra and usually find that I don’t need any more than Sinatra together with a few Rack plugins, a simple CouchDB library, and Backbone.js for the front-end.

Sau Sheong Chang, of Yahoo and author of Cloning Internet Applications with Ruby follows a similar development model:

Sinatra fulfills all I need for a base platform and anything else I need I can either use gems or is already provided by cloud platforms and services (like Heroku and its eco-system of add-ons). Anything else left over I can write it myself.

In fact, this idea could be taken a step further by using Sinatra to roll your own bespoke framework that fits your needs perfectly. Start with Sinatra and then add in the gems that provide the features you need in order to create your own bespoke framework. In some ways, this is what the Padrino project has done.

David Heinemeier Hansson doesn’t see the point in doing this:

Breaking everything into tiny little pieces and having developers assemble everything on their own is the antithesis of what Rails is all about and how it won the framework game. Tens of thousands of man hours have gone into getting us to this point. Trying to reproduce that is a fool’s errand.

But while having more control over what goes into your app might be a nice idea, Konstantin Haase warns that this could take up a lot of your time:

The biggest disadvantage with Sinatra not solving the issue for you is, well, Sinatra not solving the issue for you. You actually have to deal with that issue. You might end up wasting too much time dealing with it.

And this is time that the developers simply may not have at their disposal if they are working to a tight budget. David Heinemeier Hansson is concerned that using Sinatra involves wasting so much time trying to reinvent the wheel:

the gains Sinatra offers you in simplicity are likely to quickly be offset with all the work you have to do replicate solutions Rails already provide. I pity the person who would try to build all of Basecamp, GitHub, Shopify, or any other major app in Sinatra alone. Rails is involved and large because it contains solutions to most of the problems that most people building apps of such scale will encounter. Trying to recreate all these solutions by hand is the anti-simplicity.

Ryan Bates, presenter of Railcasts feels that an advantage of using Rails is the amount of time that is saved when starting a project from scratch:

The default Rails app provides a lot that I need which requires extra setup in Sinatra. This can lead to faster development in Rails.

This sentiment is echoed by Rick Olson who believes that Rails made it easy to get GitHub off the ground:

I think Rails was a major asset to the founders [of GitHub] in the first year. They were able to take advantage of some of the higher level Rails features and iterate quickly.

The Rails mantra of ‘convention over configuration’ is cited by Chad Fowler(co-organizer of RubyConf) as another reason why Rails speeds up the development of big projects:

The Rails generators and structure provide conventions that Sinatra doesn’t.

The problem is that these conventions can sometimes feel like a straight jacket at times as Rick Olson points out:

Rails is fine if you agree with the Rails opinionated conventions, and stay on the “golden path.”

In contrast, Sinatra, has no restrictions whatsoever, as illustrated by this great quote from Aaron Quint provided by Satish Talim of Ruby Learning:

“Sinatra follows an abstract pattern: WDNNSP (We Don’t Need No Stinkin’ Pattern). WDNNSP means that Sinatra is beyond flexible, and it contains no preconceptions of how you organize your domain or business logic. It has no implicit folder structure, no default Database Abstractor, and no restrictions about how or where you use it.”

A lot of the appeal with Sinatra is being able to choose how your app is structured in every way. Using Sinatra can be liberating, as you are not restrained by size, structure or work flow. You can build an API, web application or pack your code up as a gem.

It may surprise some people to hear that David Heinemeier Hansson is also a fan of Sinatra’s simplicity:

I’ve used Sinatra in the past and I like it a lot. It offers an entirely different approach that’s great for a much smaller scope of problems, but does it really well.

So is there anything that Sinatra brings to the table that he would consider adding to Rails?

There’s nothing inherently in Sinatra that makes me want to redo Rails in other ways.

He admits, however that Rails nearly copied one of Sinatra’s coolest features:

We considered adding a single-file mode to Rails but rejected it because why would we want to optimize for something Sinatra already does so well?

Rails certainly provides a huge amount of features, but this often includes many that you aren’t needed – or they don’t work exactly as required. Rails 3 tries to mitigate this as much as possible by decoupling some of the different features, which can lead to a lighter and more confgurable exerience, as Chad Fowler points out:

Rails itself isn’t all that “heavy”, especially with the ability these days to trim it as you see fit.

Rails 3 introduced a lot of configuration options that allow you to tailor the experience to suit what you want to do. Despite the ability to cut out the cruft, Konstantin Haase warns that it is often just too tempting to keep it all in there, which leads to bloat:

In my experience, Rails apps often and up as one monolithic application. [not using Rails] leads to modularity, flexibility, fast test suits and scalability. However, you could reach the same architecture while carefully constructing Rails applications, it is just very tempting not to.

David Heinemeier Hansson doesn’t see this as a problem and feels that Rails is a good fit, whether you use all the features or not:

There is nothing practical gained by physically removing a piece of code in Rails that you do not use. Nobody is forcing you to use all features. [Many features in Rails] are entirely optional and can be completely turned off, if they rub you the wrong way.

Rails is becoming lighter and Sinatra has shown it can do the heavy lifting which means that there is an increasing amount of overlap between the two. Chad Fowler believes that, in actual fact, both Sinatra and Rails could be used for a variety of projects:

I think in truth each could be used for both ends of the spectrum. I suppose it’s a subjective choice ultimately.

The general consensus seemed to be ‘choose the right tool for the job, but the overlap between the two means that the decision of which to use often comes down to personal choice. Sinatra might allow you to have more control over the architecture, but is the extra effort a good use of your (or more importantly your client’s) time? Ryan Bates summarizes what type of person would be more likely to choose which framework:

In the end I think it depends on your preference, whether you like to start lighter and add as needed, or start heavier and remove something to make lighter if needed.

Geoffrey Grosenbach proposes that there are fundamentally two different types of developer:

I think there’s a massive divide between Ruby developers who prefer small, light, fast, explicit, and extensible vs. those who prefer full featured frameworks. Sinatra provides the former, Rails provides the latter. So I don’t think Sinatra will displace Rails. It’s just a different philosophy and appeals to a certain kind of developer.

But perhaps you don’t have to choose one over the other. Fellow Ruby Source author Dave Kennedy points out that Rails and Sinatra actually work really well together:

If anything recent developments have made the 2 frameworks complimentary. That said I’m working on a multi-tenant application at the moment that uses Sinatra heavily within a Rails app, some pretty cool stuff. Sinatra has let me modularise my app in a way I have not been able to do before so easily.

A number of people point out that the ability to mount Sinatra apps in Rails 3+ means that you really can have the best of both worlds. In fact Chad Fowler feels that the whole concept of choosing one over the other is meaningless:

The ability to mount Sinatra apps inside Rails 3 apps makes it a choice you don’t need to worry too much about.

Geoffrey Grosenbach feels that this will give apps a more modular feel:

Many people are embedding Sinatra apps inside Rails apps. This mimics the design of the Django framework, where an app consists of many smaller apps that handle specific parts of the app (and are often reusable between apps).

David Heinemeier Hansson also feels this was a nice way of doing things:

You can even have micro Sinatra apps inside your Rails structure. GitHub has that for a few things. Nice model.

Rick Olson ellaborates on how GitHub frequently use the pair in tandem:

I’m very thankful that Rack and Sinatra integrate so tightly with [Rails]. Rather than trying to force Rails to your will for a specific feature, you can route the request to a Sinatra or Rack endpoint and do exactly what you need.

Everybody agrees that there is a place for both of these frameworks in the Ruby web ecosystem. In fact, they work incredibly well together and in many ways complement each other to a certain degree. A lot of people seem to think that the two frameworks work best together and fill different needs in general. Where there is some overlap, they appeal to different types of developers. They both do what they do so well and are exceptional examples of good practice – so much so that they have been copied to death in other languages. This is brilliantly and succinctly summarised John Nunemaker of GitHub:

They both have their place. Rails is better if you just want to get things done. Sinatra is better for simple things and for when you want to control everything and use your own opinions.

As a community we are so lucky that we have such well developed tools that are so well supported and open source. Both Sinatra and Rails cover all the bases so well, that they really do give us the best of both worlds.

What do you think – have you used Rails and Sinatra, do you prefer on over the other? Would you consider Rolling your own framework instead of using Rails? Leave a comment below.

  • I took an introduction course to Ruby and one of our projects was to build a to do list app with Sinatra. It was challenging at first because I was so used to Rails and its instant gratification of building a web app. But the further that I work with Ruby, HTTP, and Rails, the more attractive Sinatra becomes for micro apps.

    • Hey Andre,

      I’m sure that you’ll love Sinatra more and more … and not just for micro-apps – you can use its modularity to piece together big, production style apps. It’s also great for learning the Ruby language too!


  • Padrino doesn’t get nearly the recognition it deserves in the Ruby community.

    I started using Padrino in place of Rails and never looked back.

    • Hi Chris,

      I’ve not really used Padrino that much. How come you prefer it to Rails?


      • I’d say the biggest reason is the speed of Padrino vs. Rails. It’s roughly 4x as fast. See the benchmarks:

        One of my favorite features is the drop-in admin (similar to Django) with built-in user and role management. You can generate CRUD pages for your models as well.

        Padrino is agnostic. You can use a variety of components for your database wrapper, javascript library, renderers, stylesheets, etc. Rails makes these choices for you by default, but you can use others with a little work.

        Routing is controlled in the controller vs. a separate routes file with Rails. You can make it behave exactly like Rails or break out of the mold if you want to.

        You can mount sub-applications in a Padrino project. You can now do this with Rails 3.1.0 and Engines, but Padrino’s way feels cleaner and simpler.

    • Eleo

      +1 I can’t seem to convince enough people that Padrino is amazing. It’s lightweight and non-opinionated like Sinatra, while giving you just enough power to build a large app ala Rails.

      • I have to confess that my first thoughts about Padrino were ‘why try to emulate what Rails already does so well’, but after reading your comments I’ve taken another look at it and can see that its goals are quite different. The drop in admin looks very useful. It would be good to see slim included as one of the rendering options though.


        • Slim has been one of the rendering options available for a project for a while now:

          • i’m using slim with padrino every day :D

          • I thought it was weird not to support Slim. I was going off the table that is displayed on the homepage when you click on agnostic – only erb and haml are listed as rendering options.

            Good to know that Slim is in there too – now there’s even more reason to give it a go!



    • baiki

      Precisely where I want to go. +1

  • Sinatra is NOT just for micro apps. Sinatra has great modularity support, just subclass Sinatra::Base and treat each class a controller and combine them in We’ve used it for some major applications (>8000 loc). The upside is less magic, more control and higher performance.

    • Hey Carl,

      It’s great to hear from somebody who has used Sinatra in some big apps. I think it gets a reputation for being just for micro apps because it makes it so easy to create small, one-file apps. But as you point out it can be used to create big modular apps too. Do you think it took longer to do this than just using Rails, and if so, do you think the extra time and effort was worth it for the extra control you got over your app?


      • I think the “extra” time it takes to models or controllers by hand instead of with a generator is neglectable. we often start from a boilerplate when starting new projects so that cost is very low as well (

        I think we win time in that less things that can go wrong because the stack is lower.

        Another win is the ease of upgrading…

  • billstickers

    i’ve been moving toward sinatra for a little while now, as good js frameworks to replace the server-side send/response cycle have begun to be useable. now that rails appears to be solidly in it’s postmodern phase, i expect to greenfield very few rails apps going forward.

    • That’s interesting to hear billstickers. Do you think Sinatra integrates better with JS frameworks in this way? And Rails in it’s postmodern phase … an interesting observation!


      • billstickers

        you can easily use rails to serve the backend requests, and i have a recent backbone based app that uses it that way. but once you start pulling the front end functionality out, then using the rails stack becomes less compelling because you still have to put up with all it’s opinions but you are getting less value. pairing up with sinatra makes a lot more sense to me in this configuration.

  • I learned the Rails way, it was not meant for me. Then I found Sinatra and loved it . Shortly after a friend of mine said, “We could build something awesome with this”. A year later and we have just released our framework, “Vesper”.

    We use Sinatra as the foundation. It is really easy to use. Being relatively new (2 years) in the programming world that was the most important part for me.


    • Well done on creating Vesper Richard. You’ve confirmed what I thought – that Sinatra provides a brilliant and solid base for rolling your own framework. Vesper looks like an interesting project, good luck with it.


  • I am not sure about ‘best of both worlds.’

    It *is* nice that you can use sinatra and rails 3.x together, by embedding a sinatra app in rails, or probably other ways too (requiring certain parts of rails into sinatra?). It is probably useful in some certain cases; it is just pretty cool; and it shows the flexible architecture of both frameworks.

    But I think in practice actually doing so is just as likely to get you the *worst* of both worlds as the best. Now you (or any future not-you maintainers or developers) have got to understand how *two* frameworks work, and how they interact. I think you probably lose the simplicity and transparency that is the good part of sinatra, while also losing the “don’t have to spend so much time architecting, because it makes decisions for you” that is the benefit of Rails.

    In fact, the *worst* of both worlds, in some ways. Still probably useful in very specific circumstances, but I don’t think it’s probably good general advice to get ‘the best of both worlds’.

    I think the first part of your post actually DOES do a *great* job of a non-partisan illustration of the tension between Sinatra approach and Rails approach, the strengths and weaknesses of both approaches. Ideally we’d all want a framework that has the best of both, that gives you a good _default_ architecture that doesnt’ make you think unless you want to or don’t want it’s defaults, while still being stable and simple and easy to understand and transparent without much magic, etc. But it’s *hard* to make something like this, there is a fundamental tension between the two poles, optimizing one often de-optimizes the other. If it’s possible, the community hasn’t figured it out yet.

    That said, coming from Rails background myself, one thing I do do with Rails, is seldom use the “resourceful routing” approach. I do simple manual one-by-one routes in Rails routes.rb, which I think winds up being closer to what you’d do in Sinatra too. You can consciously avoid using some Rails features if you don’t want em — most of em, really, in Rails 3.x, although if you stop using too many features that many rails gem plugins won’t work, because they can’t assume what they thought they could.

    (You can probably do the same from the Sinatra end, and consciously use and require certain Rails gems to only use _specific_ features you want. Like, say, the Rails i18n. Or maybe even rails view helpers and automated javascript behavior. Would probably be harder to do something like use Rails routes, but maybe possible. You could perhaps even use Rails controllers in a sinatra app, in the post-rack-unification world. I don’t know if you’d want to, at some point, why not just use Rails?)

  • Also, hmm, in Rails 3.x, your routes file can route to _any_ object that implements rack interface, including if you want an anonymous class you define in-line, or even a lambda.

    So maybe Rack 3.x already does support the single file approach if you want to use it — your single file just has to be `config/routes.rb` (although there’s probably some way to hack even that in a dozen lines of code if you really want to)

  • Eli

    I am also a big fan of Padrino because it gives you just enough structure without being overbearing and also adds some generators for you, which are handy for rapid web development.

    I think you are missing one very large thing in this article. Maintainability. One of the biggest benefits that both rails and padrino have is their structure. When you break into a rails/padrino app that someone else has written you have a base knowledge of where things are and how they work. This allows a new developer to hit ground running on a project, or makes it much easier to get a developer up to speed if you need to add another hand late in the game. This is a very common happening in my office. Most of us absolutely dread taking over and jumping on one of the projects that was built on sintra because it seems like every one is built in a different way, and you have to spend a lot of extra time following bread crumbs.

    Sorry for the rant, just my 2 cents.

    • That’s a really good point Eli. Having a standard structure definitely makes things easier for people to just pick up where somebody else has left off.

      Although I suppose on the flip side, a team using Sinatra can use their own structures that fit in exactly with their workflow … although this won’t be very useful if somebody else has to then pick up the project.


      • But that’s not a framework issue. That’s a design issue of the app. If the Sinatra app is hard to dig into because its so non-standard then it may be designed poorly, doesn’t have tests to read, has spaghetti code, etc.

        Rails does help because for the most part you can count on views being in one place, tests in another, etc. but that doesn’t mean that its any easier to debug. Just because Rails has separation of concerns built into the file structure, doesn’t mean poor programming practices can’t make it a mess. :) We’ve all seen crazy stuff I’m sure.

  • An excellent article about two pretty spectacular frameworks – I’m glad we have both!

    If anyone wants a breakdown of why (imo) many of us are choosing Rails (over all-language frameworks not just Ruby) check out this blog post:

  • Ramsees

    I started learning Ruby on Rails, the reason belive it or not was that I needed to undertand better ASP MVC, I liked, but after I heard about Sinatra and Loved it, Im using it right now in a project in the place I work, it is quite a project but I think Sinatra can handle it.

    • Hi Ramsees,

      No wonder you liked both Rails and Sinatra – they are both exceptional at what they do … and Ruby is such a great language that it makes writing apps a much more pleasant experience, whatever the framework.

      I’m pleased to hear that you’ve found and now using Sinatra – I’m sure it will be able to cope with whatever you throw at it!


  • Red

    Coming from Rails background myself, one thing I do do with Rails, is seldom use the “resourceful routing” approach. I do simple manual one-by-one routes in Rails routes.rb. You can avoid using some Rails features in Rails 3.x, although if you stop using too many features that many rails gem plugins will not work.

  • It strikes me as interesting that many of DHH’s comments about “why would you want to do all that work?” or “Sinatra solves a different problem” would be the EXACT same thing that pretty much every evangelist of a language or framework says when their product hits maturity and a new iteration shows up on the market and starts gaining attention.

    That says both good and bad things about Rails. First, that its now “mature”, has a broad ecosystem of support and ready for everything you can throw at it, which is excellent for Enterprise and more stolid IT shops who rarely hang their hat on a new thing.

    But maturity often also means “inflexible” or “set in its ways.” Not in a malevolent sense, but everyone saw the debate about HAML / SASS / Coffeescript. As a framework gets more widely adopted, inertia sets in, and larger more radical changes are harder to digest. And that is when new ideas and new technologies tend to sprout.

    I’m definitely going to have to explore Sinatra more now though… Great article.

    • Thanks Dave, glad you enjoyed the article.

      I think you’re spot on there – but I’m sure DHH would think that Rails does exactly what it needs to because he has such a strong influence on what goes in there … so, obviously, it is a perfect fit for his needs. Of course other people may have different needs and this is where they might want to put something together themselves.

      You definitely should have a play with Sinatra … it rocks big time!


  • Jason Milkins

    This is a bit late I know, but it’s not all that difficult to provide Sinatra as a subsection of a Rails app.

    Padrino is ok, but really, if you want it for the speed, routing a Sinatra app through rack, will get you there too, and you’ll have access to everything you need from rails, it’s good if you need to add socket or pubsub/sse/eventsource features, or anything else that Sinatra can get going quickly.

    just setup a match in routes.rb that points to your sinatra class…

    e.g. create a /lib/api/core.rb which provides class Core as a subclass of Sinatra::Base


    module Api
    class Core < Sinatra::Base
    get '/api' do
    "Let's go!"

    and your route.rb would include

    match ‘api’ => Api::Core

    and you’re good.

    Obviously you have access to all your models etc. so you have the best of both worlds.

    Ultimately you could do the same thing with Padrino, but you obviously have a more complex task to do so, and a ton of overlapping functionality, that you don’t need, so it’s not really practical to do it.

  • Rails sucks. It’s bloated, slow and doesn’t teach you anything. It’s too easy and boring.

    Sinatra is well suited for large applications and invites the programmer to create custom solutions. There is nothing you can’t do with Sinatra, Rails just sucks 100%.

    • Hey Vidar,

      I completely agree with you about Sinatra and would always choose it for development. Your view of Rails seems a bit harsh though! Lots of people find it very useful and it has influenced a large number of other frameworks.


Get the latest in Ruby, once a week, for free.