In Search of Ruby’s Sweet Spot

In a recent post, Stuart Halloway wrote that his company bids up to 50% lower for projects done with Rails, compared to similar Java projects. For applications ‘nowhere near the Rails sweet spot’ they still bid 10% lower. So the question arises: what is that sweet spot? For what projects would you rather choose Rails (over Java or PHP or .Net or…)? These are my suggestions:

  • To start with, the project must be about building a web application (as we’re talking about Rails, not Ruby). But, with Profict, my employer, being specialized in EAI, I’m also interested in using Rails and Ruby for integration projects. I’m guessing Ruby can be used mostly for point-to-point integration (I’ve worked with BEA WebLogic Integration, at the other end of the spectrum, featuring a complete workflow engine and ready-made connectors to all sorts of data sources and applications); but point-to-point might be all you need sometimes. Needless to say I’m waiting for the release of Enterprise Integration with Ruby, a new Pragmatic Programmer book.
  • The existing PHP codebase may hold a useful indication. There’s a wealth of web application software available, written in PHP: content management systems, wikis, groupware, contact/communication software, host management software, blog software… In my opinion, anything to be coded in PHP can also be done in Rails, probably better, faster, more maintainable. Like PHP, Rails applications will be cheaper to host (either by yourself or by a third party) then Java/J2EE.
  • If you’re building a presentation web site (a site meant for web presence only) that has very little code, you would, up till now, probably have used PHP for the scripting. Maybe the site has a contact form that must be stored in a database, or it should run the odd database query and present the results to the visitor. I don’t think I would use Rails here, that would be overdoing it; but you could do the scripting in Ruby. (Of course, Flash might be considered for these kinds of sites).
  • Applications that do not come with clearly outlined specifications and requirements, clients that are not yet completely sure what they want, but they do want something fast: these situations call for prototyping, rapid development, the ability to change direction easily; these are projects where Rails would have a clear advantage.
  • I would hesitate to choose Rails if the project requires a large number of developers, simply because there don’t seem to be many experienced Ruby developers around yet. But this might be a local (Dutch) issue.
  • There would have to be no need for using heavyweight J2EE(-like) features like messaging, distributed transactions, connecting to ERP systems etcetera. I know, there’s a Ruby library available for everything; but if you’re going to need things like these, you’re probably (working for) a large enterprise doing an Important Project where Things Should Never Go Wrong. Let them pay for BEA, IBM or Oracle support (or Microsoft, sorry) to help out when things do go wrong, usually somewhere deep inside the application server.

It might again be a local thing, but I think a company that has chosen Java as their development platform, have done so not too long ago, and will not be particularly happy to switch to something like Ruby. Not even if the project costs them less. For them, Java is a project requirement. Also, they can afford to use Java and they’ve invested in it; I mean, Java is difficult and expensive to host, and Java development isn’t cheap either.
Clients who could be interested in Rails might not even be using Java right now — PHP might be a better guess. Those clients could well benefit from a framework that delivers faster, has a better architecture and is easier to maintain. Compared to PHP, I think Rails is one enormous sweet spot.

2006-01-13. No responses.

Comments are closed at this time.