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.