Thank you, Rails

It’s fashionable, or perhaps inevitable, for tech communities to trash their competition. The Emacs folks like to mock vi users; Windows folk look down on us Mac users (and Linux users mock us both); and everyone likes to mock PHP despite PHP ’s dominance in the web world. We geeks make arguing over minor technical points into a kind of art.

This is all pretty understandable: it’s easy to define community in terms of what we’re not . A common enemy focuses and drives us. Competition can take a positive form: when it’s friendly and constructive both communities benefit.

Lately, though, I’ve noticed the tone of the arguments in the Django community getting nastier — especially when it comes to Rails. Again, I’m far from innocent in this regard: I’ve certainly done my fair share of Rails-bashing, and I regret it.

I think it’s important to recognize that we in the web development community do in fact owe Rails and the Rails community a debt of gratitude. Rails helped reframe the way we think about web development, and even those who’ve never touched Rails nevertheless are probably reaping indirect benefits right now.

So I think we should all step back from our personal preferences and plainly say thank you, Rails , for all that you’ve done to move the state of web development forward.

Personally, I’ve learned two huge lessons from Rails:

Development should be fun

At PyCon 2009, while discussing some topics of interest , Ian Bicking mentioned that at times he worries that the Python community takes itself too seriously.

I worry about this, too. When I first started using Python, all eyes were on the Enterprise. Python needed to be a Serious Language used by Serious People at Serious Companies doing Serious Work. This was always a bit of strange goal for a language named after a British comedy troupe.

Then Rails burst onto the scene with a simple message: web development ought to be fun . In retrospect this seems like an obvious development: most geeks of my generation got into computers just because they’re fun. But at some point we realized we could get rich programming, and when the money came in most of the fun drained out. Then came the dot-bomb. Suddenly there really wasn’t a huge amount of money any more; just Serious Work.

But the Rails community turned this on its head. Why should we spend so much time trying to build Big Serious Software when we can build small, fun, light tools that actually make money, too? Turns out that those who enjoy their job are actually more productive — fancy that!

I learned this lesson years ago when I left a my soul-sucking job in New York City for a move to Kansas and a 50% pay cut. It was the smartest decision I’ve ever made, but at the time dropping half my salary for a job that seemed “more fun” got me a lot of flack from colleagues. These days I doubt I’d get the same criticism, thanks in no small part to the ideals that the Rails community put forth.

These days, the Django community has its own special breed of sillyness which brings me no end of joy. There’s some who find this stuff all a bit precious, and I sympathize, but laughter, play, and fun are vital aspects of a vibrant, healthy community.

Simplicity is a feature

My first foray into the CMS world came through Vignette and BEA (now Oracle) WebLogic . My first expose to a “web framework” was Struts 1 . My second, Zope 2 .

All these tools seem designed with those massive feature comparison grids in mind — the goal seems to be to garner as many pretty √s as possible. CMS development is strongly strongly feature-driven: the goal seems to be to support as many use cases as possible.

Faced with BEA , I couldn’t understand this impulse. Now, as a maintainer of a framework (with strong CMS -y leanings) I understand it perfectly : every single use-case has a real-world developer behind it, struggling to get his job done on time. Saying “no” to feature requests is incredibly hard. I don’t do it as often as I should.

One of the most controversial tenants of “the Rails way” has been this idea of opinionated software . This idea that our libraries should make certain expectations about developers can seem pretty heretical. We’ve certainly taken a softer spin on things in Django-land; we talk instead about “sensible defaults. The basic idea’s the same, though: make assumptions about common cases to help keep software simple.

This idea turned simplicity itself into a feature, and completely neutered the power of the feature grid. Instead of neat rows of checkmarks, now we’re comparing who can accomplish some task in the fewest lines of code. Monolithic, massive features sets are out; minimalism is in.

---

So, once again, thank you, Rails. Even though we don’t see eye-to-eye on everything, I’m glad to have you around. You’ve made these Internets a better place.