February 13, 2010

Abstractions, Abstractions, Pile Them On

In my modest experience as a web developer using ASP.NET, I have gone through several stages of comfort and happiness with Web Forms, most of which I assume are pretty common:

  • Amazement at how little code or markup you need to write in order to spit out a bunch of html
  • Confusion over this “Postback” thing
  • Slowly growing comfort with the “Page Life Cycle” and its foibles
  • Eagerness to use more controls, especially those new-fangled “Ajax” ones
  • Happiness over how quickly pretty good applications could be written
  • Frustration at the quality of the html that gets spit out
  • More frustration over state-management (view state? session variables? hidden form fields? cookies? client-side caching? server side caching? AARRGGHH!!)
  • Yet more frustration with the hoops you have to jump through with the Page Life Cycle
  • Even more frustration with the Update Panel and the general clumsiness of ASP.NET Ajax
  • Hope that tools like jQuery will help deal with the above frustrations

You may have noticed a trend. :-) Like many, I think I have grown slowly weary of the idiosyncrasies of the Web Forms engine and its “Leaky Abstraction” problems. In our zeal to abstract away the complexities of a naturally stateless web environment, we’ve accepted abstractions piled upon abstractions piled upon more abstractions.  I can’t help but feel we’ve arrived at a point where, despite creating abstractions to simplify web development, the weight of the abstractions (or, more precisely, the weight of the leaks) have complicated things more than they’ve helped.



Of course, I’m not the first to realize that ASP.NET is a leaky abstraction. And I’m certainly not suggesting that the abstractions shouldn’t be respected. On the contrary, I understand that the tall abstraction pile helps us build better software. But, as Eric Sink says:
This is what programmers do.  We build piles of abstractions.  We design our own abstractions and then pile them up on top of layers we got from somebody else.  Abstractions can be great.  We use them because they save us a lot of time.  But abstractions can also cause lots of problems.  They're never perfect, as Joel Spolsky explains in his excellent article on "The Law of Leaky Abstractions".

But you can't have the benefits of an abstraction without its risks.  We need to make wise decisions about our piles of abstractions.
So, we’ve built layer on layer of abstractions, some layers created solely to fix problems created by other abstractions. And it can get very confusing just keeping them straight.

Consider this recent question on StackOverflow concerning view state and dynamically loaded controls. The developer is using an Update Panel (abstraction of Ajax functionality) holding a Panel (abstraction of a div) on a page with manually updated view state (abstraction of application state). Sometime during the page lifecycle, the developer wants to add dynamically loaded controls (abstraction of HTML elements), but during the postback (abstraction of a stateful event), the controls lose their state. He’s using somebody’s example as a reference, but with a slight difference. What can he do?

This entire situation exemplifies what happens when we pile too many abstractions on top of one another, such that we end up with so many leaks that we don’t know how to resolve them. Yet, what’s our first impulse when trying to help? We suggest to try yet one more abstraction. This, to provide page functionality that (if done with different tools) probably wouldn’t need any of the abstraction layers that are getting in the way.

I can certainly see, therefore,  the attraction that many web developers have to ASP.NET MVC. It, unlike web forms, accepts the fact that the web is primarily a stateless environment. It is able, therefore, to strip away many of the abstractions we’ve built to simulate a stateful environment. To be fair, many of the frustrations we have with the current version of web forms are being addressed with ASP.NET 4.0. And MVC adds a few new abstractions of its own. But still…

MVC has a few paradigms that may be tough to learn for those whose experience is entrenched in web forms. Gone are the training wheels, and that scares some, and frustrates others (I’ve got to learn something else now?). On the whole, though, using MVC feels like a more natural way to develop web applications. It sheds many of the abstraction layers that web forms has built up for us, and in turn feels less complicated.

At least, so far. Let’s see how long that lasts. :-)

GPFKURH6UEK9