Blue Flavor

Filament by Tom Watson

Why I Chose Ruby on Rails

October 4th, 2006 at 6:45 a.m.

As I sit down to type this I feel as though I’m about ready to light the trail of black powder that leads to the giant barrel down the hall. It shouldn’t be this way, it shouldn’t matter whether I chose Rails or Django, what should matter is whether or not we’re able to build great things for our clients, the community and ourselves. Not whether the geeks or the community agrees with what technology choice we made.

Which is why I decided to chose Rails. Not because it’s better or because it’s cooler, or because I wanted to jab Jeff. I chose it because I think it’ll work best for us here at Blue Flavor. I’ve spent a good month playing with the two frameworks, looking at the different options they both offered, reading user opinions, meeting with developers, etc. and realized that it just doesn’t matter that much. We needed to make a decision and actually start using something as opposed to just talking about it or we’d never get anything done. There were many factors but here’s the main reasons I went with Rails:

1. Developers

We’ve got a few developers that we’ve used in the past here for various projects and they’re very into Rails. This was probably the biggest deciding factor for me. I’m the technologist here at Blue Flavor. Which basically means I guide and make the technology decisions here. I’ll do some coding and eventually get good enough to make some cool apps, etc. but when it comes to whipping out solid, tested, and client ready applications we’ll have to look for some more professional resources because, although we do web development, we don’t want to become an application development shop. And as many people mentioned in Keith’s post a few months back, finding just one or two developers you know and trust isn’t a trivial thing.

2. Hosting

Our host is in beta with their shared hosting plan that will be offering Rails. Yes, we could have found a different provider and switched to them, but we’ve just switched to Media Temple from Dreamhost here. And after talking with a few guys over at Media Temple, they explicitly said we could use Django on our own server but not on the grid (their shared hosting environment). So if we wanted to offer it to clients, we’d have to find another host, which would mean I’d have to deal with yet another hosting environment, and we already have a great relationship with the guys at Media Temple.

3. Momentum

This is totally a gut thing and something I’ve wavered on a lot. I really like Django and feel it might even be more well suited for the projects we’ve got in mind but it just doesn’t “feel” like it’s got the momentum Rails has. It’s not going to be bundle in Mac OS X 10.5 like Rails, we can’t seem to find Django (or even Python) developers around Seattle, and when I was talking with a potential client last week who was basically a business man who like websites, he knew all about Rails but had never heard of Django. It just sounds like an easier framework to “sell” to potential clients then Django. Now that might change, but right now it just feels like Rails has the edge there.

These were just my top three. There were plenty of other deciding factors but I want to emphasize this: this has nothing to do with which one is better. It’s just what I think is better for our company right now. We may find after using Rails for a few months that it just isn’t working and have to jump to Django or even CakePHP or some crazy Perl framework (shutter), or even Lasso. What I, and all of us here, want to do make websites and web applications better, quicker, and more well structured so we can do it again faster. So, in the end the client gets a better product and the people using it get a better experience.

That’s really the bottom-line here more than anything. Being able to use technology to solve problems and improve user experience. For our particular situation Rails seems like the best choice.

Tom Watson

More Information