-
Why I don’t deploy on Ruby on Rails
Posted on April 21st, 2008 2 comments
I read an article today that says already alot of what I have to say in regards to Ruby on Rails. My previous articles should pretty well imply how I feel about Rails as my coding style in php has been largely inspired by Rails methodology. That being said, Rails unfortunately has not been the holy grail it was promised to be. While I may sing its praises and encourage people to learn it, I will not deploy production applications using the technology. It’s actually sort of a long standing inside joke at my job about past developers who’ve come and gone and pointed at anything remotely shiny on the web and proclaimed “that’s got to be done in Rails”. While amusing, it demonstrates how Rails has established this “coolness” reputation. Developers seem to think you can’t teach an old dog (php, java, perl, etc) new tricks (ajax, mvc, rapid development).
This article was one that change alot about how i viewed web development. In that article Derek Silvers explains his failed 2 year foray into the world of Rails in his rewrite of cdbaby.com. I was heavily developing in Rails when he wrote that article so naturally I was very interested in what he had to say. Some time after I was getting into another obscure language called Scala (I will be back to talk about that) and I was noticing the rough start of the popular site, Twitter (I cannot find the referencing article but I’m pretty sure there were some scalability concerns). Seemed as though Rails was struggling for sites that needed to scale and performance was a nagging problem.
There’s no denying that Rails is a superb framework and has taught me many skills which I have taken with me to the Zend Framework, but I admit I am nervous about using it for anything large scale which I deal with constantly at eROI. I still can’t get over my long standing infatuation with the framework though and until I mold the Zend Framework to embody all of its attractive qualities… I will always have a place in my heart for the little framework that could. In fact, for some of my uber large scale project ideas I am working on the side, I may use Rails as a prototyping framework before writing the real thing in something that will run on the JVM (Java Virtual Machine).
This could change but that seems a ways off according to Tim Bray (strong Rails advocate). Performance has to be enhanced and it probably wouldn’t hurt to make Rails more Apache friendly. I know that its perfectly fine to run Rails using fastcgi on Apache, but its no where near is nice as using an apache module. Mod_php makes my life so easy and it would be fantastic to see something like mod_rails (If such a thing exists, forgive me my ignorance). The struggle to make Rails and Apache play nice 2 years ago prompted a brief affair with Lighttpd/Mongrel which is a great combination for Rails hosting.
I really hope that these things happen because I would switch back in a second if telling someone you were developing an enterprise application in Rails didn’t prompt snickering and quiet chuckles.
2 responses to “Why I don’t deploy on Ruby on Rails”
-
Very interesting perspective. I came across Derek’s article a while back. While I have heard about scalability concerns from several users of Rails (I prototyped with it for about 6 months, but never ran a production site on it myself), I have to mention that we hope there are other reasons to use Zend Framework for high-load, enterprise-oriented site/apps. For example, a lot of the cool features for which Rails has become the poster child- such as scaffolding and other features that rely heavily on convention- are really attractive to developers because they make the first few days of working with a framework easy. I don’t know of a single developer who likes having to go back to the manual every few seconds to do the next step. Rails simplifies this by heavy use of CoC and DRY. *But* the first few days is only a small fraction of a typical developer’s relationship with his/her framework of choice. With that in mind, we plan to work up to such features in ZF, but *never* at the expense of power and flexibility- which are much more likely to affect your *long term* experience with a framework in our opinion.
Rails is an elegant framework that works well for many sites; I think we’ve gotten about as much consensus on that as we can ever expect in the web dev community. It’s when your requirements fall outside of those Rails was designed to simplify that a lot of the RoR shine starts to wear off. ZF is designed to work with your requirements- whatever they are. We have a will continue to build on top of our existing abstractions to bring more out-of-the-box functionality and facilitate common use cases; if our top abstraction layer doesn’t work for you, ZF is designed so that you can punch through that abstraction and find the layer that supports your requirements as well as any framework could be expected to. In a way, we see ZF as the ‘no worry’ framework. It wears it’s (current) limitations on its sleeves- you don’t have to worry about scaling or excessive complexity of design for unique requirements beyond the concerns that you’d have in your tried and true PHP platform.
This is a hard position to hold to. Until we have the time to implement Rails’ features without relying on conventions entirely, our shortcomings are put front and center: in the first hour of a developer’s experience with ZF. But we believe it’s the right strategy for our users in the long run. In any case, I just wanted to add that extra perspective from an extremely biased person. :),Wil
-
I’m thrilled to see someone from Zend chime in… I agree with you completely. In my experience with Zend so far I have found it to be more flexible in that you don’t sacrifice the ability to for convenience which has burned me more than once on rails. Thanks for the perspective.
Leave a reply
-
profile 