So, I expect most of us have seen both halves of that comparison. Two questions:

• If you were trying to sum up the value of RoR to a hardcore ASP.NET professional, how would you do it?
• Given that no one system is perfect for anything, how would you split up the universe of Web projects into “more appropriate for RoR” and “more appropriate for ASP.NET”?

The first one is hard to answer in a sum-up sentence, even though I’ve been asked this many times.

I think the best way to explain the value of RoR vs. ASP.NET is what you don’t do in Rails. This is a hard way to get the point across, because working with MSFT stuff makes you think in terms of features and what you “can do”. In Rails, it’s what I don’t do that appealed to me so much.

Typical ASP.NET app: design your DB tables in SQL Server. Write code which maps your data into .NET classes. Write your front-end pages with the crazy postback event-handling model (and may I add, I think 50% of most ASP.NET devs at this point don’t really understand how an http request hits their code). Then, write some more code to get the pages working with the data classes. Need to support an XML API? Write some more code. And I’m not sure, but I don’t think there’s an easy way even in ASP.NET 2.0 to expose a SOAP service from all that work you’ve already put into your website – even though you’ve got all your business logic and data access already written – so you’ll have to factor out your code and start a new WebService project to implement your SOAP endpoint. Oh, and along the way you have to decide where all your code will go, what coding conventions to follow, and come up with your own testing methodology.

Typical Rails app: use scaffold_resource to generate a REST-compliant architecture for each resource; you can generally get your migrations for free if you already know the columns you’ll need up front. You don’t write your own code to provide a REST XML API. You don’t have to do much more than tweak the existing controller code that’s generated for you. Just write your html. So the coding you do is focusing on your specific problem domain, instead of laying plumbing (the same plumbing you’ll need for every web project).

So that’s my shot at answering #1… the value is in what you won’t have to do anymore. (Plus you get an http request/response model that’s whole lot easier to understand… and repeatable database schema changes… and easy unit testing… and you’re always in one language, Ruby, for everything, including most Ajax work….)

A major difference of the ASP.NET mentality/culture didn’t become clear to me until we did our training class last month. I was hand-coding HTML to illustrate a simple example in Rails, and a couple people cried out: “Why are you doing it the hard way?” (As opposed to using something like scaffolding).

And it hit me. Microsoft has invested a lot of money into making sure that your web development experience is, in many ways, very similar to your desktop application development experience. And your mobile device development experience. And so on. Trouble is, it is different. It’s supposed to be different. It’s the web. The language of the web is HTML, CSS, Javascript, etc. It’s not drag-and-drop “controls”. That’s the language of desktop development. ASP.NET was originally built to abstract all this stuff away from the developer by adding stuff like drag-and-drop controls, event handling, etc. It was built so that the average VB developer writing a line-of-business app for his/her company could easily write it as a web app as well.

Don’t get me wrong. All this hard work done by the ASP.NET team is great for someone in that situation. If you’re a mid-sized company that’s made a 10-year investment into a team of VB-turned-ASP.NET developers, there’s a pretty compelling argument to not make a switch to any other technology, including Rails.

I’m trying to figure out how to answer this question at work. It really all depends on whether that .Net professional is open to alternate solutions. Most .Net developers that I know are too scared of jeopardizing their job security to start investigating other technologies.

Assuming that you’re dealing with a developer that is interested in expanding their boundaries, I would start with CRUD as a selling feature. For a web app that uses a lot of CRUD-based forms (i.e. editable datagrids) along with some basic searching functionality, RoR kicks ASP.Net’s butt all over the place. The convention over configuration in RoR just cuts through all of the setup costs that ASP.Net will give you. Even if you look at ASP.Net with NHibernate, you’re still spending too much time updating xml mappers.

If your hard-core ASP.Net person is also into the latest buzzwords, you can talk about how RoR allows you to be agile easily (scaffolding is actually a good sell here), has unit testing built right in, and has AJAX functionality that ASP.Net can only dream of (Atlas/AJAX does a pretty good job but is still clunky and full of configuration settings). Then when he’s swaying back and forth like a punch-drunk fighter, hit him with the REST support in 1.2.1 and knock him out.

Of course, if your developer doesn’t care about these approaches then you’re probably screwed anyway. :)

Brian’s comment is definitely spot-on. Personally, I like coding HTML and RoR lets me feel “closer to metal” when it comes to HTML, CSS and Javascript. ASP.Net feels way too abstracted if you’re a person who actually likes to use the Source view rather than the Design view.

This quote from Jeff is the key: “(and may I add, I think 50% of most ASP.NET devs at this point don’t really understand how an http request hits their code).” I could tell at the workshop that Brian (and Jeff) had an understanding of how http really works, and that was a big draw for me.

“And I’m not sure, but I don’t think there’s an easy way even in ASP.NET 2.0 to expose a SOAP service from all that work you’ve already put into your website – even though you’ve got all your business logic and data access already written – so you’ll have to factor out your code and start a new WebService project to implement your SOAP endpoint.”

Actually, creating or consuming a web service in .Net is really easy. Just add [WebMethod] CLR attributes to your methods, make sure the returned type is serializable (which can be as easy as adding a “Serializable” CLR attribute), and you’re done. To consume a service, just add it as a web reference to your project. Corresponding classes are generated automatically, as wel as synchronous and async execution methods. Need security? Instla WSE and start using the whole breadth of WS-* protocols. Need to call your service using AJAX? Just mark the method with a “ScriptMethod” attribute. Client-side methods, async event handlers, JSON serialization are all done behind the scenes.

“come up with your own testing methodology.”

If you’ve got the $$ for it, VS Team Suite offers Unit Tests, Web Tests, which can be reused to generate Load Tests. It’s actually pretty good…

One more thing I couldn’t live without: Visual Studio Intellisense.

“One more thing I couldn’t live without: Visual Studio Intellisense.”

You don’t have to! We have Visual Studio, Ruby and IntelliSense all wrapped up: http://www.sapphiresteel.com For IntelliSense info see: http://www.sapphiresteel.com/IntelliSense And: http://www.sapphiresteel.com/Evaluating-Ruby-IntelliSense And maybe a screencast or two for good measure ;) http://www.sapphiresteel.com/Ruby-In-Steel-Movies

best wishes Huw

Microsoft has invested a lot of money into making sure that your web development experience is, in many ways, very similar to your desktop application development experience. And your mobile device development experience. And so on. Trouble is, it is different. It’s supposed to be different. It’s the web. The language of the web is HTML, CSS, Javascript, etc. It’s not drag-and-drop “controls”. That’s the language of desktop development. ASP.NET was originally built to abstract all this stuff away from the developer by adding stuff like drag-and-drop controls, event handling, etc. It was built so that the average VB developer writing a line-of-business app for his/her company could easily write it as a web app as well.

that’s exactly the problem I’m facing going the other way. ASP.NET is not a web application language imho – the controls are desktop controls, just using microsoft’s x/html schema to output the code. Forms are not server side elements to hijack in x/html – they’re elements on the bloody client side to give a framework to pass information back to the server. The mash of desktop jargon, words and “viewpoints” with the web leaves me wanting the control I’ve always had before but don’t seem to be able to in .NET

It really all depends on whether that .Net professional is open to alternate solutions. Most .Net developers that I know are too scared of jeopardizing their job security to start investigating other technologies.

zing!