Selecting the right technology

I mentioned about the idea that I had for an application. Since an idea not executed, is just that, I was keen to at least test drive this idea. And that meant it had to be built.

If I was sitting on a pile of money, I would have hired a team that would have gone about building this app, dedicated to it. But since that was not the case, there were a few decisions that I had to make in selecting the technology.

There were a few criteria whatever the technology I select had to fulfill.

1. It has to be a lasting technology stack. I don't want to build a new app using a technology that is deprecated or on its way out. This application will be (hopefully) going through many iterations and improvements. And I don't want to be forced to do a complete ground up re-write anytime soon.
2. It has to be something that can be run on a shared or cheap hosting platform. It is not going to be launched in its own servers. I will have to bootstrap the operational costs for sometime and that means hosting has to be cheap.
3. It has to be easy to learn this technology stack or framework. The key reason being, since this is going to be built as a side project, I want to minimize the time spent learning a new technology rather than building the app.
4. It has to be cutting edge. This is a key requirement as as much as the solution, I am attracted to elegant and cutting edge solutions. I want this app to be a case book of good practices and cutting edge technologies.

There were two choices. RubyOnRails (RoR) and ASP.NET MVC.

I have been interested in RoR for quite sometime. I like it’s elegance and the design principles like convention over configuration. I think RoR is a great framework to build web apps. I wanted to learn this framework and move beyond the standard ToDo app that the learning examples provide.

Developing a real world application is a great way to master a new technology. And this would have been the perfect opportunity for me to master RoR.

BUT, I decided to take the ASP.NET MVC path instead. And my justification goes like this:

Developing with RoR will require a significant learning curve. While one may argue that RoR is really easy to learn, from my experience the caveats are hidden in little details. When you want to move beyond the standard example application that’s where the learning curve gets steep.

Secondly, I am not familiar with the hosting environment RoR requires. I am a little scared of Linux/Apache still. (Yup, I am a MS junkie)

Then there is S#arp Architecture (pronounced sharp). This is framework built by integrating some of the best open source frameworks and built on top of ASP.NET MVC. And it has a huge RoRness. So I am getting some benefits of RoR in a framework that I am already partly familiar with. My experience with nHibernate was also another force that pulled me towards S#arp.

So it is final, I am going to build my new app using S#arp and oh did I mention MySQL. Yeah, MySQL it is. Nothing beats free!