views:

296

answers:

4

One of the main reason many developers choose Ruby-On-Rails is its promise of increased productivity. As many people in the rails community claim "It is the fastest way of going from and idea to implementation". I have seen anecdotal references to Rails vs. java OR Rails vs. PHP coomparision claiming Rails applications to be 3-5 times faster development time.And there are numerous screencasts and blogs that show you how to develop a database application from start to finish in an hour (or a day) with few lines of actual code logic.

Can you really extrapolate this level of productivity to a large project involving multipe teams and highly complex requirements for scalability, performance and enterprise integration ?

Rails like many of its open-source predecessors such as Java and PHP is going through a chaotic phase of rapid innovation and accelerated growth in terms of ideas, features and implementation strategies. We witnessed similar growing pains with Java during its early years between 1996 - 2000. New versions and patches of core java libraries kept coming at you faster than you can keep up.

One of the frustrating aspect of developing with Ruby-On-Rails is knowing if a particular gem, engine or plugin is compatible with the version of Rails you are using. Most of the plugin repositories (gitHub, agilewebdevelopment.com) don't always provide information about the version compatibility. Rails has not yet evolvled to a point where we can establish an independent certification body (open-source OR commercial) who can provider a seal of approval for compatibility for Rails versions with a myriad of gems, plugins and application code.

What is your experience with Ruby-On-Rails and its claim to productivity gains ?

+2  A: 

Like any new technology, if you are using it for any kind of commercial or production development, avoid using the newest version. I've had very few headaches using: Rails v2.3.2 Ruby v1.8.6 and now v1.8.7

Although it claims great performance gains, I would avoid moving to Ruby v1.9 until it has been more fully adopted by the Rails community. See http://isitruby19.com to track progress of adoption and problems that others are experiencing. Like other popular open source environments, the large user base creates a nice wealth of 'Google-able' examples and help.

I'm a big fan of Ruby and its ability to let me write powerful functions that require minimal code, but are still readable. My company has done very small and basic Rails applications, as well as feature heavy, data-intensive Rails applications. The biggest drawback was probably the fact that you are limited in hosting options.

As far as evaluating their claims about productivity, I don't know if it is five times faster, but the full stack framework and ActiveRecord make creating data-driven web applications very easy. If your application is data/model driven, you will almost certainly see large productivity gains. The other nice thing is that the framework as a whole is very easy to install, especially for OS X or Linux.

EDIT:

Just to supplement my original answer, if you are using OSX, it will come with Ruby/Rails pre-installed. Hivelogic has a really good tutorial that shows you how to build your own version so that your versions of Ruby/Rails will not change with system updates (potentially causing disaster for your app locally). You can find it here: http://hivelogic.com/articles/view/ruby-rails-mongrel-mysql-osx

cgyDeveloper
+1  A: 

I have found Rails to be tremendously productive, but I've also lost time trying to deal with issues arising from the rapid evolution of the framework such as deprecations, incompatible plugins etc. However, the pace of change in Rails has also settled down a lot since version 2 was released. The quality of the documentation and breadth of supporting resources has also grown immeasurably in recent years.

Looking forward, there are more big changes coming up with Rails 3 as the best ideas from Merb are folded in, but it should be the best ever release and for the first time will feature a proper, documented plugin API. Expect more work to migrate applications to Rails 3, followed by hopefully a long period of maturity and stability.

Sometimes you have to break things to move forward. Otherwise you end up trapped in a backwards-compatibility prison like Windows.

John Topley
It's also important to note that if you're following good practices, like writing tests / specs and using a versioning system like Git or SVN, it's very easy to see what's going to break in the next release - freeze your app to the next version, run your tests, see what's coming up in the new deprecation warnings, and then roll back. A good thorough test suite makes moving forward much less painful.
Brian Hogan
Yes, good points.
John Topley
+1  A: 

Keep in mind also that Rails is a framework, not a language, so it's difficult to make a comparison in a lot of respects

A: 

My experience with Ruby on Rails is that it's great for developing small-to-medium sized applications.

However, when you start adding multiple sites running off the same Rails app with integration with other systems (AS/400s and such), this is where the pain lies and shows that Rails CAN suffer from diseconomies of scale where it becomes harder to spot the development time gains, since you have to account for caching wherever it is reasonably easy to cache, whilst also analyzing your application to see where the bottlenecks are.

We still work with Rails on large applications because even at enterprise levels it's still easier to develop with than Java and code management is more well defined than it is in PHP.

Taking into account your notes on gem incompatibilities, most people do (or should!) put the gem versions into their environment. My experience with some plugins did leave a bad taste in my mouth, but not something that was impossible to fix should you know a little Ruby or can read the history of commits on github on the Rails source.

DISCLAIMER:

I say this not yet having tried any of the Python frameworks, I'm sure they would be about as adequate (maybe more, maybe less) as Rails in this regard.

Omar Qureshi
The things you speak about (caching, bottlenecks) are just parts of building web applications and are not exclusive to Rails. If you didn't use Rails, you'd encounter them eventually, it just might not show up as quickly. But when the problems do occur, they are much easier to address with Rails than in other platforms, at least that's what I've learned from my own experiences.
Brian Hogan