2.5. Rails vs. ASP.NET vs. ASP.NET MVC
If you are reading this book, you're probably an ASP.NET developer. However, even if you aren't, the Rails versus ASP.NET diatribe that's raised every so often in online forums and groups is worth addressing before wrapping up this "philosophical" chapter.
The "versus" question is often asked by developers who'd like to learn the "next big thing" in Web programming, be prepared for the evolution of the job marketplace, or, even more commonly, by programmers who're looking for the best tool for a certain project.
Becoming proficient in a new framework can take at least a few months, so it is understandable that most people don't want to bet "on the wrong horse."
Choices exist that are bound to become more popular and that better suit certain types of projects or development philosophies, just like there are options that are more productive than others. Switching to Rails from an ASP.NET background makes a lot of sense in most cases, so this section will help you to better understand how these two different frameworks compare from a macroscopic perspective.
2.5.1. A 10,000-Foot Comparison
From a technical standpoint Microsoft ASP.NET and Ruby on Rails are very different. They have so little in common that, at a microscopic level, a detailed list of differences would be huge. It is truly comparing apples to oranges; they are both round fruit, just like Rails and ASP.NET are both Web application frameworks, but they don't have too much in common beyond that. Taking into consideration the Rails notions introduced so far, a high-level comparison based on several aspects of the two worlds is going to be the most beneficial.
Albeit very different, whenever the occasional similarity exists between the two, this is pointed out (throughout the book) as Rails concepts are introduced, in order to make them seem less foreign. For instance, the concept of layouts in Rails is very similar to that of MasterPages in ASP.NET. Or again, the controller layer can be intuitively seen as the Rails (loose) equivalent of the Code-Behind model in ASP.NET.
2.5.1.1. Political Matters
Microsoft ASP.NET is a proprietary solution for Web development, whereas Ruby on Rails is entirely open source and ships with a very liberal license (MIT). Microsoft is slowly embracing openness, but it is far from being able to claim that ASP.NET is open source. ASP.NET works on Windows only, if we exclude the Mono project (http://mono-project.com). Mono allows you to run ASP.NET applications on operating systems like Linux and *BSD, but being a part of Microsoft's implementation, it usually plays the "catch up game" with the latest version that's been released by Microsoft. Rails and Ruby are, on the other hand, both cross-platform.
The implication is that Rails developers tend to opt for open source tools, operating systems, databases, and Web servers, whereas ASP.NET developers will usually employ Visual Studio, Windows, SQL Server, and IIS. They are two different breeds of developers living in different cultures.
The open nature of Rails-based stacks is a strong advantage that shouldn't be ignored when choosing between the two platforms; but it's up to you to decide whether these somewhat "political" considerations matter or are entirely irrelevant.
A very practical implication that comes to mind is that ASP.NET development is tied to Windows and has (with the exception of Mono) a single deployment stack that is centered around IIS. As you will learn in Chapter 11, Rails has many possible deployment stacks, most of which separate the Web server from the application server, giving you a greater deal of flexibility in deciding how the request-response cycle should be handled.
2.5.1.2. Who Uses What?
ASP.NET has the advantage of being a few years older than Rails, plus the backing of a giant corporation like Microsoft. Despite the David (literally) versus Goliath scenario, Rails is the tool of choice that's favored by most startups and independent Software as a Service (SaaS) vendors, especially in Silicon Valley, which, as we all know, is the biggest startup hub.
Its exponential growth in the marketplace implies that today Rails has even attracted the attention of the corporate world. Its market share will continue to grow, but realistically though, ASP.NET along with Java remain the most widely used solutions in the Enterprise world. In these environments, big projects carried out by large teams of developers still favor ASP.NET over Rails any day.
This has certain implications in the job marketplace. Currently there are far more job ads for ASP.NET developers than there are for Rails ones (at least outside of Silicon Valley). On the other hand, Ruby and Rails skills are very much in demand, given that there are relatively fewer developers than the fierce competition that exists in the .NET world. If you are a manager, please be advised that Rails developers are not hard to find (and visiting http://WorkingWithRails.com is a good starting point for finding talents).
The working environments in which these two frameworks are utilized are also very different. It's a good bet that Dilbert-esque scenarios are much more common among ASP.NET corporate jobs than they are in Rails startups or corporate teams that are brave (and smart) enough to adopt Rails.
2.5.1.3. Learning Curve
Based on experience, it's far easier and faster to teach developers Rails than it is to teach them ASP.NET. The technology is much simpler and more intuitive. The .NET Framework alone is a huge body of concepts and namespaces that heavily affect one's ability to get started quickly.
Try to remove Visual Studio from an ASP.NET developer and then ask him to code with Notepad. He'll probably be unable to do so. A Rails developer, on the other hand, would have no problem using just Notepad. It would be less convenient, but not worth sweating over. I think this speaks volumes about the relative complexity of the two frameworks and their reliance on RAD tools.
Even if you take the frameworks out of the picture, C# and Visual Basic.NET are much more complex to learn than a "programmer friendly" language like Ruby. Anyone who can program in both is bound to confirm this point.
Rails requires only a decent understanding of Ruby and a few specific concepts and conventions. As such, even existing .NET teams can switch over to Rails in a relatively short amount of time. And this book should help you to do just that.
Anecdotal evidence is not conclusive, but should help illustrate this point. A couple of years ago in IBM I had three bright students doing an internship. These students had never seen Ruby or Rails code before, so I trained them on both Ruby and Rails, for three days in a row. After that they started working on a project, while I provided them with mentoring support.
They wrote all the code, and after only 10 weeks, they had a complex Ajax-enabled application up and running. Those who saw the application couldn't believe that it had been developed in so little time by a trio of students. And what's more important — you guessed it — they absolutely loved working with Ruby on Rails.
2.5.1.4. Performance Considerations
Rails is written in Ruby and as such is interpreted, whereas ASP.NET is compiled. It can't be denied that this difference has repercussions when considering performance. ASP.NET tends to be faster than Rails. Just as C# is a relatively fast programming language, whereas Ruby is a slow one.
This aspect is worth keeping in mind, but not worth getting paranoid about. It only means that if you're ever going to handle very large volumes of traffic with a Rails application, it is plausible to assume that you may need slightly more hardware than if you implemented the same application in ASP.NET.
What's more important though, is that Rails allows you to develop applications faster (and simplify their maintenance) than ASP.NET can. That's your crucial gain. After all, hand-coded Assembler is drastically faster than C#, but that's not a good enough reason to favor it over C# in most contexts. There is a clear trend in the industry and it's that very high-performing, dynamic languages are here to stay.
2.5.1.5. The Issue with ASP.NET
Beyond language choices and culture diversity, which could certainly be discussed at length, a fundamental issue distinguishes ASP.NET from Rails.
ASP.NET is based on the very bad assumption that Web development should mimic desktop application development as much as possible. But desktop applications and Web applications are fundamentally different.
The act of dragging and dropping controls on WebForms made ASP.NET relatively easy for MFC and Windows Forms programmers, but it was also a terrible decision that has had far-reaching consequences. ASP.NET's evolution has been continually forced to work around that initial mistake.
For instance, it greatly complicated the request-response life cycle and forced a paradigm that is essentially event driven upon Web developers. You drag and drop the control, double-click it, and then proceed to describe what it should do when the associated event is triggered. That's not how the HTTP protocol or the Web naturally works.
That same assumption also led to abominations like the ViewState, in order to store the state of these fancy controls on the client side through a hidden HTML field. ViewState can easily be abused, and accidentally introduce serious problems. Even when Microsoft introduced the ASP.NET Ajax extensions (formerly known as Atlas) in order to inject Ajax functionalities into ASP.NET development, it was forced to do so in a control-centric manner.
Many ASP.NET developers create Ajax-powered applications by essentially dragging and dropping controls within the UpdatePanel, enabling portions of the page to be partially rendered without the need for a postback. That's very different from how the overwhelming majority of other Ajax frameworks work and it's arguably a much less flexible approach. Of course, ASP.NET Ajax provides more than just "ajaxified" controls, but many developers will still probably end up using and abusing the drag-and-drop approach due to its familiarity and ease of use.
If you'd still like the convenience of dragging and dropping controls from within an IDE into an ERb template, you can use the Ruby In Steel IDE described in the first chapter. This offers a Visual Rails Workbench, which enables drag-and-drop design without the negative consequences of ASP.NET server controls.
Rails avoids all these headaches by simply opting not to force an abstract, event-driven, and control-based approach onto developers. Through ERb templates and the information provided by the controller, the view can render HTML which, along with JavaScript and CSS, is all you really need to generate Web pages. No special server controls, a straightforward request-response cycle, and a clean separation of content and presentation through the MVC paradigm greatly simplifies development and has the added bonus of facilitating the testing of each layer. In particular, Unit Testing in Rails is fairly easy, whereas all the complications mentioned previously (which are due to that initial assumption) imply that the same can't be said for ASP.NET. Data access becomes extremely easy too, thanks to ActiveRecord. And there's no need to bind controls to a given DataSet or to follow other approaches that are typical of the desktop development arena.
Rails lets you be "closer to the metal" and gain flexibility without being unnecessarily complicated.
2.5.1.6. When to Use ASP.NET Instead of Rails
Learning to program in Rails doesn't have to be a religious conversion. In many cases developers realize how much more enjoyable Rails is and prefer to switch from ASP.NET entirely. But that's not always an option. Learning Rails will therefore, in most cases, be the equivalent of adding a useful tool to your toolbox.
Though it's possible to use Rails for just about any project, there are still times when ASP.NET would work fine and be even less problematic than Rails. To distinguish what this sort of case is, you need to learn where ASP.NET has the advantage over Rails:
Performance: The performance issue was mentioned earlier. If you need to develop a Web application whose performance is critical, ASP.NET may be the right solution. Just don't be too quick to jump to the conclusion that this applies to your application. The average social networking site, blog engine, Content Management System, or online store is in no way a performance-crucial application. As a matter of fact, these are all areas where Rails would excel.
Unicode support: Great progress has been made in the area of internationalization and Unicode support by both Ruby (particularly since the 1.9 development release) and Rails. To be fair, though, these are still far behind what the .NET Framework has to offer. If this topic is critical for the success of your application, you should carefully evaluate whether Rails' current support (including its plugins) satisfies your needs well enough.
Legacy databases: Rails' Convention over Configuration approach implies that it really works best when you follow its conventions. If you are dealing with legacy databases that diverge a lot from the standard Rails conventions, you may find yourself "fighting" with Rails and spending far too much time configuring and "convincing" ActiveRecord to work with your data. In instances like these, ASP.NET can be more productive and less of a headache.
Enterprise features: Though the number of libraries for Ruby, and plugins for Rails, is constantly growing, large and complex projects that require a lot of integration with an existing Enterprise infrastructure are probably better left to ASP.NET. For example, the .NET transaction model and message queue capabilities are far more advanced than what you can currently find in Ruby-land. Chapter 11 provides a few pointers to articles about Rails and the Enterprise.
2.5.2. ASP.NET MVC and Other .NET Frameworks
Many Web developers have come to appreciate the MVC paradigm thanks to Rails. It shouldn't be too much of a surprise, then, that so many MVC frameworks are inspired by Rails or, in some instances, are even clones of Rails, for languages other than Ruby. The .NET world wasn't immune to this influence either.
2.5.2.1. MonoRail
Several MVC frameworks are available for .NET, but the most popular open source one comes from the Castle Project. Castle (for short) includes, among other components, MonoRail and ActiveRecord. MonoRail is a clone of ActionPack for .NET. You can think of it as the VC part of the MVC triad. ActiveRecord is, as you would expect, an implementation of the Active Record pattern for the .NET Framework, and covers the M layer of MVC. Castle's ActiveRecord leverages the NHibernate ORM, but it doesn't require XML configuration.
A few .NET developers have expressed enthusiasm toward the combination of MonoRail and ActiveRecord, and opted for this alternative, as opposed to switching to a new language (Ruby) and framework (Ruby on Rails). But many who tried this approach eventually ended up opting for Rails, because it's more polished, robust, and well-documented than its .NET clone. "Why not use the real deal?" is an argument often heard, and many admit that by not using Ruby, these frameworks lose a lot of their appeal.
With this and other Rails inspired projects, you need to take into consideration that they were started later than Rails itself and have received much less attention and time in the limelight. As such, their maturity in the face of real-world projects is usually inferior to that of a well-tested framework with thousands of contributions, like Rails. For example, these frameworks may lack a few generators (one of Rails' killer features) or other particular features (for example, according to the FAQ, the current version of MonoRail doesn't offer support for caching).
That being said, and despite this being a book about Rails, you are absolutely encouraged to try out MonoRail and other .NET alternative frameworks if you are an ASP.NET developer. There is no reason why you couldn't take your knowledge and apply it to both MonoRail and Ruby on Rails. In life, as in programming, it's always worth being open minded and ready to try out possible alternatives.
In the .NET culture, developers who keep an eye open for a better way, independently from where it's coming from (Microsoft or not) are part of the so called ALT.NET movement. David Laribee coined the term in his original post that you can read at http://laribee.com/blog/2007/04/10/altnet/.
2.5.2.2. ASP.NET MVC
Following Rails' success even Microsoft took note and decided to come up with the ASP.NET MVC project, which adds an MVC framework that's similar to Rails, on top of ASP.NET, wherein the controller takes the place of the typical postback model.
This is definitely a huge step in the right direction for Microsoft and, if you're an ASP.NET developer, you may really want to try it out. It provides some of Rails' strong selling points, including the ability to delineate beautiful URLs by defining routes in your Global.asax.cs file. The same considerations made in the previous section for MonoRail apply to this project too, though, even if it's probably going to become the de facto standard in the .NET world. A lot of Rails' productivity and wow factor is directly related to the fact that the Ruby language is employed. Consequently, ASP.NET MVC applications still feel different and much more verbose than Rails ones (at least until IronRuby will be ready for prime time).
ASP.NET MVC is often considered a clone of Rails, but this is not entirely fair. It's very likely that Microsoft started the project in order to offer to .NET developers the advantages of a framework like Rails. And yes, perhaps it also did it to prevent many .NET developers from switching to Rails. Rails and other open source MVC frameworks heavily inspired Microsoft. But the final product includes bits of Microsoft's own approach to MVC and Web development, and as such it ends up being different enough so as to not feel like one's developing in Rails when using it.
Consider these alternatives, particularly the promising ASP.NET MVC, but please read on and give Rails and Ruby a shot. You may find, as many did before you, that Rails has a unique chemistry, which is hard to duplicate even in very similar frameworks.