How Ruby on Rails Could Be Much Better

How Ruby on Rails Could Be Much Better thumbnail

A rant by Zed Shaw, the man who wrote the original version of the Ruby application server Mongrel got me thinking about the experiences DreamHost has had hosting Ruby on Rails driven websites over the past couple of years. The rant itself was somewhat lengthy but an interesting (albeit self-indulgent) read if you’re either a Ruby on Rails developer, a nerd who’s just into stuff like that, or interested in the behind-the-scenes of a highly public open-source project.

I don’t have anything to add to Zed Shaw’s comments about how the Rails development team operates as I don’t have any personal knowledge of that. What I do have personal knowledge of is how difficult it can be to get a Rails application up and running and to keep it running. DreamHost has over 10 years of experience running applications in most of the most popular web programming frameworks and Rails has and continues to be one of the most frustrating.

Some History

When we first started implementing our support for Ruby on Rails, we wanted to do whatever we could to support it. It was an exciting and new web framework that was invigorating web application development. Ruby on Rails seemed to really fit in with our company philosophy and we thought our existing customer base would love it. We ended up implementing quite a lot of new features just to support Ruby on Rails, not least of all FastCGI support. Rails itself turned out to be far too slow to use without some sort of acceleration (unlike any other web programming environment we support), and FastCGI is by far the best suited to a shared web hosting environment. Unfortunately, Rails and FastCGI just don’t really get along! No matter what we did users of Ruby on Rails kept seeing regular internal server errors. The best guess I have is the FastCGI dynamic process manager was politely asking the Rails process to die and instead they were just exiting and leaving the application high and dry. That’s in layman’s terms, of course!

These issues were later mostly mitigated by a single user of Ruby on Rails who wanted it to work better on our servers, but the solution from the Rails community itself was quite honestly, stupid. They said to stop using Apache and FastCGI (a combination that successfully powers bazillions of websites, just not Ruby on Rails ones) and instead to entirely retool our servers with Lighttpd and SCGI (a FastCGI like protocol that may be technically superior, but next to nobody uses). That suggestion shows either a complete lack of understanding of how web hosting works or an utter disregard for the real world. It’s all good and fine to recommend that users use higher-end dedicated server hosting for their commercial applications but you simply cannot ignore the fact that nearly everyone will want to use lower-cost shared hosting for getting started. It’s just simple economics. Additionally, people who use systems like Ruby on Rails want to spend time programming and not time setting up servers. Recommending technologies that are not widely used or supported by any major web hosting company is putting too much of a burden on your users, the people you want to keep happy! It’s a good thing we never even tried to switch our system to support Lighttpd and SCGI, too, because 6 months later the ‘in thing’ in the Rails community had shifted to Mongrel, instead. Make up your minds already!

How It Could Be Better

Zed Shaw mentions in his rant that even the Ruby on Rails application run by DHH (the guy who wrote Rails!) has regular issues and needs restarts several times a day. The Rails community is full of very smart programmers and they have implemented a great system that works awesome when it’s not needing looking after. It’s one of the most fickle web application systems I’ve ever had experience with, and this is coming from someone who has experienced both the ill-fated Netscape web server as well as many iterations of PHP (PHP has many issues of its own, so don’t get too smug, PHP people).

Ruby on Rails has amazing potential, but here are some things that simply must be fixed before it will ever be as widely used as much less hyped web application environments like PHP…

  1. Ruby on Rails needs to be a helluva lot faster. With a proper accelerator, it’s nicely usable but without one it’s painful. Ruby itself is a big part of the problem so this one may come down to just simplifying the management of the accelerator technologies, unfortunately. Mongrel seems like a big step in the right direction, even though it’s not Rails-specific. I hope the Rails core developers will be cooperating a lot more closely with Mongrel developers in the future.
  2. Ruby on Rails needs to more or less work in ANY environment. You can’t just expect your users to set up their servers any which way. There are millions of established systems that cannot simply integrate any bleeding-edge technology you think is better this week. If you continue to keep this attitude you are surely shooting yourselves in both feet.
  3. You need to maintain backward compatibility better. Admittedly this is the area where PHP has historically done very poorly, but that’s no reason to not one-up them. Also, Rails is admittedly very young as a development platform and you guys have gotten a LOT of attention very early on. Still, with big hype comes big responsibility. You need to keep the momentum going now.
  4. Officially support shared hosting environments. The feeling I get from the Rails community is that Rails is being pushed as some sort of high-end application system and that makes it ok to ignore the vast majority of user web environments. You simply cannot ignore the shared hosting users. In my opinion, the one thing the PHP people did that got them to where they are today is to embrace shared hosting and work hard to make their software work well within it. That means it has to be very lightweight (it may be too late for that in Rails already!), and it has to “plug in” to a wide variety of operating environments with minimal fuss and hassle. Compatibility work like that is not glamorous, exciting, or fun, but it’s gotta be done.

What Now?

DreamHost very much intends to continue fully supporting Ruby on Rails. Ruby on Rails does have great promise, and I think in time it may be able to meet the hype it’s got surrounding it. I just hope the community doesn’t get a big head before that happens!

The opinions presented here are entirely from the perspective of an outsider with some web experience. I know Ruby on Rails is in use on some very high traffic websites and it is certainly possible to make it work well. What I’m saying is that it really needs to be a whole lot easier. You have to be careful not to confuse user enthusiasm with easy to use. Enthusiastic users will fill in many many gaps in usability (DreamHost thrives on that fact!), but you cannot rely on that over the long-term.

Photo of Dallas Kashuba
About the Author: