This post originated from an RSS feed registered with Ruby Buzz by David Heinemeier Hansson. Original Post: Serving the koolaid with the facts Feed Title: Loud Thinking Feed URL: http://feeds.feedburner.com/LoudThinking Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp Latest Ruby Buzz Posts Latest Ruby Buzz Posts by David Heinemeier Hansson Latest Posts From Loud Thinking

After the last salvo of Java fire, I considered it best let the gun cool off for a while before giving it another round. But it's just so darn hard when my newsreader is flooded with misinformation, shallow intentions, and the smell of fear.

Let me start in good manners by offering up some self-deprecation. It has been a mistake to power-push scaffolding through movies and tutorials without following up with the story of how Rails is actually used by people building real-life applications. I acknowledge that while it has brought plenty of wow-factor attention, it would leave the recipients — who only got that message — with an easy path to draw distorted conclusions.

The fact is that scaffolding plays a very small role for anything more than getting people interested, teaching them the first baby steps about doing CRUDs in Rails, and possibly, remotely for doing non-important admin stuff. It was hacked together in a single afternoon as a spur of the moment thing after I had remembered about naked objects and just wanted to take a quick stab at shallow auto-wiring. The main driver for scaffolding is a mere 100 lines of Ruby code!

Why code and HTML gel in Ruby and not in Java
Suffice it to say, I'm disappointed, but certainly not without blame, when I see the simplicity of scaffolding being used as a straw man to convict Rails. I'm equally disappointed, but at some level understanding, when Java programmers apply the misfortunes of their own environment to ramp up the indictments. Dave Geary has this bit:

It's nice to get you up and running, and great for seductive demos and articles, but you're going to override at least 100% of the views that ROR generates. And therein lies the rub... because views in ROR are a mixture of HTML and Ruby scriplets! We've been there before, of course, in the early days of JSP with HTML mixed with Java scriptlets. No thanks, I'll pass on that giant step backwards.

Let's examine the origins of one of that charge — the mixture of Ruby and HTML being a bad idea — and I'll explain why its misguided.

In Java with JSP, it's incredibly tempting to allow your view logic to deteriorate through responsibility creep (overloading them with business or mere complex logic) that leads to a rapid rot. Back in 2001, I worked on a J2EE system fraught with rot of this kind. I can perfectly understand the fear of such decay can instill in any developer.

There are many reasons that things turn from bad to worse with JSP. Allow me to list just three:

• JSPs are normally auto-compiling: Unlike the controllers and models, you can make a change, then see it work. In other words, you can circumvent the drudgery of letting the Ant loose to recompile the half or all of the system and redeploying it in the container. Hence, JSPs serve as a constant and appealing temptation to do the bad thing to get the job done.
• Extracting complex view logic is painful: With tag libraries, it's possible to be a good programmer and rid the views of complex logic by extracting code and replace it by tags. That is a noble and right path to follow. The problem is when the effort required to do the right thing is so intense that its basically a project in itself. Then its not something you're gently invited to do. It's a huge barrier and easy source of procrastination ("I'll extract later...") and guilt ("If only I had extracted sooner...").
• Java is a terribly view logic language: I talked at length about this subject in The false promise of template languages and I doubt there's any disagreement here, so I'll leave it at that.

Let's contrast this to the situation with Ruby on Rails:

