I’m stopping all my ruby on rails development. Its been a while since my last rails line was written and I will not continue to develop on that framework.

Here are my reasons for this:

  1. Documentation and entry point price

    First of all, to get any serious documentation on how to use the framework, you have to buy Pragmatic Programmer’s Ruby on Rails book. While its a good read and all, its a $40 US dollars (ok, now its $19.95, but I bought it when it was recently published) entry price to get serious on the subject. Another good resource are the Peepcode’s videos. They are excellent reference material, but still there’s a cost. Its not that I’m against commerce and all that. I’m just making the point that there’s very little or no good documentation for rails for free. Plus, there’s a disadvantage on printed books that they’re not up to date with the latest changes. There’s a lot of “when rails2 comes out…” comments on it.

  2. Community problems

    Then are the community problems. Its people and people sometimes don’t get along, but the comments from Zed Shaw, the mongrel web server developer are something to pay some attention to. Besides, he’s also stopped development on mongrel, so the installation trend must, or probably by now has, shifted again.

  3. Hosting

    Another big problem is the hosting support. All the projects I’ve developed I’ve tried then successfully on my development computer and on some self owned servers. Hosting support for Ruby on Rails is still not very common, so if any of my clients don’t have control over their server and their hosting solution doesn’t support it, its bad.

  4. Production deployment “trends”

    One of the main problems I see often is production deployment “trends”. The method to succesfully deploy a rails app on any server changes constantly. First, the recommendation was fastcgi with lighttpd, then it was mongrel servers doing load balancing with an apache server, then capistrano, then nginx, now I’ve lost track of what to do. Even on the book this ambiguity is mentioned.

  5. Ruby gems

    And finally, now that we’re talking about owning a server and deploying it for production, the final caveat is the ruby gems mess, described on more detail on several Debian developers (Wouter, Gunnar, Luke Kanie) blogs.

So, with all this in mind, I’ll be looking to port some of my already developed rails apps to Django. I’ve seen a lot of progress on this framework and like a lot of its design concepts. As much as I’ll miss a lot of ruby’s syntax and “sugar”, python is not bad either and its also a very comfortable language to work with. There’s a lot more libraries for python than for ruby to build stuff. Also, its interpreter is a lot faster than the ruby1.8 one. I know there’s a promise that ruby1.9 will be a lot faster, but its not ready yet.

Finally, I see there’s a lot of good stuff in Rails, but for me, right now is not a good time to jump on that ship.

About the author

Gabriel Saldaña Gabriel Saldaña is a web developer, photographer and free software advocate. Connect with him on and Twitter

%d bloggers like this: