A couple of years ago,
DHH's fifteen-minute blog
screencast introduced
Rails to the world. This wonder was accomplished in no small part because of Rails' scaffolding - code and markup generated by the framework to handle the most common tasks.
Since that debut, scaffolding in Rails has changed substantially. Dynamic scaffolding (where the generated code lived in memory instead of on the file system), for instance, was pulled out of the core framework a year ago, while static scaffolding (where actual files are created) was updated to reflect the
RESTful principles that the community as a whole has been moving towards. Even while the core team made these changes, however, a tension over the
goals of scaffolding has emerged.
Cross-Purposes
So what are these goals? Well, on one side, there's the production-ready faction. These people want scaffolding to resemble
Django's admin interface, where it's ready to support a live site out of the box. When they are (inevitably) let down, they opt for or create alternatives like
Streamlined and
ActiveScaffold. On the other side, you've got the educational faction. Proponents of this want scaffolding to teach new developers best practices for writing Rails code. They're apt to be big fans of documentation and tutorials, as well, and to be the right people to turn to if you want to know the
why of something - like why RESTful controllers have seven actions. As it turns out, production-ready code, even when it
follows best practices, is often not the best way to
learn those practices. The problem is that the best practices the educational faction wants to instill underdetermine production code - any application capable of supporting a live site is likely to optimize things, move things around, and in general obscure much of its implementation of best practices behind structures that make it
better at supporting a live site (and often easier to maintain).
A Modest Proposal
Given all that, here's a suggestion: separate the two goals. Abandon the idea that scaffolding can or should be both useful and educational, and rip out everything that detracts from one or the other purpose. My suggestion (for what it's worth) is to ensure that scaffolded code is in fact production-ready, and is solid for the basic case. This doesn't mean that we completely abandon the educational aspect, however. Instead, we should create a sample application expressly tailored to helping new Rails developers learn how best to write their code. It could be distributed via gem or plugin (with a generator or as a
resourceful plugin), but it should be separate from Rails core, and easy to find and install. In the end, clarifying a single purpose for scaffolding will better serve both factions, and the community as a whole. (photo from
joelogon on Flickr)
