Working with the web model
Lots of comments from my recent post on ASP.NET WebForms being officially unmaintainable noted that:
- AJAX works with the ClientID property
- I don’t care about HTML
One thing to remember about web applications is that web applications are nothing more than HTTP, Cookies, HTML, CSS and JavaScript. Let’s spell that out again. Web applications are:
- HTTP
- Cookies
- HTML
- CSS
- JavaScript
You can create web applications without CSS and JavaScript, but the latter three represent the structure, style and behavior of a single web page. HTTP is engine that makes at all work, and the browser is the window into our application. The browser does not care, nor will ever care about:
- Postbacks
- Viewstate
- Lifecycle events
All of these are a clever ruse on top of the four elements of a web application, an effort by the ASP.NET developers to make the web appear as a stateful application like the VB6 applications before it. One slight problem: HTTP is inherently stateless.
Many web application frameworks solve the stateless problem through Session objects, where a unique cookie value matches clients with state bags on the server. All persistent state lives completely on the server, hidden from view from the client except a cookie value.
Now the five components of a web application are simple in and of themselves. Combined, they can create very powerful client experiences. The browser, completely decoupled from the server, serves as a conduit for a myriad of applications, each supplying all the building blocks a browser needs. No matter what happens on the server, eventually all data must go across the HTTP wire, delivering HTML and the others.
And that’s the beauty of web development: browsers completely decoupled from the server technology used to serve the pages, and a set of standards covering each component (HTML, CSS, etc.)
So why the WebForms abstraction?
ASP.NET needed to convert a mass of VB6 developers into web developers. To do so, WebForms mimicked a stateful web application through clever use of JavaScript, the FORM element’s TARGET attribute, and some hidden INPUT elements to persist state. These combined tricks enabled the PostBack model, where a page posts back to itself for processing.
Already, WebForms is subverting and abstracting the very nature of HTTP – statelessness of postbacks. Additionally, server controls abstracted the raw HTML being sent to the client. With WebForms, you lost control an important component of a web application: HTML. You also lost control of the FORM TARGET, which allowed for posting to specific URLs for specific controlling.
So what’s the big deal, right? HTML is annoying. It doesn’t render properly in every browser, and CSS tricks sometimes are the only way to get IE6 and lower to behave properly.
But the underlying concepts are dead simple. HTML to describe the structure of your information, and CSS style the information. When something doesn’t look right in the browser, no server technology matters. It’s only HTML, CSS and JavaScript.
By programming in the actual underlying language of the web, we don’t have to undergo the translation that Web Controls force, nor the behavior change that WebForms force. Since we’re constantly posting back to the same page, a single page has to be responsible for quite a few things:
- Creating HTML to be rendered, through an elaborate server control hierarchy
- Flow Control, through elaborate life cycle events
But the web is much, much simpler than server controls and life cycle events. HTTP GETs and POSTs are how users request information, not through a Button_Click event.
Working with the model
The main problem I have with WebForms is that it tries to make the web something it’s not: a client application. Although events get fired on the server, it’s only through the hidden form variables and self-posting forms that this is possible.
WebForms works completely against the inherent nature of the web, which is why it can be such a pain to work with. WebForms did introduce a number of great concepts, including a component-based architecture, the request pipeline, caching, etc etc.
So how do you develop web applications outside of WebForms? For one, you don’t use the WebForms designer. The designer lies to you, as it is only the browser that is the singular truth to what your web application will look like. Instead, I structure my HTML directly, using CSS for styling.
How do you develop behavior and flow control? MVC frameworks do this by routing control to the Controller first. The Controller, after performing any flow logic it needs, can pass data to the View. The View is only responsible for taking in data and creating HTML, CSS and JavaScript.
By separating these concerns, we are both working with the model the web is built upon, and allowing complexity to vary independently between the Controller and the View.
When first coming over to ASP.NET from ASP 3.0 back in 2002, I both marveled at the cleverness of ASP.NET and disliked the control that was taken away. The difficulty in ASP development was the language (VBScript is not OO) and the unholy marriage of concerns, as Controller and View were in one single file. Not creating HTML, handling requests, or anything else to do with the components of the web.
Eventually, after seeing other web application frameworks come to the forefront, including Rails, I began to notice the cracks in the woodworks. HTML isn’t hard, it’s the flow control where the meat of the application resided.
Now, I’d rather work with the web model than against it. I recognize that HTML is all that matters in the end, so I might as well accept it and embrace it.