I've long thought that the spiritual difference between RoR and ASP.NET is that one is built by application developers, and the other is built by language and framework developers.
Indeed. Though you'll note that ASP.NET is conspicuously absent from my list of nightmare monstrosities.
Not because it's not a nighmare monstrosity. It's the posterchild for nightmare monstrosity frameworks. But it's unique in that if ignore roughly 95% of the "point and click your way to unmaintainable intranet sites" garbage, what's left is pretty much pure awesome.
Deep in the center of the hairball is a tight little framework for building websites that has access to a really good, really big library that can do pretty much anything you'd want to do with a computer.
So it's both terrible and awesome at the same time, depending on whether you know which bit you're supposed to use. I wouldn't be surprised to find that there was a team at Microsoft somewhere using that small bit to build stuff and guiding the project just enough to make sure none of the good got mangled by the tons and tons of bad.
I can't agree with that at all. ASP.NET even after you remove all the point-and-click crap is still a mediocre web framework at best and arguably horrible in a number of crucial areas. One thing it is not is "pure awesome".
1. It isn't nearly as extensible as Rack and Rails. I mean not even in the same zip code.
2. It is not a very testable framework to work with. The ASP.NET abstractions are horrible for this, while the .NET MVC ones are better but still suffer due to all of the issues with the testability of the core of ASP.NET. Most of the testability abstractions that modern ASP.NET does have were added purely as afterthoughts, and awkward does not being to describe working with them.
3. ASP.NET regularly violates the "principle of least surprise". One of my favorite examples is where the HttpContext class throws an exception from the `.Request` property getter if you attempt to access it during the application startup (ironically it is actually starting up in response to a request so this is both confusing and inconvenient in addition to being bad API design).
.NET MVC is a poor man's Rails and working with it is merely a far more verbose and complicated way to accomplish the same thing. It is far less extensible, painful to test and automate around and has a far weaker OSS ecosystem around it.
I could honestly, go on. I worked with ASP.NET for years before moving on to Rails and occasionally node.js (though I'm really not all that big of a fan of callback coding).
I suspect the "pure awesome" part is at the IHttpModule and IHttpHandler level, where you can do everything except receive and produce grievously invalid HTTP requests. If you need to do that, IIS is extensible via WCF to host more than HTTP.
If you don't use the legacy static accessors like HttpContext.Current, it's actually quite testable. HttpContext.Current is especially bad because it uses thread local storage, so you have to be very careful about when and where you access it.
I may be telling you things you are already well aware of, but ASP.NET MVC is a separate framework that removes 99% of the utter crap that came along with ASP.NET WebForms, so there definitely is a team at MS that sympathises. To go even further, Nancy.fx is a third party framework that gets even closer to the metal.
I still have enough of an undying love for the C# language that I dream of running Nancy.fx on Mono, on Linux, giving me the best of at least three worlds.
