“WTH is happening to Rails?” I’ll tell you.

I just read the blog post that got some traction on HN last night, entitled “What the hell is happening to rails?” It goes on to list a litany of complaints against changes in Rails 3.x, ranging from the default commenting of the catch-all route to, yes, of course, CoffeeScript. They all end up sounding a lot like “I don’t like change,” an argument we’ve all heard before. The difference is that Steve Coast, the post’s author, casts himself in the role of a crusader for the newbies. He says that he, personally, “gets” why these changes were made, but that the most recent versions of Rails are actually harder to learn than the older ones were. The post highlighted two things, to me:

1. Some people still miss the point of Ruby on Rails, even after all these years.
2. There’s a difference between “easy to learn” and “easy to use,” and when these competing goals butt heads, the latter should always win out.

Conventions necessitate opinions

We often say that Rails is an opinionated framework. It chooses sides. It has an opinion about what format our view templates should be in (ERb), what testing framework we should use (Test::Unit), and what Javascript DOM manipulation library we should use (Protoype. No, wait! jQuery! What were we smoking?). It has opinions about where we should put our application’s files and logs, what settings we will want to enable and disable for different application environments, and so on.

This is all good. Rails makes a reasonably sane default choice for us and saves us from making our own decisions until we actually care enough about some aspect of our application to form an opinion of our own. It makes changing our decision possible, and often simple. We enjoy these benefits stemming from the principle of convention over configuration, and it would seem that some of us forget that for a convention to exist, someone (an individual or collective someone) must decide that one way of doing things is better than another.

The “right way” to do things

Steve points out:

The barrier to entry to learning rails if you came from something like PHP used to be pretty high. You had to get your head around MVC, the quirks and so on. But it was doable.

It reminds me of a discussion I had a while back. An developer with plenty of experience in PHP and other languages was complaining that he didn’t like working with Ruby, nor Rails, because there seemed to be the notion that there was generally a “right” or “accepted” way to do things in these communities.

This really floored me. Mostly because:

• If you’re learning a new language, a strong community consensus about a right and a wrong way to tackle problems aids learning. It increases the likelihood that you’ll pick up good habits from the community as you learn. Even in cases that are more ambiguous, a community passion for doing things the right way means that there will be ample debate about what the right way is, for the newbie to digest and form his or her own opinion.
• In most cases — for mere humans, anyway — there really is a right way to do things. Ruby is an Object Oriented programming language. There are literally decades of prior research in the field of OO software design, and they’ve resulted in a lot of really well-documented and well-tested design patterns for building software. While it may be possible that the design you’ve build for your application really is far better than the designs of those who’ve gone before, you’ll have to forgive us if we’re skeptical at first.

In any case, when you’re learning to write Ruby on Rails code, you’re not just learning a language or a framework, and a developer’s arbitrary API design decisions. You’re also learning the fundamentals and benefits of solid object-oriented software engineering, through practical implementation. You’re employing a well-respected pattern for separation of concerns (MVC) as you write your models, views, and controllers. You’re using an implementation of the Active Record pattern (you didn’t think ActiveRecord was only the name of a library, did you?) as you interact with the data in your RDBMS. You’re learning about polymorphism and composition and a ton of other OO principles as well, just by doing the research required to write your first Rails application.

And, hopefully, you’re learning the value gained from having so many of these routine engineering decisions already made and already implemented.

Fighting the framework

The great thing about working with opinionated software like Rails is that it can help guide you as you build your application, and as a result, your application will benefit.

When I teach an Introduction to Rails class, one of the first things I tell students is to pay attention to what the framework is telling them. If, while coding something, it seems as though things are much harder than they need to be, it’s very likely that they’re “fighting the framework,” and they should double-check their assumptions to ensure that:

1. What they’re doing is a good idea, and
2. There isn’t actually a more straightforward way to do it, already provided or encouraged by Rails

Nine times out of ten, for a newbie, they’ll find that they missed some part of Rails functionality that already solved this problem for them, or that their idea wasn’t following a solid OO design principle to begin with, and should be rethought. You have to know why the rules are there before you start breaking them.

The answer

The complaints that Steve raises in his post are nothing new. They’re simply a continuation of the same thing that Rails has always done — eliminating repetition, solving problems common to most web applications, and generally making the framework easier and more pleasant to use.

Steve says:

Rails is busy optimizing for the anal superior coder who wants to learn things for the sake of learning things, which is neat and cool but not worth it if you just want to make a website.

I wouldn’t have it any other way. If, as coders, we aren’t constantly striving to improve the status quo, what’s the point?

The only people who will suffer from this continuing effort are those who need to unlearn bad habits. As for the true newbies? At least they’ll be learning how to build software the right way, and they’ll take away lessons that they can reuse no matter what language or framework they end up using next.

So…

Q. “What the hell is happening to Rails?”
A. It’s growing up.