Sunday, June 8, 2014

ASP.NET vs RoR

ASP.NET? Why would anyone compare RoR to ASP.NET? The startup community has mostly dismissed ASP.NET based on the belief that Rails is a much more agile stack. Much of this applies to the Java stack as well.

One of the biggest reasons to not use ASP.NET is because it came from Microsoft. Some common gripes include not open source, letting Microsoft control your destiny, cost, and Windows servers. While this may have been true, Microsoft has recently open sourced a large portion of their system, and the cost is negligible for the first 3 years with BizSpark. Plus, the costs aren't that bad. When we look at the efficiency of .NET vs any Ruby platform, .NET is clearly fast enough to cover the Windows licensing costs. Some of the more adventurous ones will use Mono to run .NET on Linux, but I prefer the stability and speed of Microsoft's .NET over Mono. I will agree, however, Windows servers are annoying to manage. I haven't had experience with Linus machines, yet, but I don't like giving up so much of my RAM just to run Windows. I don't think Server Core is 100% ready, yet, since many non-Microsoft components still require the GUI.

Once we get over the fear of Microsoft, many people cite Ruby as one of the biggest advantages. Ruby being a dynamic language makes it the most agile. I wholeheartedly disagree with this one. I have loved Python for a few years, but that was because I was using C++. C# (and even VB.NET) has changed quite a bit over the years. C# is capable of being dynamic as well, but I don't like what I give up there. With type inference, lambda functions, extension methods, and LINQ, it's not that bad anymore.

Plus, I think the biggest gain to productivity is the compiler. I agree waiting 10 seconds to see a change reflected in the browser is annoying, but there's a huge number of tests I don't have to write because of the static type system. When I change something, I will know all the places I broke because the compiler knows. Moreover, I can't make typos anymore. Between IntelliSense and the compiler, it's impossible to type in a variable that doesn't exist unless I choose to be in the dynamic land. Those in the dynamic world would need to write a unit test for these things. I get them simply by declaring a class.

A huge draw for Rails is convention over configuration. I think this is great to a certain point. The obviously correct choices should be done by convention, or at least auto-generated configuration. However, I think there are many obscure conventions that at not obvious, and more importantly, not how I want them. For example, I don't want my view files in a separate folder from my controller files. Why can't I have them right next to each other like ASPX and code behind files? They are logically tied together, and separating them by location is just annoying. (This also applies to ASP.NET MVC, and it's very annoying in large projects.) Instead of setting a bunch of configurations to get started, I have to learn a bunch of conventions. Sure, like all other noobs, I will start by just glossing over all the magic, but they're going to come bite me later. I don't like getting bitten by decisions I didn't choose to delegate.

The huge library of gems lets developers get additional functionality for nearly free. This is also cool to a degree. The cost changes from re-inventing the wheel to learning documentation and traps. At least having gems gives me the choice of outsourcing the functionality or not. That's cool. The .NET world is sorely missing these gems. Something that helps alleviate this problem is that many integrations are now moving out of the core stack into JS libraries or web services.

But I am willing to try out Rails for a while to see if it's really as amazing as the community thinks it is.

No comments:

Post a Comment