Ruby on Rails, and the Rails Beta Book

Fri

Jun 10
2005

listen

Ruby on Rails, and the Rails Beta Book

I've been reading Agile Web Development with Rails, and it's a great book, as well as a great structure, the "Beta Book" program from the Pragmatic Programmers, for providing early access to books. Rails (for the most part) feels like the future of Web application development, and the Beta Book feels like the future of book publishing.

Some engineering shops have what is known as a "tools developer" -- the person who goes around finding the repetitive tasks endemic to software development, and who develops code to automate those tasks. It can be a good job, but often the tools developer either becomes the department janitor, cleaning up other people's messes, or they get sucked into some "high priority" project and lose the purity of the original role. But when a tools developer excels, you see common tasks factored out of your day. You do something three times, and suddenly some new code appears so you don't have to do it anymore.

Rails feels a bit like the best tools developer in the world automated all the stuff you haven't even had to hit once yet. As you reach to do it the first time, you'll find the framework steering you to do it the easy way. I love that. The "convention over configuration" idiom is very worthwhile, and I'd love to see more frameworks use it.

I'd learned Ruby a while ago, back when the first PickAxe book came out, and I was impressed with it. A detour into Groovy made me appreciate Ruby still more. My friend Nelson, a Python fan, was joking with me about the funny characters Ruby puts at the front of each line -- @, @@, and so on. "Python does, too!" I replied, "but its funny character is a tab!" Don't shy away from Rails because of Ruby; it's a worthwhile language to know, and I find it far more usable and consistent than Python.

The one area of Rails that grates, for me, is the inclusion of code directly in the HTML templates. Of course, Rails is not alone in this at all, and many successful frameworks do just the same thing. I've written at length about my complaints with this approach (yes, I am the number one hit if you type 'jsp sucks' into Google -- thank you, thank you), so after reading many pages of beautifully-short code examples, hitting the HTML template on page 61 of the Rails book felt like slipping on a banana peel. What happened to the elegence?

David (the author of Rails) has written about this at length in the past. What he says in the book -- that MVC frameworks used ~~business logic~~ active code in the view from the beginning -- isn't very compelling; his blog post is much more persuasive, but still I am unconvinced. Nonetheless, I'm going to try to drink his kool-aid dry, and see if another try, and a try using Ruby instead of the languages I've used in the past, changes my mind. David did too many other things right for me to question this decision without a good, up-to-date run at the way he suggests doing it. In the back of my mind is a method for adopting "convention over configuration" into HTML templates -- hopefully a better proposal than the one in my "JSP sucks" article -- and if I still hate .rhtml a few weeks in, I may clamor for it.

If you haven't already, check out Rails, and definitely check out the Beta Book program from the PragProg guys. That's the way you'll get technical books in the future, I suspect, and you might as well start writing web apps from the future now, too.

UPDATE: Several people have pointed out that there are a few splinter groups trying to take "convention over configuation" to the template. If you're interested, check out:

None of these are quite what I had in mind, but they're all close, and I wonder if one of them would make a good option for Rails.

I'm still planning to go the default Rails way for now and see if I've just talked myself into my ideas on this topic, rather than actually being right!

UPDATE 2: Please see my comment about HTML developers in response to Andrew's comment, below. I think people assume I'm saying "Photoshoppers can't grok code, we must save them," and, well, that's not my point at all.

tags: | comments: 15 | Sphere It
submit:

Previous | Next

0 TrackBacks

TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/4105

Comments: 15

Jon Evans [06.10.05 06:47 AM]

It's not a case of putting business logic in the view - that's still wrong. Think of it as "view code" - the controller typically hands the view a set of model objects to render, and the view needs to call methods on those objects to render them as HTML (or whatever). So, it will iterate over a collection of Articles for example, and display a link to each. That's not business logic.

Andrew [06.10.05 08:27 AM]

The code-in-HTML issue is a valid complaint. There's absolutely the dangerous potential--described really well in the linked "Why JSP Sucks so Hard" article--of putting too much logic into your view templates.

One of the appealing things about Rails, and a huge difference between it and other frameworks I've seen, is that it assumes the designer is not dumb. David's commented before that "frameworks are extracted, not designed." Rails was "extracted" from working with the designers at 37Signals--by anyone's measure a group of skillful front-end developers. If yase your framework on working with smart, capable HTML coders and there's no reason to assume that they'll gum up the view code with inappropriate stuff.

