In the previous post I tried to describe as good as I can all the things that make ASP.NET 2.0 great platform, but also all those that make it very irritating and tiresome.

I ended up choosing Ruby on Rails (RoR), but the decision was not nearly as simple. I like Ruby as a language just like many people do – there’s something magic about it that seduces you from the moment you write your first non-trivial script. But the hype surrounding Rails was so strong that I was put off by it. Finally, when I realized that building my site with ASP.NET will most likely become an exercise in frustration I decided to give Ruby on Rails a chance.

Note that unlike ASP.NET, I did not yet build anything serious with RoR. However, looking back at the project I did build with ASP.NET it is quite clear that it would have been almost trivial to build in RoR. To understand “almost” you’ll need to check out the list of what’s good and what’s bad about RoR. First the good stuff:

• RoR is an application framework and not a class framework; this means that there is a certain way you build your apps and especially if you are inexperienced this will help to guide you
• RoR’s MVC (model-view-controller) implementation is very good, especially its ORM (object-relational mapping); ORM is not the most flexible one, but for most of the purposes it works really well – as long as you follow the conventions; ORM supports multiple database backends: MySQL, PostgreSQL, DB2 but also Microsoft SQL Server
• RoR has a concept of conventions over configuration – by following the naming of database columns, classes, modules and methods you can achieve a lot; for those that like flexibility and don’t like rules this is irritating, but for practical folks (this is my opinion) this is great because all your “configuration” information stays embedded in your source code files
• RoR insists on good testing practices; the skeletons for your unit tests are generated along the rest of the generated files and the community around RoR seems to pay just right dose of attention to tests, both unit and functional
• RoR is very practical by supporting three different kinds of development environment, each with its own database – development, production and testing
• RoR has feature parity for most of the features a modern Web framework should have (just like ASP.NET) – things like ASP.NET master pages (they are not called like that but any page that consists of other components is effectively a master page), good caching, session support, AJAX…
• If you do know HTML, writing the pages will be very easy; RoR embeds Ruby in HTML, not unlike ASP (not ASP.NET!) did years ago, but there’s a difference – because RoR is an application framework, you do not end up mixing business logic and presentation code, you just mix code and markup; after thinking about this a lot, especially after my struggle with some of ASP.NET controls while trying to tweak their behavior I think this way is better
• RoR has a strong emphasis on DRY (don’t repeat yourself); if you are experienced, this won’t matter because you’ve already learned the lesson the hard way, but if you are a beginner, this is a very nice habit to adopt
• RoR is constantly developed and if you are inclined to do so, you can “live on the edge” and always run the latest and the greatest code; the release cycle is also faster than for ASP.NET because there are no other products to tie the launch with
• There are several IDEs to choose from, including extensions for the two giants of modern IDEs – Eclipse (RadRails) and Visual Studio 2005 (Ruby in Steel)
• Ruby is a great language that fits the needs of a Web developer very well; speed is not as important here as much as flexibility and expressiveness
• RoR is free, runs on variety of free Web servers (like Apache, lighttpd and Mongrel) and free Operating Systems (practically all popular versions of Linux); it generally a lot cheaper to find a Web hosting deal on Linux with MySQL or PostgreSQL than it is for Windows with IIS and Microsoft SQL Server

Now for the bad stuff. You’ll notice that just like with ASP.NET, both the good and the bad list are just as long. Programming is hard – deal with it . Here we go:

• RoR is hyped beyond belief; some of the screencast will make it seem almost like magic; people will take it for granted that RoR is the magic silver bullet they’ve been waiting for and be very disappointed when it does not fit their needs
• The concept of conventions over configuration works great as long as you can fit your app into the convention – if you can’t, tough luck; example is composite primary keys – can’t do it in RoR without a lot of trouble, RoR likes its keys as a single column named id of type integer and auto-incremented
• If you don’t know HTML, you’re in a tough spot; there is no concept of controls spitting out markup and the IDEs do not have nice designers – you’ll have to build all your markup manually
• RoR is not documented well and there is no alternative to MSDN library; the situation is improving, but for the meantime your best bet is to buy books (that are not free and cost money)
• When I said “my app was almost trivial to build in RoR”, the missing feature I was referring to was i18n (internationalization); this is actually a problem with Ruby itself, not RoR, but doesn’t matter – building properly localized Web apps with RoR is incomparably more complicated than with ASP.NET; this is the biggest problem with RoR at the moment
• RoR is not thread-safe, so if you want to serve several requests at the same time you have to set this up yourself (non-trivial, see next point)
• Setting up (or deploying) RoR application is complicated just because there’s so much choice (regardless of what Open Source zealots will tell you, my opinion is that too much choice hurts) – do I use Apache or lighttpd or maybe Mongrel, or maybe I should combine them with a load-balancing scheme; should I deploy to Windows or Linux and if Linux, which distribution and which version etc
• RoR is young and sometimes changes a lot; if you want to stay on top of it all, you have to run the latest code which in turn means that you’ll run into bugs and won’t know if it’s your bug or framework’s
• IDE support is not as nearly as sophisticated as it is for ASP.NET, including integration with databases
• Third parties do support RoR in the form of plugins, but there are so many and most are a one-off job from a single dev just playing with the technology so you have to be careful which ones to pick to base your code on
• Ruby is a great and flexible language but it is slow – if you need stuff done fast, you might have to resort to writing C based extensions which is hard if your background is pure Web development with scripting languages only
• Ruby as a language evolves very slowly; the i18n problem that I mentioned is supposed to be fixed Real Soon Now^TM yet it took more than a year to move from 1.8.2 to 1.8.4 (with a small fiasco with 1.8.3)

Looking at all of this, it’s obvious that RoR is not a clear winner over ASP.NET. In fact, the site I built with ASP.NET, despite all the frustration would probably be harder to build with RoR just because of bad i18n support.

In the end, having in mind my needs and the size of the site I am about to build, I decided to go with RoR. It just feels right. Everything makes sense. The framework is there to help you, not to fight you. If you can live with all the conventions and restrictions of course.

So choose wisely. Ignore the hype from all sides. Try building something and definitely read a few books and search the Internet. There’s a lot of information out there. Hopefully the last two posts will help you decide too.