The Fragile Genius of Webforms
Turning Desktop Developers into Web Developers
I’ve been doing a lot of Webforms (ASP.NET) development over the last four months, as I’ve mentioned in some posts. Before that, I was doing a lot of WPF development for desktop applications and before that a hodgepodge of things that included web development with the Java stack. I had done very little with Webforms (though I had dabbled with a couple of internal corporate applications), so wrapping my head around it has been interesting.
For those of you not familiar with the way Webforms works, it could probably best be summarized as “helping you write web applications without realizing that’s what you’re doing.” Okay, that might be a bit snarky, so let’s go with “making windows desktop developers comfortable with writing web applications.” (in particular Winforms developers). It goes out of its way to create an abstraction layer that represents web concepts as their desktop equivalents which, I believe was done with the intention of easing the transition of a generation of Winforms developers to web application development. And, well done. I think it was wildly successful at that.
Indeed, it’s quite possible to write code for Webforms apps without understanding anything about HTTP, statelessness and the client-server nature of the web and understanding next to nothing about Javascript, HTML, and CSS. Instead of these concepts, Webforms developers are deal with concepts like “button click event” and “user control” ala Windows desktop development. It’s really quite a concept — “keep doing what you’re used to doing, and we’ll handle transforming the result from desktop apps to web apps.” It took me a while to stop wondering when I’d stop writing everything with wizards and datasources and gridviews and start outputting some templated markup with binding logic. It happened in trickles and drizzles but never really at all beyond that.
If your web experience is in any other technology, you’re certainly used to a less monolithic approach. Rather than “controls” that generate reams and gobs of HTML/CSS/Javascript behind the scenes, you’re no doubt used to the template approach where what you’re looking at is more or less HTML but with some notation for binding to a model and handling core concepts like iteration, validation or missing data. Perhaps there is also some notion of inline script execution. This is definitely how life works with technologies like JSP, PHP and even ASP.NET MVC. Developers using those technologies understand and embrace web as a delivery mechanism and architectural component and divide work up accordingly.
But not with Webforms. Webforms evens the playing field using wizards, WYSIWYG and extremely involved abstractions to make everyone working on a Webforms project a Webforms developer. Webforms actually abstracts understanding of underlying concepts away from the developers in this fashion, the way that Front Page and other such code generation tools have in the past. Karl Seguin gives an excellent Webforms vs ASP MVC summary that touches on these points and others.
A Brief Foray Into Architectural Philosophy
Persistence technologies, messaging/communication with externalities, web vs desktop are all non-core implementation details. Oh, don’t get me wrong, they’re important. But ebay doesn’t have an Oracle DB application or even a web application — it has a consumer resale application. The core of their business is enabling resale and that transcends the current technology stack. If Oracle went out of business tomorrow and a unified web became passe, ebay would no doubt try to soldier on by switching to MySQL and peer to peer app communication (or whatever). If people stopped wanting to resell goods, on the other hand, ebay would be kaput.
To staff a project that scales beyond tiny (i.e. multiple developers and up) a sensible way to divide up the work is to have some core business rules programmers and then others specializing in various satellite aspects of the application. So ebay might have people that develop server side application/business logic, people that specialize in Oracle stored procedures and people that specialize in web as a delivery mechanism and it would be expected that those people be domain experts, database experts and web experts, respectively. (Not to say that there couldn’t be some fluidity among these groups according to skill-set or availability and learning curve).
This separation of skills required in a team environment allows for the pairing of team members with tasks for which they are best suited. These pairings, in turn will naturally tend to foster productive collaboration, division of labor and generally good morale. People, especially knowledge workers like software developers, prefer autonomy and that tends to exist in greater abundance when each team member has a unique skill set that he or she is applying. A project with an architecture like the one I’m describing is more likely to be staffed by happy and productive developers.
Webforms and Generalist Mediocrity
Webforms does not lend itself well to the sort of architecture that I’ve just described. It invites developers to use controls that completely automate and obfuscate the generation of client side markup and scripts. But beyond that, it invites developers to describe the persistence layer in the specialized markup as well (the various “data sources” and their wizards), in effect flattening the application and rendering it monolithic. As such, Webforms developers can be (can be — not must be, please don’t misunderstand my point) relatively low-knowledge generalists whose only specialty is, well, Webforms. Webforms itself is the one with knowledge of different application layers and architectural patterns.
Whoah. Let’s think about that for a minute because it’s actually fairly profound. In a Webforms project, it is Webforms itself (or, more accurately, the people who designed ASP.NET) that understands the technologies involved. Webforms is your most knowledgeable ‘stakeholder’. Most successful frameworks and architectural technologies offer a cafeteria plan of sorts to let developers pick and choose what they need and want and to allow people to be paired up with particular facets of an application (a lot of IoC containers and various toolkits have this property). They empower developers. Webforms instead offers them a crutch — a way to perpetually develop applications without really understanding how they work.Imagine that you owned dogs all your life but decide you want a cat. Now imagine a team of engineers coming along to ease the transition. They build a wooden “Trojan Dog” with a litter box in it so that you can “walk the cat” to get it to go to the bathroom. They build a sound altering muzzle so that when the cat meows, it sounds like a bark. They give you toys and pants loaded with catnip so the cat will ‘retrieve’ the toy and bring it back to you in game of ‘fetch’. In short, they create all manner of pretty elaborate and impressive adapter tricks to allow you to own cats and pretend that they’re dogs. They probably also do a bit of hand-waving when asked why this scheme makes any sense.
The Genius And Fatal Flaw
Like the hypothetical “dog to cat transition technology”, the Webforms abstraction of all things web is impressive. It’s impressive for a group of developers to be able to create a technology that allows tens of thousands of people to write applications without really understanding the underlying technology stack (again, not in all cases — just saying it’s possible). It’s impressive for those developers to create something that allows other developers to generate a radically different type of application without having to learn much in the way of new skills. I can’t overstate that — it’s amazing.
But the same thing that makes it amazingly effective at bringing old school Winforms developers into the 21st century also limits their growth and that of the applications that they produce. Webforms is a “helicopter parent” that doesn’t, on its own, know how to stop telling its 17 year old child when it’s time to brush his teeth and wash his face, and thus it runs the risk of perpetuating learned helplessness in the same. The internet is no longer new and alien, and our web development toolbox should reflect that.
ASP.NET MVC is slick, powerful and impressive as a framework. Developers should be comfortable with Javascript, HTML and CSS if they work on the client side. Developers should be familiar with IoC, communications protocols, decoupling and testing if they work on the server side. They should be using frameworks to enhance their knowledge and speed their work and not to handle everything for them so they don’t have to understand. It’s time to appreciate the genius of Webforms, acknowledge its importance, and wish it well in retirement.
[…] Webforms See Winforms. Webforms is very similar in terms of framework testability, and for pretty similar reasons. Webforms is arguably even harder to test, however, because it’s predicated on spewing out reams and reams of HTML, CSS, and Javascript while allowing you to pretend you’re writing a desktop app. I’ve talked about my opinion of this technology before. […]
I really am impressed with the developers who created Web Forms. It is certainly very ingenious. I appreciate the issues with separation of concerns but for small teams or single developers I still find Web Forms hard to go past for quick development. But, as much as it is touted as being simple for non-developers or non-web developers to create applications using Web Forms, from my experience it is only simple to create simple applications. Creating even moderately complex web applications in Web Forms needs significant experience and knowledge of things like the page lifecycle and ViewState. I also don’t… Read more »
It sounds like we have somewhat different taste in frameworks (I’d prefer to instrument MVC or a similar framework for rapid development if I were going that route), but I definitely can empathize with it being a bummer to find a tool you’ve gotten value out of over the years falling into sunset/abandonment.