• All layers are "auto-compiling": There's no compilation penalty for placing code in the controller or model in Rails. All changes are instant! This creates an environment of equal opportunity where code can be placed in the appropriate level right away. In fact, it is often less inconvenient to place code in the views than in a helper or in the model because you have to integrate it with the HTML instead of just making another method. Temptation to do bad has been replaced with convenience to do good.
• Extracting view logic into helpers is easy: As I was riffing on in the rant about template languages, view logic is not a bad thing. It just needs to be managed through extraction of commonalities and complexity. Exactly how easy it is in Rails is hard to explain in words, so I made a little video to do it on its behalf (I'm just working with scaffolded code here, perpetrating the original crime, I know).
• Ruby is an excellent view logic language: Ruby is incredibly succinct and imminently suited to do view logic where conditionals and loops are mixed and matched with HTML. Allow me to demonstrate with another example.

But it gets even better. You don't have to mix Ruby and HTML, if that doesn't cook your noodle! Rails provides a fully programmable alternative using Jim Weirich's excellent Builder class. It's very cool and I use it in all the places where I don't collaborate with designers (where HTML is a nice common language). An example is the Builder-template for the RSS feed in Ta-da List.

So with the addressing of Dave Geary's hasty conclusion that "But [Rails] seems to me that once both apps are up and running, ROR is no match for a Java-based web app six pack of JSF-Shale-Tiles-SiteMesh-Hibernate-Spring" purely on the basis of "implementing my own views in ROR looks mighty ugly to me", let's move onto to the even more depressing perception of Rails held by Trails creator Chris Nelson.

'This seems to totally preclude having a rich domain model'
Trails is a can of glue for binding existing Java frameworks like Spring, Tapestry, and Hibernate together into what Chris calls "...a domain driven development framework in the spirit of Ruby on Rails or Naked Objects". Seeing he even got the casing right on RoR, you should think that he spent an equal amount of time understanding the very spirit he's attempting to clone. He echoes the charges from Dave Geary's post on scaffolding and Ruby in HTML (apparently equally ignorant of the issues outlined above), which we won't bother with again, but also adds a third to the mix:

First, domain classes in Rails have to extend ActiveRecord::Base. At first I didn‘t get how big an issue this is, as I assumed Ruby had multiple inheritance or something similar. But having delved into a bit, I‘ve learned that it does not. This seems to totally preclude having a rich domain model. That‘s a compromise I wouldn‘t be willing to live with. It seems like maybe this could be easily done in a different way (with mixins maybe), so let‘s hope Rails makes an improvement here. Since Trails uses Hibernate to persist POJOS, that just isn‘t an issue here.

(My emphasis). Reading that gave me one of those woah experiences. Let me try to give my understanding of what the above means and then address it (then Chris can perhaps correct my understanding): Because Rails already used the first step of inheritance, you can't use inheritance for your own domain model. This is of course not true.

In addition to regular inheritance, Active Record supports single-table inheritance that can give you hiearchies like:

class Company < ActiveRecord::Base; end
class Firm < Company; end
class Client < Company; end
class PriorityClient < Client; end

Additionally, Active Record supports a very flexible and powerful set of associations for describing relationships between classes:

class Project < ActiveRecord::Base
  belongs_to              :portfolio
  has_one                 :project_manager
  has_many                :milestones
  has_and_belongs_to_many :categories
end

Hence, it addresses both of the short-comings of the original Active Record pattern as described by Martin Fowler while making it incredibly easy to create rich domain models without the overhead of XML sit-ups to describe the mapping.

True, Hibernate can certainly handle more edge cases and legacy database integration jobs, but to state that "This seems to totally preclude having a rich domain model" is one of the most ignorant statements I've ever read about Rails. And its baffling that it comes from a guy that claims to be interested enough in Rails to attempt to recreate the spirit in a Java package.

Jumping back to Geary for a moment, I'd like to ask him to reconsider just how big a Dave Thomas fan he really is (he states "I'm a big Dave Thomas fan"). You obviously don't have very much respect for Dave's sense of judgement, if you think he would be excited enough about Rails to talk about it in front of Amazon and at the Java No Fluff conferences, not to mention that he's write a whole book about Rails!, just because of a little scaffolding.

So please, both of you. Don't be a stereotype. Dislike Rails for all sorts of reasons based on more than a shallow look and a quick dismissal. Talk about how it has no major vendors behind it to make your enterprise feel secure, how static typing makes you all warm and fuzzy, what terrible life would be without IDEA, or how you need to integrate with crazy legacy schemas all day long that Active Record can't handle. There are plenty of enterprisy reasons to diss Rails. Using scaffolding or Ruby in HTML as straw men are not.

To everyone else spectating this with curiosity: Unless you've already been turned off by Rails with my inability to let any negative Rails mentioning on the web slide me by without a big fuzz (and I forgive you if you are), I recommend that you have a look at some Rails code that isn't about scaffolding. Tobias Lutke has some great Subversion repositories available online for the minimalistic weblog-engine Typo and for the book collaboration project Hieraki. And there are move available at documentation.rubyonrails.com.

Even better, download Rails. It's really easy to get started. We include just about everything in the box and there's always somewhere between 150 and 200 people available in #rubyonrails on Freenode to help you get started.