ASP.NET vs Ruby on Rails : Round 1

Before I start, I want to say one thing. Comparing RoR and ASP.NET is not like comparing Apples and Apples. They are not the same type of entity. Its more like comparing Oranges and Tangerines. To someone who has never eaten orange-colored fruit before, that person might think they're the same thing. But, once you take the outer layer off, they have a very distinct flavor all their own.

Basically, ASP.NET is a compiled, managed framework for building web applications on top of the .NET Framework. Rails is a framework upon which developers can build web applications written using the Ruby programming language (scripting language carries a somewhat negative connotation, so I prefer to refer to Ruby as a programming language). If you want more detail on each of the two web application frameworks, feel free to consult the MSDN documentation for ASP.NET and there is a plethora of documentation available for Ruby and Rails as well.

In this article I am only going to compare the actual construction of rendered output. I will not discuss creating data-driven applications or data mapping, data modeling, etc. I will save that for Round 2, because it deserves a blog post of its own.

In the red corner with the white trunks: Ruby on Rails

Ruby is a very powerful object-oriented, interpreted programming language that incorporates a lot of extremely good ideas from SmallTalk and other "pure functional" programming languages (such as the ability to utlize lambda expressions, treat code as data, etc). Rails is a framework for creating web applications with Ruby. You use a web server such as WEBrick to run a web host on a given port that executes your Ruby code to produce rendered HTML output. 

RoR enforces the Model-View-Controller pattern in an absolutely rigid fashion. When you hit a web page in an RoR application, it basically follows this pattern:

http://server/application/controller/method

The controller is invoked, with the method indicated on the URL. The controller is responsible for populating the model that will then be used to drive the view. The view is essentially an RHTML file that is interpreted with ERb (Embedded Ruby) that allows the view to be linked to the model. This separation of MVC is strictly enforced by the directory structure and file naming structure. For example, to create a section of the website that provides a browsable catalog, you might have the following files (among others):

/mystore/app/models/product.rb
/mystore/app/models/line_item.rb
/mystore/app/models/order.rb
/mystore/app/controllers/store_controller.rb
/mystore/app/views/display_cart.rhtml
/mystore/app/views/index.rhtml
/mystore/app/views/layouts/store.rhtml
/mystore/app/views/order_history.rhtml

display_cart, index, and order_history all correspond to methods on the controller, which is a class called StoreController found in the store_controller.rb file. There is something about the purity of the MVC implementation here that I find irresistable. The elegance in the design, coupled with the ease of maintenance and enhancement brought about by the pure implementation of MVC is extremely good. If you're a fan of this pattern, and you have never grown to love the horrible practice of embedding all code in a single ASP (or PHP) page - then you may find the RoR model extremely appealing. You can create re-usable components that are rendered within a loop very much like ASP.NET user controls or Repeater templates - and a truckload of other stuff that I just don't have time or space to cover here.

Here's a sample bit of Ruby (taken from the Agile Web Development with Rails book) that renders the contents of a shopping cart.

Model:

class Cart
  attr_reader :items
  attr_reader :total_price

  def initialize
    @items = []
    @total_price = 0.0
  end

  def add_product(product)
    item = @items.find {|i| i.product_id == product.id }
    if item
      item.quantity += 1
    else
      @items << LineItem.for_product(product)    
    end
    @total_price += product.price
  end
end 

View:

<div id="cartmenu">
  <ul>
    <li><%= link_to 'Continue shopping', :action => "index" %></li>
    <li><%= link_to 'Empty cart', :action => "empty_cart" %></li>
    <li><%= link_to 'Checkout', :action => "checkout" %></li>
  </ul>
</div>

<table cellpadding="10" cellspacing="0">
  <tr class="carttitle">
    <td rowspan="2">Qty</td>
    <td rowspan="2">Description</td>
    <td rowspan="2">Price</td>
  </tr>
  <tr class="carttitle">
    <td>Each</td>
    <td>Total</td>
  </tr>
  <% for item in @items
      product = item.product
-%>
  <tr>
    <td><%= item.quantity %></td>
    <td><%= h(product.title) %></td>
    <td align="right"><%= item.unit_price %></td>
    <td align="right"><%= item.unit_price * item.quantity %></td>
  </tr>
<% end %>
  <tr>
    <td colspan="3" align="right"><strong>Total:</strong></td>
    <td id="totalcell"><%= @cart.total_price %></td>
  </tr>
</table> 

Controller:

class StoreController < ApplicationController
  def index
    @products = Product.salable_items
  end 
  def add_to_cart
    product = Product.find(params[:id])
    @cart = find_cart
    @cart.add_product(product)
    redirect_to( :action => 'display_cart' )
  end 

  def display_cart
    @cart = find_cart
    @items = @cart.items
  end
  private
  def find_cart
    session[:cart] ||= Cart.new
  end
end

Opinion: RoR has a very "Web 2.0"-ish feel to it. It feels very progressive, forward thinking and it lends itself extremely well to an iterative, Extreme Programming (XP) type of life cycle where you produce small bits of testable functionality and then continue outward in a spiral from there - adding more and more and refactoring as you go if need be. RoR includes out of the box support for multiple data environments (e.g. test, development, production, etc), as well as support for building unit tests for the entire site. RoR's philosophy is all about convention over configuration. If you agree to a couple of rules that are really not much more than some commonly agreed upon best practices, then things will magically "just work" and you can override the convention with configuration if you feel that you must.

In the blue corner with the rainbow-colored trunks: ASP.NET 2.0