Often, the complaints about code-in-the-HTML come from people who say, well, I'm working with pixel-pusher Photoshop jockeys who let wysiwyg editors write their HTML. I'd say Rails is the wrong choice for those situations. In your 'JSP Sucks' article you write: "[once the JSP is added] the HTML author will have absolutely no clue what the page does any more, and will have no desire or ability to edit it." I say: that's crap. The base expectations for HTML coders have evolved since 2002. If you're working with a UI developer who can't read and write basic view scripting logic, or at least understand it and work around it, you need to find a more capable UI developer.

Andrew [06.10.05 08:29 AM]

The last sentence of the 2nd paragraph should read: "If you base your framework on working with smart, capable HTML coders and there's no reason to assume that they'll gum up the view code with inappropriate stuff."

Marc Hedlund [06.10.05 09:15 AM]

Jon, you're right -- the Rails book says, "views contained active code even in the original MVC archtiectures." I'll make a correction.

Andrew, what I said about interactions with HTML developers and designers were some of the most contentious parts of the "JSP sucks" article, and I agree that you shouldn't treat HTMLers as though they can't cope with complexity. Of course, given HTML itself, CSS, JavaScript, DHTML, and everything else that gets piled into the HTML file, they deal with complexity, and code in templates, all the time.

My point was that I was seeing a bad process when a site went from design to dynamism. Java, and JSP, were very serious contributing factors to the bad process I saw. First, JSP agressively screws up many HTML editing tools (with nested angle brackets and so on). Second, once JSP tags are added to a page, the only way to view those pages while editing them was (at the time, at least) to have a running servlet container that you're willing to restart between certain kinds of edits. Third, very minor errors on the HTMLer's (or designer's, or whatever) part would cause the page to crash completely, unlike what happens when a typical, minor JavaScript, DHTML, or CSS error makes it into the page.

All of this led to a bad set of steps for changes once the HTML code went into production. Sometimes an HTMLer would go back and change the template as it was before the JSP snuck into it, and preview the changes there before shipping it off, effectively maintaining parallel code lines. Sometimes they would spend a couple of days learning how to get Tomcat working with whatever editing tool they were using, and then having to keep up with changes to the Tomcat environment (new jars, etc.) to keep the ability to preview their changes. Sometimes they would wind up pair programming with an engineer -- not the worst thing, but in my mind not ideal, either.

My point was that there should be a better way. Maybe the better way, as David argues, is to use Ruby in place of Java, since the weight of the code on the template is lighter. Maybe there's more we could do. You can say that someone is perfectly smart and capable of using whatever tools we require, and able to work around template code they don't understand, and still feel that it would be better to make the burden on them less onerous.

Let me put it another way. In my interview with Jason Fried, David's business partner, Jason argues for giving developers a choice in the tools they use:

The way I look at it is this: I want developers to be comfortable with their development environment. I'm a designer and a business guy, not a developer. I'm not going to push PHP or Java or whatever just because I've heard of it. I'm going to defer to David on this. And if David chooses Ruby, then Ruby it is. [...] Why would you dare impact your developer's morale by throwing him or her into a language where he can't be as productive or as satisfied? You only get good work from people who enjoy doing the work. I'll take a happy average programmer over a disgruntled, frustrated master programmer any day.

If you look at the JSP development environment, as I describe it above, and think about the impact on a full-time HTML developer, do you think you are going to get a happy developer who feels comfortable and satisfied with their development environment? JSP in particular, and templating languages in general, make many smart, talented, capable, intelligent HTML developers and designers I know miserable. These systems prevent them from using certain tools they know and love, and force them into an editing and QA process they can understand but don't like. And the workarounds, from my point of view as a manager, are often terrible -- as I said in the JSP post, they are akin to a compiler that tears up your source when you compile.

I think it should be possible to make a system that allows the code developers and the HTML developers to both have setups they like, from initial design, to testing, to production, to internationalization, to maintenance. I don't think that's a condescending view towards the capabilities of HTML developers. Instead, I think it is a respectful view.

Simon Willison [06.10.05 09:20 AM]

A quick note before the bulk of this comment: one of the nice things about Rails is that setting up a "development environment" is as easy as installing rails, grabbing the latest code for an application and running script/server - a far cry from having to install TomCat and configure a servlet environment.

The following is copied from an e-mail; I read this blog through RSS so I hadn't realised comments were enabled.

Hi Marc,

I've been on both sides of the template issue you mention in your Radar entry about Ruby on Rails - I've even written my own template engine once or twice - and I've been really enjoying the way Rails does it. The point of MVC is to have the presentation logic (the view) separated from the model and controller, and Rails achieves this admirably. Of course, it's up to the programmer to be disciplined in not adding application logic to their templates but the whole of Rails and Rails culture is set up to encourage them to keep things separate.

Ian Bicking makes an excellent point about presentation logic here:

http://blog.ianbicking.org/smart-vs-dumb-templates.html

"""
There's lots of other layout issues. Many pages render improperly when the content is too short, or has long lines, and so on. And these are problems just for rendering relatively static material, as opposed to interactive web applications.
...

Things become even worse if you are dealing with an interactive web application. A web UI is a subtle thing, and prone to overall suckiness. (It is ironic that I am a web programmer, yet I rather dislike web interfaces) "Layout" and "display" become very complicated -- if you are writing your UI well! A simple display gives people only small snippets of information at a time, leads to low-content interstitial pages, forces information traversal instead of nested display, and lacks helpful or predictive direction. A good UI involves all sorts of little rules, exceptions, warnings, qualified feedback and compound screens. Wimpy template languages are not up to the job. Though you might ask: are any template langauges up to the job?

"""

In my experience, the more you evolve a templating language the more it starts to look like a "real" language. Look at PHP's Smarty, or Python's Cheetah for example - both have evolved to the point now where they are pretty much Turing complete, and in fact you end up asking developers to learn /two/ languages.

Contrast this to the way Ruby on Rails handles templating logic. In essence, it /does/ have a templating language - it just so happens that this language is Ruby as well. What's really smart is that Rails makes use of Ruby's syntactic flexibility to create a domain specific language (or mini language) adapted to the needs of templates. Built in functions are provided like h() (for HTML escaping) and linkify() (for auto-marking-up links). Because Ruby lets you omit parentheses, you end up with template code looking like this:

All of the above said, I've just read your piece on Why JSP sucks and your arguments there mostly apply to the way Rails does it - they're universal to pretty much every template language I've ever encountered. In my limited experience HTML authors are far less scared of templates than you give them credit for, but then I've only every worked with hand-coders so I don't know if the same is true for Dreamweaver users.

Incidentally, I've seen systems that work in the way you describe in the article (template markup contains only class and ID attributes, the underlying code then modifies the pages) and I've found them to be far too brittle. Firstly, changes to the templates frequently require changes to the calling code as the underlying code has to make many assumptions about the structure of the HTML it is meant to modify. Secondly, they don't work well with presentation logic more complex than "replace X with this" or "repeat Y over this set" - simple things like "1 dog" v.s. "2 dogs" have to be handled by the code that drives the templates rather than being placed in the templates themselves. It all comes back to Ian Bicking's point that presentation logic can be a lot more complicated than most people give it credit for.

At the end of the day though, "> seems a lot more confusing than something like HTML involving in Rails.

This ended up being longer than I expected! I hope it encourages you to give the Rails approach a second chance. And of course, if you really don't like it Rails is designed to let you swap in your own templating/presentation layer solution. You may be interested in Amrita2, which is similar to the system you describe (although in my opinion it suffers from horrible coupling between code and template:

http://amrita2.rubyforge.org/

It can be easily added to Ruby on Rails:

http://one.textdrive.com/pipermail/rails/2005-February/003322.html

Cheers,

Simon Willison

http://simon.incutio.com/

Monty Zukowski [06.10.05 11:29 AM]

Terence Parr analyzed templating engines according to formal language semantics, applying grammar theory to generation instead of recognition.

http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

And of course he did it to encourage people to use his StringTemplate code http://stringtemplate.org. You might find his arguments useful, at least for quantifying the danger present in a particular templating engine based on its features.

Marc Hedlund [06.10.05 11:33 AM]

Thanks, Monty, that paper looks well worth reading.

Scott T. [06.10.05 11:39 AM]

Hey Simon, could you repost your code snippets so they don't get stripped out by the comment handler?

Keith [06.10.05 01:33 PM]

I've found that XMLC (why?) cleanly separates my Java code from the HTML. XMLC turns HTML into Java classes that implement the DOM structure and allow me to manipulate pretty much anything through Java. You provide ID attributes to interesting DOM elements and then you can set, clone, or delete them as desired before rendering the page. You can happily use Struts and replace the JSPs with XMLC.

Simon Willison [06.13.05 01:34 AM]

Scott T: the sentences were:

Because Ruby lets you omit parentheses, you end up with template code looking like this:

<%=h @title %>

And:

At the end of the day though, <exec:iterator condition="<%= shopBean.validate() %>"> seems a lot more confusing than something like <% for item in @items %>HTML involving <%= item.title %><% end %> in Rails.

Justin Palmer [06.13.05 02:40 PM]

As a designer, I see absolutely no need for a template language. I have written about this in detail here: http://www.encytemedia.com/article/14/designers