Ayende has tried to explain why he doesn't like ASP.NET Webforms many times, but based on the comments that pop up on his posts I'm not sure if he's successfully getting his point across. I'll try to help him out in this instance, as I think the same way about not just Webforms, but most other view technologies. This will take more than one post, however, so hopefully I can convince myself to increase my stunning post frequency of the past year in order to properly delve into this issue.
First off, let's take a paragraph or two for a brief refresher on HTTP, the protocol that drives the Web as we know it. This will be quick, and I guarantee it will be dirty...
The HTTP protocol
HTTP is based on a request/response model between a client and a server. The client is assumed to be a web browser in this instance (but can be anything really), and the server is a central location (IP address, domain, URI etc) on the Internet that responds to requests made by the client(s). Responses are generally sent back as HTML documents, but can also be XML, JSON or anything else, really. Each response tells the client what format it is sending via the Content-Type response header. There are many other response headers that provide clues to each client as to what it should do with the body of the response.
When a client makes a request to an endpoint, it specifies a verb that provides a clue to the server as to what the client wants it to do. These verbs are as followed:
- GET - Means that the client is simply requesting to retrieve whatever information resides at the endpoint URI.
- POST - Used to send information to the server, which the server can then use to do things like update a domain object. When a POST request is completed by the server, it can send response back in the form of 200 (OK) or 204 (No Content), or more likely a redirect to another URI.
- PUT - Rarely used and not very well supported, this verb is similar to POST in that the client sends information in the request that it expects the server to act on.
- DELETE - Also rarely used, this one is pretty self explanatory. The expectation of the client is that the requested resource will be deleted.
The modern web generally just uses the first two verbs (GET and POST) to get things done, although the latest version of Rails fakes out the PUT and DELETE verbs to more closely match the intended spirit of HTTP. One thing that you may notice is that GET, POST, PUT and DELETE look an awful lot like CREATE, READ, UPDATE and DELETE, but that's a "coincidence" for another post.
The way this stuff all gets mashed together to create a usable application on the web is only slightly complicated at the lowest level. In a common use case, a user makes a GET request (through a browser) to a URI that returns an HTML response. The browser then displays the HTML to the user. If the HTML response contains a FORM element, well that's an invitation to the user to change the state of data on the server in some way (maybe by adding a new post to a blog via a few text boxes). When the user clicks the submit button, a POST request is sent to the server that contains all the text the user entered in the HTML textboxes. Once the server receives the request, it's up to the application that drives it to figure out what to do with the data sent by the client.
I hope I haven't lost everyone yet, because I swear there's some sort of profound punchline to be found here.
The Quest For a Simpler Rube Goldberg Machine
Now, I'm sure we can all agree at this point that HTTP is pretty simple. Clients make requests using a verb that may or may not contain data, and the server responds back to the client in whatever way it deems appropriate. The issue that Ayende and I have with Webforms (and Struts, and other view frameworks) is that they take something simple and try to make it different. In the case of Webforms, Microsoft has tried to create an event-driven, stateful paradigm out of something that is resource-driven at it's core.
The result of this is that Webforms has become a layer of indirection that sits on top of HTTP. Indirection in and of itself is not bad; as a guy that uses ORM's to abstract the database will tell you. The problem is that I think it's gone a little further away from the underlying model than it should.
Witness the ASP.NET page lifecycle.
Webforms is an attempt to make web programming look like desktop programming. As a guy who learned about web programming via ASP.NET, I found it was pretty intuitive. The problem came when I ran into leaks in the abstraction that I couldn't deal with without the knowledge of what is really going on under the hood in the HTTP pipeline.
If You Only Read One Paragraph, Read This One
Now the first problem with Webforms is not that it's an abstraction, or even that it's a leaky one (they all are). The problem is that what Webforms attempts to abstract away is actually simpler than the abstraction!
The second "problem" with Webforms is that not very many people know the first problem. I know I didn't, until I saw how Rails, Monorail, and other frameworks are able to work with the underlying model of the Web, while still being terribly simple to understand and develop on top of. Making it easier to program for the Web is a laudable goal, I'm just not so sure that abstracting the technology that it's built on top of to the point where it's unrecognizable is the way to go about doing it.