Rails Blurs the Lines

By Deane Barker • • 4 min read •
AI Summary

This post explores how Rails blurs the boundaries between applications and frameworks, highlighting its flexibility and abstraction. The author discusses the implications for developers, emphasizing how this approach fosters creativity while also leading to potential drawbacks in understanding underlying processes.

I’ve been working with Rails for a few weeks now and it’s making “install” vs. “build” decisions much harder –

(We interrupt this post to get two things out of the way:

  1. Yes, Rails is as good as everyone is saying.

  2. And yes, that pisses me off too. I worked so hard at becoming a PHP ninja that I’m bitter about having to walk away from it to get this level of functionality and polish. But, time marches on, and so shall I.

Okay, back to my point…)

At its core, Rails lets you build good stuff fast. Really fast.

Say you come up with a data model for your church Web site. Let’s say you have a half-dozen tables for various things you want to manage: sermons, news articles, staff profiles, etc.

If you have the database built, Rails will give you a functional administrative interface for the five tables in…maybe two minutes (you have to run the same script five times – how fast can you do that?).

Since you probably have some relationships in there – foreign keys and stuff – give yourself another five minutes to set up all the management for those. Then give yourself maybe two hours to really dial in the interface, add validation, file uploads, etc.

So, in just over two hours, you’ve gone from five database tables to finished app. Users will tweak of course, but the way Rails puts it all together, tweaking is a wonderfully simple and elegant affair. I can honestly say I’ve never written kludge with Rails (yet – I haven’t been coding it long).

What this means is that the line blurs between (1) using a pre-built system, and (2) rolling your own system. In the above example, we rolled our own CMS…or did we? Sure we coded some stuff, but Rails did all the real work. In the end, we did less work than if we installed and configured a pre-built content management system.

It just so happens that we’re looking for a CMS for our church. I’ve always been in the “use a system that’s already been built” camp, but with Rails, I don’t know if that still applies. I’m looking at all these systems and thinking, “I only need 10% of the functionality they offer, and I could built that functionality faster with Rails that I could wrestle it out of any of those systems.”

So, like I said, the line between “build it yourself” and “install and configure” really blurs. You could look at it that Rails is the CMS, it just doesn’t know it yet. It just needs to be…oh, I don’t know… installed and configured.

I don’t want to reinvent the wheel, but with Rails, the wheel is there, I just need to smooth it out a bit. And is that so bad?

Links to this – The Quandary of the Single Table Web Site December 15, 2005
Many smaller projects need a single table of managed data in an otherwise static website. What's the best way to handle these situations?
Links from this – Why Django and Rails CMS Are So Rare November 29, 2012
Django and Rails are notably absent from the boxed CMS space. There are specific reasons why, and -- in a larger sense -- why platforms with strong frameworks tend to limit this growth.