Thank you, Ruby on Rails. Now get out of here.

I’ve been sitting on this one for a long time, but I was recently emboldened to write about it by reading Derek Sivers blog post about his struggle with a failed transition from PHP to RoR. Then I let it sit for another month. Today, as I watch the Rails community fight like middle school students, I decided I should finally finish this and post it.

While I have spent most of my career as a PHP developer, I have once and again found myself using other platforms because my job at the time required as much. I’ve built apps in Java, .NET and once, a long time ago, Perl. A year or so ago, I was working for a .NET web shop. We had a (somewhat) internal app that we chose as our first foray into Ruby on Rails. Rails is a sexy beast, make no mistake. I, like most developers that have spent untold hours writing the same database access routines over and over and over, was enamored with ActiveRecord and the beauty of the Ruby language syntax. We had a working prototype in mere hours. The ease with which we developed the first 80% of the application felt too good to be true.

That’s when the nightmare began. Implementing the last 20% of the project would end up taking more effort than if we had built the thing from scratch on some other platform. That’s because if you try to solve a problem outside of Rails core problem domain, you’re into plug-in territory, a scary place where people solve their own specific problems and crap out solutions that are kissing close to what you need, but don’t quite work right. Sure, you can write a bunch your own plugins, but then what’s the benefit of the shiny framework? (I’m looking right at you, user authentication and access control.)

So we finished the app, somewhat painfully and behind schedule, but we finished it. It worked great. We were happy, our users loved the demo and we figured our problems were over. Oh, how wrong we were. It was then we discovered that Rails application deployment can break a man.

I am not a fan of Windows anything for web hosting, but I found myself in a Windows hosting shop. (Dammit, Jim, I’m a developer, not a sysadmin.) Options for Rails deployment there are not pretty. You can use WEBrick, but that might be the worst idea ever. You can run Apache/FastCGI etc., but I’ve always felt that the Apache folks treat the Windows version kind of like an afterthought. IIS isn’t bad (considering the alternatives) but it was out at the time due to no FastCGI being available for it. After more than a week of research and false starts, I had the thing running on a FreeBSD box with Apache 2.2, mod_proxy_load_balancer and a series of mongrel servers. (I repeat, Jim, I’m a developer, not a sysadmin.) Not pretty, not easy and I hope no one ever has to move that app to another machine, let alone another platform. Performance, in case you’re wondering, was abysmal. When it was working, that is. It fell down for no reason several times a day.

Sure, you can call me an idiot because I tried to run the thing under windows or because I struggled to deploy under Apache. But um…isn’t the idea behind Rails that it is supposed to be less complex to use?

So what can we learn from all this? Lots! In short, I look at it like this: RoR is the H. Ross Perot of web application development. Perot forced everyone to acknowledge issues they were trying to ignore, but in no way does that mean he should have been elected president. Rails took very solid practices and many new and innovative ideas for how to structure a web application and implemented them in the worst way possible. It did, however, force the entire industry to evaluate its methods. Things changed. There’s now lots of great frameworks in lots of languages that incorporate many of the Rails ideals but are far better performing and easier to implement. Web development can be fun again, no matter what language you use.

So, Rails, take another pointer from Perot: Your point is made. Please fade into obscurity. Don’t worry, we’ll think of you fondly every so often.