RoR vs. Web Forms vs. MonoRail
As you know, I’ve been lucky enough to do a fair bit of Ruby on Rails development lately and well, what can I say? I’ve been spoiled! The development experience leaves me running out of expletives. I adore Rails… Especially in contrast to ASP.NET or more specifically – web forms. I have always had mixed feelings with regards to ASP.NET but now more than ever – given my aforementioned experience of the graceful RoR framework. Allow me to elaborate on some of the issues I have with ASP.NET:
The cruft to allow stateful paradigms on a stateless protocol…
… Of which there are several: post-backs, view-state and complex page life-cycle immediately spring to mind. In trying to do anything slightly dynamic with the control tree you run into view-state problems difficult to debug and frankly just not worth the bother. Web Forms and control development in general is a black art thanks to the huge and unwieldy collection of events kicking off during the page life-cycle – which nobody really understands save for perhaps God and Scott Guthrie. In trying to create an abstraction over the inherent statelessness of HTTP, which by definition should reduce complexity, ASP.NET has only served to add more. Yes, ASP.NET utterly bastardises HTTP. Make no mistake.
Code behind, beside, back-to-front etc
Code behind is a decent concept. Providing a means to remove application logic from the view – you know, seperation of concerns and all that. However, the common use for the code-behind is more often like an application logic purgatory if you will – between the final dispatch to heaven (the middle tier) or hell (the view). OK so ASP.NET doesn’t force you to put logic in the code behind but it doesn’t exactly encourage you not to? The path of least resistence is always the path most followed, which in this case means piles of code which should sit in a lower tier being present in the code behind.
It is extremely hard to write testable code in ASP.NET. Mainly due to the previous point regarding code behind. Logic creeps into the code behind where it is impossible to get to by conventional testing. Sure you can write acceptance or end-to-end tests using Selenium or some other automated UI testing tool, but i’m talking closer to the metal tests… as-in unit tests.
The built-in ASP.NET controls
Most of them are overly complex and rely on piles of viewstate to get things done. ASP.NET 2 helps reduce the payload a little via control state but this is just another quirk if you ask me. Controls produce dodgy markup (ok I’m aware of the whole control adapter thing, but why should I fix MS broken HTML?) and bizarre ID tags making cross browser and standards-based web development a real bane. Some of the other weirdness such as handling OnDataBinding and OnItemCreated etc and reaching into the control tree just to highlight a particular row or cell is a real pain. Some of the big-boy controls have this kitchen sink approach i.e. datagrid, gridview etc. The validators, while a nice concept, don’t really cut it in the enterprise world. Where you’d almost certainly be performing proper validation in your DomainModel someplace.
IDE and designer integration
ASP.NET and the .NET framework in general were created to sell tools and server licences, which is clearly evident given the tight coupling with VS.NET. Take VS.NET out of the picture and ASP.NET development is a hugely different and less pleasurable experience. Show me someone who can create an ASP.NET web application using Notepad? Of course thats not what we should be using in the enterprise but its a good benchmark for both a language, or framework simplicity.
There are things I do like about ASP.NET. I like the extensibility of the provider model, the hosting aspect, the HTTP pipeline and extensibility points such as modules and handlers are nice – especially in IIS7. It scales too, but a lot of that is due to IIS from 6 and on really.
So is there a light at the end of the tunnel? Well, yes… In the form of the fantastic MonoRail framework. Stay tuned for part 2 🙂