How Setting Aside Rails and Picking Up Padrino Might Make You a Better Ruby Developer

Learning languages through frameworks

I love frameworks. I love that frameworks like Rails and Bootstrap, in particular, make me more productive: People smarter than I have taken care of several decisions that distract from the typical goals of my web applications. I spend most of my time developing within the friendly confines of such frameworks, in part because I enjoy building—and delivering—applications I can show off to non-programmer friends (or clients, for that matter). They’re just not as impressed when I show them a Hello World app or a completed kata, for some reason.

Of course, there’s a danger here. With out-of-the-box, “omakase” Rails, it’s increasingly possible to create powerful applications with a rich understanding of Rails, but a so-so (or worse) understanding of Ruby itself. A well-done framework hides much of the complexity of a language, so the developer can focus more on the problem domain. But if and when an application’s requirements deviate from those for which a stock Rails installation is suited, a couple of things might happen for the developer who’s not sufficiently grounded in the language. At best, programmer productivity slows considerably. At worst, dirty hacks and kludges start appearing in the code base, and technical debt mounts quickly.

As a result, I tend to make myself spend a solid week or two in a language before taking on a framework written for it. I try to understand the language’s benefits, limitations, and idioms, so I can better understand why a framework works the way it does. This can be difficult for me personally as a learner. I’ll admit that I find it boring. I just want to build things with this language I’m learning, and I want to do so without having to replicate a lot of boilerplate work that’s already been done for me in a framework. So, for me, it’d be nice to be able to learn these things within the construct of a framework that adds the ability to demonstrate my accomplishment.

In the Ruby world, Sinatra is one such framework. It’s incredibly lightweight and agnostic. It makes a few friendly suggestions, but quickly gets out of your way if you want to do something differently. However, for those new to Ruby—and especially those new to programming—the blank canvas provided by Sinatra can be pretty daunting. There are plenty of tutorials out there, but since Sinatra doesn’t prescribe a strict structure, these tutorials can confuse a newcomer more than they benefit. In learning, a little structure and scaffolding can go a long way toward mastery.

That’s why I was happy to be reminded of the Padrino framework a couple of weeks ago. Padrino is built upon the rock-solid foundation of Sinatra, but applies some default structure to a new web application. It adds some Rails-like productivity benefits like generators and helpers, but under the hood adopts a much more modular and agnostic approach toward how frameworks should work. While some sensible defaults are provided, it’s ultimately up to the developer to make decisions on database libraries, tempting tools, and test frameworks.

My ears perked up recently when a fellow Rubyist, Sumeet Singh, brought up Padrino during a lightning talk at a meet-up of the Kansas City Ruby users group. Sumeet reinforced the idea that building with Padrino is a great way to really learn Ruby—it provides just enough scaffolding to get a project started and keep some of the boilerplate decisions about structure out of the way. At the same time, it offers an ample opportunity to try new libraries, coding practices, and above all a markedly different approach to web application development than offered by Rails.

Sumeet made a second point I hadn’t considered: More than the established, more bureaucratic projects like Rails, Padrino is a great project for the first-time open source contributor. The modular nature of the project and comparatively small community size provide opportunities to work on an area of interest, with less likelihood of interfering with others’ work—or creating the type of drama that can sometimes emerge from more opinionated frameworks’ communities when disagreements happen. The Padrino recipes project provides a great outlet for smaller contributions, or developers can tackle open issues within the framework itself. If not pitching in code, there’s always room for additional documentation or tutorials in Padrino (or any open source project, for that matter).

I suspect I’m not the only developer who learns, builds, and levels up this way. I also suspect that other languages have their Padrino-like frameworks—those offering just enough support to get started, but requiring me to think early on about my application’s makeup and my approach as a developer. I still love Rails, but I’m looking forward to starting a new project with Padrino—and exercising some of those corners of Ruby I don’t get to use in my day-to-day Rails development.


Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Programming
  • Joshua R. Simmons

    I’m not a Ruby developer, but I have definitely seen similar things happen among PHP developers, especially with the wild success of WordPress. I think it’s probably even worse with PHP because so many frameworks allow developers to (almost) completely avoid code!

    Best advice to a new coders: Work as close to the metal as possible, at least to start.

    This calls to mind a great article Joel Spolsky wrote back in 2002:

  • scottradcliff

    Ah, Padrino. I played with it a few years ago, but had forgotten about it. I confess the more Rails grows, the less inclined I am to reach for it first. It’s often Sinatra, unless I know that by the time I’m done adding dependencies to the app, I’ll almost have Rails. In that situation, Rails makes more sense. Now I’m thinking maybe Padrino is a better option if Sinatra isn’t a good fit.

    I didn’t know Padrino Recipes existed. Great find.