Sho Fukamachi Online

So I’ve been watching the RailsCasts episodes going through the latest features in Rails 2. I’ve read about them before – but it’s good to see them demonstrated by an expert.

But man – some of this is too much. Don’t get me wrong, I like magic – if I didn’t like magical free stuff I wouldn’t be using Rails at all. But there comes a point where there’s enough magic, and more just trades off too much for too little – diminishing returns, as it’s called.

Take this screencast: Simplify Views with Rails 2.0. It shows very clearly what I’m talking about.

Now some of this is good shit. The ability to write this:

<% div_for_product do %> # is this supposed to be <%= ?
<% end %>

And have it automatically generate div IDs and the like is great. That saves some nasty looking code – assuming it works properly, stays unique across multiple includes, etc. Good shit. A worthwhile addition.

But this:

# from
<%= render :partial => 'product', :collection =>  %>
# to
<%= render :partial =>  %>
# and for a single case
<%= render :partial =>  %>

I think this is bad news. Suppposedly Rails is going to look inside that instance variable, decide whether it’s an object or an array, and automatically use the correct partial, multiple times if it’s an array .. why? To save what, 15 keystrokes?

I would argue the “Rails 1.2″ way of doing this is about the most concise way to write this function imaginable while still maintaining decent at-a-glance understandability. It’s not so long and unweildy, is it? And you can see what’s happening instantly – ok, now render a bunch of partials named ‘this’ using whatever was in this . The word “collection” is a nice touch which helps you remember there’s a number of them.

The second one? Its behaviour literally changes according to what’s in that instance variable. Is it really that much nicer to look at that it’s worth losing the information necessary to see, at a glance and unambiguously, what it’s doing?

There’s more, and worse: forms, where we go from this

<% form_for :product, :url => product_path(), :html => {:method => 'put'} do |f| %>

to

<% form_for  do |f| %>

And if you’ve used the strict Rails conventions, mapped all your resources in routes.rb, are using the strict controller layout as demonstrated in the resources scaffold generator and have a picture of DHH as your desktop background, it’ll know what to do and work.

Now, at this point you might be saying “but you don’t have to use these features – it’s only if you follow the convention, which is the whole point of Rails! Follow the convention, get free benefits – it’s been like that since day 1″!

I agree with that, kind of. But there is such a thing as too much convention, and too many limits, and – this one’s my point – too much “magic”. I know it’s a bit silly to talk about “vendor lock-in” in the context of a Rails project but following “The Rails Way” is beginning to smell strangely similar. And these extraordinary efforts to save a few keystrokes, ONCE, at the expense of readability (and no doubt speed!) are beginning to seem less like cleverness and more like Koolaid-driven idealogy.

We’ve been told, again and again, that it’s all about “Beautiful Code”. And you know, I appreciate that up to a point. But when the code is getting less readable and more dependent on arbitrary chains of “convention dependence” which may or may not work (and which may or may not change in 3.0!!) then I start getting cold feet.

You know what? I’m working on *a* web site, not *the* web site like these changes all seemed designed for.

Predictions of a coming fork, anyone? “Rails Lite”?

Oh, and despite the endless hours which must have been poured into this kind of useless bloat, YAML handling in rails is still UTF8-unsafe.

UPDATE: Sure, you can just not use these features. But the codebase bloats, the execution speed is slower – and it’s not like it was fast to begin with. I argue these new features make the code more difficult to read and learn – hurting the Rails community as a whole, reducing numbers of developers, marginalising the framework – as someone with a considerable investment in that framework I am a stakeholder in Rails, and it’s from that position I comment.