Every once in a while, this tiny quote pops up in my twitter feed. I am not even sure where it originated.

Any sufficiently complicated Sinatra app contains an ad hoc, poorly-specified, bug-ridden, inconsistent implementation of half of Rails

— Tony Arcieri (@bascule) October 22, 2012

This time, it ended in this conversation with Steve Klabnik.

As someone who has seen and implemented several successful and clean projects using Sinatra and subsequently Padrino, I'd like to call anyone out who uses this or any similar quotes to easily and try to explain both projects from my point of view. It basically comes down to a point of misunderstanding of what both projects try to accomplish. It might also be some miscommunication in the community as a whole. And the biggest point is a community that dukes out things like this on Twitter using 140 character quotes.

Sorry if things might become a bit inconsistent, I am basically writing a few things off my chest that nagged me for a while. I'll start by explaining where I see both Sinatra and Padrino in the webframework ecosystem.

Sinatra: the anti-fullstack

Sinatra is a library that contains the bare minimum that is needed to properly accept and respond to HTTP requests in a modern fashion: by matching on urls, manipulating request and reponse objects and by allowing arbitrary conditions on routes. You might argue that in its attempt to keep things brief, Sinatra cuts a few to many corners (e.g., I think that "classic" mode should not be used or tought), but it makes as up with some great features that make it really easy to use Sinatra alongside with basically everything.

Problems with Sinatra use

Sinatra is often seen as a pet framework for prototyping stuff quickly and then people evolve from that and sometimes use it for bigger stuff. This is a road to pain. Professional Sinatra usage basically requires that you have read all docs (and yes, they cover almost every little aspect). Many times I speak to someone about Sinatra at a conference, I meet people that are in blissful ignorance of Sinatras interesting features like the Sinatra as a Middleware or Conditions.

I would go as far as to say that Sinatra enjoyment is directly related to how much time you spend with the documentation.

Padrino

Padrino is a webframework based on Sinatra that attempts to solve many parts of running a successful large-scale application while providing as much Sinatra-compatibilty as possible, like project organization, namespacing, configuration, etc. It also has a very different approach to development, by actually leaving the "convention" part of "convention over configuration" to the libraries it uses and expecting its users to make a few decisions before getting started. Padrino also has a very flexible and easily hackable way of binding things together - its basically multiple Rack stacks packed together. If you want to manipulate any of them, there is a supported way of doing so. Also, in contrast to Rails, it lends itself to meaningfully arrange your code instead of having the app folder ruling it all. Just like Sinatra, Padrino is a Rack lovers heaven.

Also, it doesn't default to anything, protecting you from sticking to the default and getting trapped by it. Also, its conceptual weight is very light, the whole framework can be read and understood (architecturally) on a weekend. Padrino is not a reimplementation of Rails ideas like Merb was, so there is no danger of abandonement through merge.

Problems with Padrino

Padrino is still not officially 1.0 yet and is run by a very small team, comparing to the monster that Rails is. Also, from time to time, there are also bugs to be ironed out, beta and all. But it is in a state that is definitely ready for production.

The biggest trap of working with Padrino is considering it a Rails replacement. Yes, there are some equivalents and the team once fell into the trap itself (by not calling controllers namespaces, what they actually are), but handling Padrino like Rails is a problem. Another big problem is treating Padrino as a fullstack framework. It is a larger stack than sinatra, but is not a mortar-and-brick building like Rails. For lack of a better word, I usually refer to it as a "feature hub", a thing that is very geared to integrating other things in a sane fashion.

Its biggest problem is not lack of community, but lack of developers (I currently contribute to the problem through lack of commits). But everytime someone devalues projects built on top of Sinatra (the same argument would go if it was built on rack) as containing an incomplete Rails reimplementations, it shies people away even more, which is a great contribution. Thank you!

The Rails ecosystem is incredibly biased

Just for the record: I know that Rails is pretty modular right now and can be used in filets (Padrino even makes use of this, by loading small parts of ActiveSupport). But I have yet to see any real project that didn't start from the basic Rails template, which is part of what this paragraph is about.

My biggest problem about the Rails ecosystem is that it is incredibly biased towards certain solutions. The extreme "convention over configuration"-cargo cult is one of them. While I think that this is an important feature of any framework, I think that Rails is over-defaulting. I think a number of Rails projects would actually be well off with using different database abstraction layers (e.g. Sequel). This has led to a framework that is sometimes incredibly hard to manipulate, for example using the complex, multi-staged Configuration Framework along with a very extensive Initialization Process. There once was a time where we ridiculed the Java community for things like this. Rails sometimes makes the default very easy at the expense of making the non-default harder. And this is the point where Rails is not my cup of tea.

Either you approach Rails as a dumb user and swallow all of the things it gives you or must turn into a Rails hyper-brain, which no sane project can affort.

The Rails monotheism

Every time someone makes blanket statements like the above, it is a contribution to what I call "Rails Monotheism" and also somewhat devalueing the work of people that actually try to fix this. Those efforts might in some ways be wrong or have issues, but you know who fixes this? People caring about the whole ecosystem and those efforts. People like @headius, who called Padrino out for running bad on JRuby or @postmodern_mod3, for complaining about Padrino being behind the times (and Rails) when it came to view helpers.

I am really sorry to say that, but at the moment "I am (usually) not using Rails" to a Rails developer feels like "I use Ruby" to a PHP developer back in 2006.

A new quote

So, to bring the discussion back to a tweetable level:

Every time I use Sinatra or Padrino, I am happy that the most byzantine parts of Rails are none of my Concern.