twitter
    musings about technology and software development..

A taste of Ruby on Rails, part 2

NOTE: This is a continuation of part 1.

Ruby on Rails is a great web development platform, but has a few drawbacks that you should understand before switching from ASP.Net.

Catch #1: Library support, or lack there-of
When you're staring at Notepad, and you want to support uploaded images and auto-resize them, it's not easy to figure out where to start. With .NET, you have the standard library to poke around and can usually find what you need with the help of Intellisense. With Ruby, everything starts with a Google search. After deciding amongst five identical-sounding choices, you download an image plugin written 2 years ago by a kind developer, which doesn't install on Windows because said developer only has a Mac. You download the tarball of source files that you can't compile without a special version of Visual C++, and doesn't work against the latest version of Ruby you just downloaded. After it finally installs, you end up burning an afternoon debugging it. Of course, it's free. But only in terms of money -- it costs a lot of time (not spent coding, mind you), and time is more important than money (that's why you're even considering using RoR, right?).

Catch #2: Convention over Configuration
One of the key tenets of Rails is convention over configuration. What this means is the language has an expectation of a "right" way to do things, and if you do it that way, lots of goodness happens for you automatically. The net result is you will find yourself making compromises just to make sure you stay on the right side of syntactical sugar.

Catch #3: Stabilization
At Microsoft, perhaps only a third of the time is spent writing new code. Making the code functional is the easy part. Making it work in all the different user scenarios, under heavy load, with different data sets, and otherwise stabilizing the code, that's what we spend two-thirds of the time on. And what are you doing during much of this time? Debugging.

Anyone who's ever used a debugger knows how critical it is to walkthrough code to comprehend what's going on, especially as your code gets more complicated. And, for anyone used to Visual Studio, the debugging experience in Ruby leaves a lot to be desired. So the thing I spent one-third of my time on is now super fast, but the thing that I spent two-thirds of my time on is now frustratingly slow.

Catch #4: Performance
I can't stress how important speed is when it comes to the user experience. Milliseconds matter. Like other non-compiled languages, Ruby will execute slower than ones which compile to native bytecode. Moreover, the tools to measure and profile those milliseconds are still in their infancy. If you've never looked at a profile of your code, you are probably wrong about where your code spends its cycles.

Conclusion
RoR is a great tool to have in your inventory, and like every language it has it's deficiencies. And, like any deficiencies, they can be mitigated -- for example, writing better unit tests to reduce time debugging, and using AJAX to improve user perceived response time.  As long as you understand the trade-offs, you can decide what's best for your project. For my one-man "fun" web development projects, RoR is a winner.

1 comments:

Tim Kellogg said...

Have you ever tried IronRuby on rails? Running RoR on IIS would eliminate #1, 3 and 4 since you have full access to the .NET framework, it can be debugged in Visual Studio, and the performance far exceeds that of C-Ruby. The convention over configuration is more of a paradigm shift.

Post a Comment