ASP.NET is probably far more familiar to those of you who read my blog, especially considering that Microsoft technologies pretty much comprise 99.9% of everything that I blog about. That doesn't mean that I'm not open-minded, it just means that I'm a .NET Addict. ASP.NET uses the .NET Framework to provide a framework upon which developers can build web applications. It doesn't enforce any particular pattern on you, and I've often found that in the hands of the untrained, ASP.NET can produce some of the most hideous, difficult to read, difficult to maintain, difficult to troubleshoot code known to man. Conversely, in the hands of a "tersity purist", Ruby can be pretty damn cryptic as well.

Rather than enforce the use of a Model-View-Controller, ASP.NET 2.0 gives you the magic of "code-behind" ASPx pages. To produce a functioning shopping cart in ASP.NET 2.0, you might have the following files:

shoppingcart.aspx
shoppingcart.aspx.cs

Admittedly, the sample I showed above in RoR actually has all the plumbing necessary for data access, so you might also include a Typed DataSet in your app to represent the model portion of the pattern:

/App_Code/Store.xsd
/App_Code/Store.xsd.cs

What's really going on here is that shoppingcart.aspx is functioning as the view portion, and can have sub-view or partial-view functionality provided by ASP.NET User Controls or ASP.NET Server Controls. The controller is typically located in shoppingcart.aspx.cs , though its status as a controller is not as clearly defined as in RoR. The model in this sample is Store.xsd, a Typed DataSet that can interact directly with the database and retrieve its own data and perform its own updates. The mapping contained in Typed DataSets is probably the closest you can get to RoR and ActiveRecord (I'll discuss LINQ to Entities vs ActiveRecord and RoR in the next post).

What happens more often than not is that the undisciplined programmer will completely munge the MVC pattern in ASP.NET, and come up with what I refer to as the MoTrolliew, a hideous creature that is a frankensteinish mash of Model/View/Controller where the boundaries of each overlap in such a way that the true benefits in terms of scalability, maintainability, re-use, and ease of review are lessened by the blending. Note that I said undisciplined programmer. It is perfectly possible, and often quite easy, for the programmer with good discipline and skills to create a very clearly defined MVC pattern in ASP.NET. The problem arises when you get people trying to jam all the code into the .aspx file without even bothering with a code-behind. To add insult to injury, a large number of ASP.NET books actually recommend this hideous bastardization of good design principles. Almost all of the early Wrox books on ASP.NET 1.0 illustrated their code samples this way. *shudder*

In subsequent posts, I will address data mapping/data modelling, as well as things you get "for free" such as ASP.NET's provider model, authentication, etc. For now, I just want to address the visceral "feel" of the environments since that is what contributes to a first impression, and as we all know, the majority of our technological decisionmaking is done on first impressions regardless of whether thats a good thing or not (its not). I discarded Ruby on Rails as a hobbyist toy during my first impression. I am aware of the fallability of first impressions, and I actually go back and re-evaluate every technology I experiment with for second and third impressions as a result of this known flaw in first impressions.

When I first started working with Ruby, I felt completely lost. It felt so completely unstructured and I felt as though it was too "scripty" and very immature - in short I felt as though it might make a great toy for creating really quick data-driven websites. If I wanted to create a website to display the stats from my gaming guild in the current game-of-the-month, I thought Ruby might be ideal for that. It still is, but Ruby on Rails has much more power than that, and far more applicabilty to enterprise applications than I first gave it credit for - even though it lacks some enterprise features I really like.

When I am working in ASP.NET, things feel more rigid, more controlled, and more structure. The hilarious part of it is that the rigid structure feeling within ASP.NET is actually wrong. By default, if you just start banging out code in ASP.NET, you're not using a really good design pattern (MVC) , you're using the MoTrolliew monster. Over the past years, while writing books on ASP.NET, books on C#, and creating an unbelievably large number of enterprise applications with ASP.NET, I have learned a truckload of lessons. Those lessons temper my approach to the platform, and when I create new ASP.NET applications, especially new ASP.NET 2.0 applications, I have a laundry list of things that I delete from the templates, and framework scaffolding (yes, that word is very intentional) that I bolt into my empty application before I get coding. 

When working in ASP.NET, I don't get any of the "Web 2.0" feeling, or the feeling of being outside the box. I have to do a lot of work to get the loosely constrained feeling I get with Ruby on Rails. I have to override a truckload of functionality in the stock ASP.NET 2.0 controls in order to produce my favorite "CSS Zen" output. When working in ASP.NET 2.0, I feel as though I should be going through a lengthy design process to build my application, and when the design is done, I start coding. Once I produce a 1.0 product, I then start tweaking and making additional update releases. At no point during my ASP.NET career have I ever felt that I was really doing anything "XP"-like with it, whereas I feel that way by default with RoR.

In conclusion, you may note that I haven't said that Ruby on Rails is better, or that ASP.NET 2.0 is better. At the moment I am still considering them two entirely different animals. I don't know yet if there are any areas where RoR is better or where ASP.NET is better. At this point, I'm not comparing data binding,data access, or data-driven applications. I am simply comparing the experience of creating web applications using standard environments. Personally, I find the enforced use of a pure MVC pattern in RoR to be refreshing, and I can immediately see the benefits of that in any application I write.

It remains to be seen whether the MVC pattern enforcement of RoR outweighs all the benefits of having the .NET Framework behind me when I write ASP.NET code (yes, I am aware of RubyCLR, and I'm not discussing that until yet another future post).

Score: Ruby on Rails 1 , ASP.NET 2.0 1 :)

They are both really powerful web application construction frameworks and given the scope of evaluation of this post, I see no objective reason why any is better than the other. Although if we're comparing embracing of patterns, Ruby on Rails would have a slight lead because its just natural to embrace MVC in RoR whereas it takes some tweaking to do pure MVC in ASP.NET.

Click here for Round 2, Agility . 

tags: web  net  framework  ruby  rails  aspnet  asp  adonet  

links: digg this    del.icio.us    technorati    reddit