ASP Web Forms - the favela of Web Programming Environments

Update: If you arrived here from reading .NET Culture Shock: Why .NET Adoption Lags Among Startups you might be interested in reading my followup to that article which is more relevant to Aarons post.

I am back in college for second semester, and they have put on an Introduction to ASP.NET course. Its an interesting perspective on the internals of the Microsoft Stack, and there is a lot to like about some of the technology there.

That said there is a ton of junk in there too. In trying to be all things to all men, from web novices to large scale web architects there are a lot of different ways to do the same thing. While the newer entries into the stack might receive all of the attention, like LINQ and ASP.NET MVC, the entry path for many is likely to be through Web Forms.

I don't think that there is anything that I can add to the debate on Web Forms. A bad idea - to make web programming easy, we pretend that its just like making VB desktop applications. If this was truly easy I could see the appeal - you get an easy to use environment for making non-critical web applications. But there is a lot of ceremony in writing Web Forms- its not as easy as its made out to be.

Its underlying computing model is a really bad model for the web, and when you combine that with an inexperienced user base who use it as a crutch into web programming, you will end up with a recipe for pain and suffering. People who struggle to make their web app 'just work' will tear their hair out when they revisit their code.

When you start comparing it with modern web frameworks it is hard to see where it adds much benefit, beyond overstated advantages like removing the need to learn HTML. Many of the features added in newer versions of .NET seem to be fixing problems introduced in the earlier versions.

I am not religious about web stacks, and this isn't an anti-MS rant. Like I said there is a lot of interesting technology in the .NET stack, it works well for making small inside-firewall intranet apps, and it does scale all the way up to largest sites on the Internet. But the entry level skills (visual designer, web controls) are not the first step in a learning experience that will furnish you with the ability to handle any web project.

In fact they are quite disposable. Diminishing returns kick in when you start to publish your projects to the web - a hostile place where you need to know how the web works. The tools allow you to throw sites together really fast, but leave your debugging time static. In fact the highly abstracted programming model probably makes it worse.

This is my beef with it. There should be a natural progression between the nursery, quick and easy tools for throwing simple sites together, and the tools that you need to build more ambitious, robust projects. But in reality there is a discontinuity between the entry level tools and methods and the tools and techniques you use for more advanced web development.

I suspect that this results in a segmented ecosystem for .NET development. With a professional approach for larger public facing web projects, and an ad-hoc environment for smaller web projects built/maintained by consultants and in house staff. For projects of the latter, I imagine they incur technical debt like crazy. Eventually they will get to the stage where all effort applied to them gets sucked into maintenance, and it cannot develop any further. Hence the favela metaphor:

 

Anecdotally I see a lot of things that support this. Contract positions offered for maintenance work like upgrading .NET versions, porting asp -> aspx and shop talk from practitioners. In addition some of the example code shown to beginners (including some of the material shown to us in the course) reinforces a lot of bad web habits.

With .NET MVC and LINQ, Microsoft are borrowing quite heavily from the playbook of other successful web stacks. This is ground that I am familiar with, Ruby on Rails made MVC popular on the web, and did it with an implementation that makes sense to the application programmer. However it was certainly not the only or even original framework for doing MVC on the web. The concept isn't actually that hard to explain. Critics of the Rails approach sometimes highlight the explosion of files that a generator makes for even a simple Rails site. Those same critics get silenced pretty fast by single source file Sinatra MVC examples.

MVC on the web is very easy to understand when done right. Controller code is mapped to URLs which load/update models, which then send back updated View code (HTML). Web MVC is considerably easier to understand than regular desktop MVC - URLs are less ambiguous than the intricacies of desktop UI technology.

I was hoping that this, being newer and more web friendly than classic .NET might represent an upgrade path. But it appears that its a clean break, with the Web Forms abstractions completely deconstructed. Technology only suitable for green field ASP.NET projects.

Whether .NET MVC or LINQ was useful to learn inspired some healthy debate in our course, and I was a bit surprised that I was the only one enthusiastic about it. Latest and greatest technology experience correlates hugely with better work, and .NET MVC and LINQ are well thought out technologies in an area where there have been a lot of successful predecessors (ActiveRecord, Rails, Django, Hibernate). Having a quality Model layer (the classes that represent your database) is enormously helpful in controlling the code bloat of your application. It is also a natural point for gateway code, like validations, security considerations (HTML/SQL escaping) and helper code.

This is an obvious win for me, but nobody else appeared convinced. Many of the arguments to the contrary was the LINQ was redundant if you already know SQL, and .NET MVC forced you back into the realm of embedding script into HTML.

A theme that came through was the desire to economise on learning. Learn an essential set of skills well, but investing in skills with an apparent overlap was a hard sell. Or perhaps when you are working in an environment where your bandwidth to learn more is strained you have to budget or ration it harder. Like when technical debt sucks all development work into maintenance. Or when development is not a core competence of the organisation - the need for continuous learning is not recognised or valued, or the work is done by people for whom development is not their background or specialty.

It sounds snobbish, but I understand the attitude to just get something to work. Visual web programming sounds great when HTML and CSS intimidates. But there are a lot of people suffering because Web Forms gave them too much rope to hang themselves with, and there is no transition path to get them back into a productive mode.

Until tools like these arrive, ASP development with Web Forms is going to follow a fairly predictable curve. Early rapid success, followed by a far too early productivity plateau. The only ways to avoid this are to beef up development competence considerably, or abandon the Web Forms model in favour of more traditional HTML crafting.