Code Generation: The Real Lesson of Rails

This article, Code Generation: The Real Lesson of Rails, sums up some of the thoughts I’ve had over the past few days of investigating Ruby on Rails.

It isn’t that Ruby is a better programming language than any other (though it is nice) or that Rails is a better framework.

It’s that Rails is as much, or more, about code generation than it is about just “being a framework.

I spent a while working with Fusebox while I was coding Coldfusion a couple years back. When I think of a “framework”, Fusebox is what comes to mind. Fusebox is a nice paradigm for building applications. Like Rails (and like possible most or all web application frameworks), Fusebox uses the Model-View-Controller design pattern (hereafter, MVC). It has some nifty xml files, some pre-built CFML, and some handy suggestions for organizing your code. It’s a framework, and if you want to work with Coldfusion, I still think it’s a pretty good one.

Having this in mind, I think simply calling Rails a “framework” is selling it a little short.

Rails is a framework, sure, but it’s also a set of command-line scripts that will generate code for you. Potentially, lots of code. Code that works.

Again, as a disclaimer, I’m not at all saying that Rails is the be-all-end-all of web development, nor that the other languages and frameworks don’t have something great to offer. I’m looking forward to checking many others out, in time.

In the meantime, I have to say: Rails is awesome.

2 Responses to “Code Generation: The Real Lesson of Rails”


  1. 1 John

    Congratulations on discovering Rails. I went down a similar path of thinking immediately after discovering Rails (”wow, look at all the code it can generate for you, etc”) but the great part is that you are just discovering the tip of the iceberg. There are a plethora of other features (e.g. routes, RJS, layouts, ActionMailer, etc) and characteristics of Rails (e.g. convention over configuration, DRY, an “if it’s a common task, build it into the framework” attitude, etc) that together all provide an amazing productivity boost.

    I’ve been using Rails for quite a while now and on an almost daily basis I still have the experience of pondering some new task and thinking that perhaps this will be the first thing I need to do that winds up being hard to do in rails… and then discovering that like everything else, rails makes this new task easy as well.

  2. 2 Phil Crissman

    Thanks, John. I’m looking forward to discovering more about Rails as I go.

    I’m actually just using it (so far) for a project in a Software Design class I’m taking. The class is emphasizing agile, iterative design processes, so Rails seems particularly well-suited. I’m sure as I dig in, I’ll find a whole lot of new stuff.

    My only concern is how much of the application I may have working — since the class is just one semester long, it is focusing on what would be the first three iterations in a typical Unified Process software project. In other words, it’s expected that we’ll only have about 20% of the application coded by the end of the semester.

    If things keep going the way they are, I may have too much application coded at the end of the semester. ;)

Comments are currently closed.