Top 7 Reasons an ASP.NET Developer should Consider Rails

It seems Top x lists these days are all the rage. I’d like to be cool too and present you with 7 reasons why, as I learn more and more about Ruby on Rails (aka RoR), an ASP.NET developer should seriously consider checking into Rails. This isn’t meant to say ASP.NET is bad per se. I still use ASP.NET on a daily basis, all of my projects are still being developed using .NET. It’s solid and proven. Yet I’m frustrated with it, and I’ve started learning Ruby on Rails.

This is in no particular order, certainly not in order of importance. Again, this is from a long time ASP.NET developer’s point of view.

Reason #1 – Simplicity.

I’ve found the Rails framework to be pretty simplistic without sacrificing robustness and flexibility. That’s a hard one to achieve, and Rails does it nicely. Not just Rails though, Ruby is not a difficult language to pick up and run with.

Reason #2 – A built in, solid Pattern

You’re not using a pattern based approach in your projects?? Sure you are, you probably just don’t know it. Just about every project uses some sort of pattern, and you call it an ‘architecture’. You keep building on this architecture project after project, trying to evolve it into something you have to touch less and less with each iteration of development. Rails gives you something the .NET framework doesn’t give you: support for a proven, solid pattern called MVC (model, viewer, controller). We used it (MVC) all the time back when thin client applications were all the rage but the web browser wasn’t. It just so happens to work fantastically with web development. Now, one can argue that .NET gives you the “freedom” to invent your own patterns / architecture, but let’s talk about freedom in the next reason.

Reason #3 – Vendor / Platform Freedom

I can’t begin to tell you how many potential clients I’ve had to pass up because they didn’t want to invest in Windows based hosting (and by that, I mean SQL Server, Windows 2003, Visual Studio, etc). Those of us who live in the Microsoft world day in and day out tend to develop a skewed perception that everyone hosts their web apps on Windows 2003 and everyone has a license for SQL Server. The world is a little bigger than that my friends. Many people don’t have the money to host their web apps with these kinds of setups. I’ve found in my experience though, particularly with startups, they just want to minimize their initial investment. Going with an Apache/MySQL/*nix based approach makes sense for them – it simply cuts down on up front investment costs.

Aside from the upfront costs, there’s this issue with being stuck with Visual Studio once you start using it. Web designers are good at design, web developers are good at, you guessed it, coding. Visual Studio assumes both roles will be perfectly happy using Visual Studio. I’m sure I’m not the first to say that VS sucks for designing web page layouts and interfaces. Dreamweaver is great for that. Try getting an aspx page to work with both toolsets without sacrificing their strengths and you’ll find you’d be happier plummeting off the rooftop of a 12 story building. It is painful. It is nasty business.

Rails doesn’t tie you down to a single web server software or operating system. Ruby doesn’t tie you down to a single IDE. Neither tie you down to a single database platform. Getting to use whatever you’re comfortable with is nice. Telling your clients they can leverage their existing investments is nicer.

Reason # 4 – Ruby on Rails is Modern

The more I work with RoR, I see just how un-modern ASP.NET feels. It’s the same feeling I got when I made the jump from classic ASP to ASP.NET over 5 years ago. Five years…wow, that’s a long time in our industry. ASP.NET hasn’t changed terribly much in 5 years. Sure, we don’t have to compile our web apps any more. And sure, ASP.NET has AJAX extensions. Yet it still feels like the problems we had with ASP.NET 1.0 are still there in 2.0. The same old workarounds are still necessary to make my javascript work correctly when I use master pages. Why is it, after 5 years, I still have to work around the issue of only being able to use ONE server side form per page? Do you know how much that sucks when you’re using master pages? Why is it that after 5 years I still have to write a ton of back end code to replace the 50% of ASP.NET controls that are worthless unless I use a two tiered databinding approach (which no developer worth his salt would use)? I’m getting off on a tangent here. The point is, Microsoft isn’t modernizing ASP.NET to keep up with the modern trends. Oh, trends, let’s talk about that for a moment in……

Reason #5 – RoR is Trendy

If you’re an IT consultant this should be an important one for you. The key to our success is to stay fresh, a step ahead of the game, and on top of things. RoR is the next big thing, and now is the time to hop on board. Just look at some job boards lately – the .NET market has become insanely saturated. It’s the never ending cycle that drives our industry to innovate. It’s also the cycle that makes our industry fun. Yet it’s also the cycle that we need to constantly be aware of and not become complacent with any single technology / platform.

Dare I use the term web 2.0? Yes, I do dare, because that’s the term we use when we want to describe a set of ideas and technologies that make up modern web apps. What does ASP.NET provide for us dedicated developers to web 2.0-ize our apps? AJAX extensions? I’ve been using those extensions since the very first beta of ATLAS, and they still suck. That’s right, they suck. The performance is crap. AJAX is built right into Rails. Built right smack dab into the framework because that is what we should expect from a modern toolset.

Reason #6 – Rails is easier to Test than Not Test

Here’s what some of us do in the ASP.NET world. I’m not saying I do it, or you do it, I’m just saying a lot of people do do it.

We write some code, develop some web pages, fiddle with our middle tier, compile it, slap it on a test server, and tell our client to go check it out. They check it out, and send you an email saying “When I clicked this button I got an error”. We look at the error, look at the page, realize the client was stupid and put the date in backwards before hitting submit (silly UK client). We throw in a date validation and publish the page again. Send our client an e-mail explaining the issue, and wait for more feedback. The client replies to the email saying “Okay, thanks, but when I clicked submit this time I got this error”. We look at it, and realize the stupid client didn’t actually select an item in the drop down. And thus continues the cycle until the client has lost all confidence in your application.

Now, I’m not saying Rails prevents developers from developing in such a shoddy manner, but what I can say is that Rails makes it dead simple to test these scenarios and find these sorts of problems before your client does. That’s a great thing.

Reason #7 – Ruby on Rails is Fun

Fun? FUN? What does that have to do with anything? Well, we’re programmers because programming at one point was fun and exciting. We cherish that first time we wrote a silly little BASIC program with all those horrible gosubs and it worked. We showed it to someone who pretended to be impressed that you wrote yet another calculator, and it added fuel to the fire. Somewhere down the line programming ceased to be fun and became more like work. It became more like a chore of redundant donkey work that paid the bills. It still had some sparks of that initial excitement from project to project, but overall it became…well, boring. But wait, why am I using past tense here?

Simple – I discovered Ruby on Rails and it’s a lot of fun.

More to come soon.

Explore posts in the same categories: Tressel