Why I Like Ruby On Rails

I've been working with Ruby on Rails for a little over a year now. Somewhat to my own surprise, I still like working with it. Much of the time it's downright fun.

Over the past year, it also seems that the hype around RoR has grown quite a bit. Or at least it's spread, since it's started reaching people like my boss. I don't really know what the hype usually says, but I thought that I'd try to write about what I like about it.

When I recommended Rails (again) to sugoll yesterday, he said the he'd had a brief look and that it didn't look like anything special. He's absolutely right in that. It doesn't. Rails doesn't really do anything that most other frameworks don't do as well. Sure, there are a few places where it's at or near the front line of development, like in ease of AJAX development or in database agnosticism. But those are really just perks. What sets Rails apart is a matter of philosophy.

Opinionated Software

Rails has opinions. Rails wants you to do things its way.

At this moment I can hear a lot of the experienced developers and sysadmins out there go "Yeah, right, I've known and hated abominations like that!". So have I, in my sysadmin days. But those systems didn't really have opinions. They just had a fixed set-in-stone view of reality, and fuck you if your reality doesn't match. Rails, on the other hand, actually has opinions. You can change its mind. You just need a good enough reason.

There are three big advantages of Rails' opinions. The first is that there are a lot of decisions you don't need to make. This, in my experience, saves surprisingly much time. You don't need to choose a file layout, an ORM layer, a templating system and all that. Unless you have a reason to want a particular one of those, it's easiest to just go with the one Rails wants. Which leads to the other big advantage: when you look at someone else's Rails app, you almost certainly already know how it's laid out, how it hangs together and where to look in order to find the interesting stuff. Modifying a Rails app for your own purposes is amazingly much easier than any other code I've ever tried it with.

The third big advantage of the opinions is that they're actually really good. They've been tested by thousands of people for thousands of different purposes. They work. If you don't know that you need to do things a particular way for a particular reason, you can rely on the Rails way to not be a bad choice.

A Mutable World

The people behind Rails are great fans of so-called "Agile Development". This means that the Rails worldview is heavily slanted towards one where change is constant and rapid. At least where I work, that view is a lot closer to reality than the view where change comes in large periodically released lumps. Being able to introduce and change functionality quickly and reliably makes it much easier for us to react to unexpected changes in the world around us. And that reaction speed translates quite quickly into money, for an online-based company.

Of course, most web application frameworks make it easy to change stuff. A large part of that is just having all the code running on your own servers, instead of distributed to a gazillion client machines all over the world. Where I think Rails shines is that in being actively designed with rapid change in mind, it makes it fairly easy to avoid the "insane patchwork effect". I don't think there's a single line of code in my main work app that hasn't been changed at least once, and some parts that have been rewritten upwards of a dozen times -- but it's still all coherent and well organized. Which is way more than I can say for the mod_perl/Mason thing that runs my private site. And it hasn't taken any real effort to keep it coherent, either. It falls out naturally from following Rails' opinions.

Well, ok, there's one thing that Rails doesn't do enough to force you to do. Write tests. Really. If you've ever had to put new code into production at two minutes to five on a Friday afternoon, you'll probably be able to appreciate how extremely nice it can be to actually know that the code works as intended, and that it doesn't break anything else. Yes, it takes some time and effort to write the tests, but it's so worth it.

Extraction

One of the main guiding principles behind the development of the Rails framework is that of extraction. Which simply means that all the functionality in RoR is extracted from instances of actual live use. There aren't supposed to be any features at all that haven't already proven their worth before they were included. In practice, this turns out to mean that Rails is very good at doing what you actually need it to do, rather than what some developer at some point imagined that you might need done. This makes the development experience remarkably smooth. A lot of the time, things just work. Quite a few times, features that I thought would be a lot of work to implement turned out to only need a handful of lines of code, because the basic need behind the feature was fairly common and support for it had been extracted from some other app into Rails long ago.

As of the currently recommended version of Rails, there still are a few features that are not extractions, but additions of the far more common "We think this would be a neat thing to have" methodology. These features are in the process of being taken out and shot deprecated.

Comparison

The only other framework I can honestly compare Rails to is mod_perl and HTML::Mason. Which is slightly unfair, because unlike Rails Mason does not try to be a full-stack webapp framework. But, on the other hand, Rails doesn't have the tens of thousands of modules on CPAN to draw on, so it's not like Mason has a lack of features compared to Rails. Quite the opposite. There are many, many things that you can do easier in Mason than in Rails by using a few well chosen CPAN modules. And, of course, in general neither Rails nor anything else web-oriented is doing anything that some crotchety old bastard couldn't do with 32767 lines of self-modifying awk back in 1963. But on the whole...

I started doing Perl back in 1990. I built my first Mason-backed web site in 1998 or thereabouts. I have modules on CPAN. I know Perl and Mason really well, and I have used them a lot.

I first looked at Ruby about 18 months ago. I started building my first Ruby on Rails site not much more than a year ago.

And even the first week I was using Rails, while I was still very actively learning both the programming language and the framework, I was about an order of magnitude more productive than I'd ever been with Mason.

Now, I've not been a professional developer for very long. Less than two years, actually. So maybe what I've said here is old hat to those of you have been pros for decades, and you all already use frameworks that do all the things I like about Rails. But I've seen a heck of a lot of code over the past quarter century, and I very much doubt that that is the case. So until someone tells me in reasonable detail how I'm wrong, and points me at other frameworks as good as Rails, I'll go on thinking that it really is the best thing out there at the moment.