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.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in ASPdotNET. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • One good thing about web forms is that it allowed the development of advanced controls (like the gridview) that are difficult to build with MVC.

    Secondly, in my area (Brisbane, Australia) there is not yet any work for Asp.Net MVC. I do not believe this will change in the near future; it may never change.

  • @ Liam,

    IMHO the gridview has to be the most cumbersome, unfriendly control out there (with exception of the equally as good radio button “what do you mean you cant set a value?” control)

    I am 100% behind MVC architecture as a whole (not just the MS version) and would recommend it for any project, any size!

    I am running interim drop, MVCContrib, Castle Windsor and BOO (for config).

    So testable, so maintainable just heaven to work with – especially for DDD/TDD!

    Dave The Ninja

  • rsvihla


    I have to parrot Dave here. I got really good over the years at customizing the gridview (joys of OnRowDataBound event to create a nested gridview). But I found for meeting customer needs that using things like :

    < % for employee in employees: %>


    < % end %>

    Id Name ${employee.Id}

    or the smartgridcomponent are far faster to work with when the customer wants anything outside of the default behavior, and my designers definitely thank me for tossing all this extra JS at them that they now have to deal with . See episode 2 for an excellent working example of it vs the gridview.

    Don’t get me wrong I used to LOVE the gridview when all i knew was webforms, but I started hating it when customers got more and more demanding of .net 2.0 functionality.

    Also, as far as future work being MVC based, people said the same thing about Java vs. C++, and before that about C vs C++ and before that in regards to C vs assembler. The one constant of development is change, whether you as a developer want it or not.

    I say seriously to the entire Webforms crowd, listen to JB at least enough to give some MVC framework a week of serious go (I prefer Castle, but I had to spend A LOT more than a week to get adequate with it, so maybe MSMVC would be a better entry point docs wise?) . You’d be doing yourself a grave dis-service as a serious developer if you don’t give a rapidly growing approach a serious examination.

  • rsvihla

    hah ignore the html errors in the last post, thats what I get for multitasking, but the general idea is there

  • Mike Lasseter

    @ rsvihla

    Also, as far as future work being MVC based, people said the same thing about Java vs. C++, and before that about C vs C++ and before that in regards to C vs assembler

    The key difference being MVC makes it easier and cleaner for the skilled, while Java made it easier for the masses. Which is why I would agree with Liam, that it is going to be a long while before this catches on, if ever.

  • Joe

    Raw SQL is all that matters in the end, so will you be dropping your OR/M?

  • @Mike

    I’d have to disagree, it has caught on. See all the other MVC frameworks that aren’t .NET specific. I’ve had developers quit my team _solely_ because of ASP.NET. Complexity doesn’t equal a powerful framework, it just makes it complex.

  • I got to do a lot of job interviews lately, among which some ASP.NET developers with 2+ years of experience. When I asked a question about the difference between HTTP POST and HTTP GET or the stateless nature of the HTTP protocol, they couldn’t give me a decent answer. How is it possible that you can proclaim to be a web developer and you know nothing about HTTP or HTML, let alone CSS or Javascript?

    I, for one, am happy that I’m not the poor guy who gets to maintain the web applications they wrote.

    It’s not the abstraction of WebForms itself that is responsible for all the grief, it’s the fact that I’m not able to put out my own HTML if I want to. This is what an MVC FW allows me to do.

    Same goes for an ORM vs raw SQL. A good ORM (read NHibernate) allows me to write my own SQL when I really want to. It doesn’t prevent me from doing that.

    Oh, and by the way, I’m kicking this again because I’m with Jimmy on this one. :-)

  • @Joe

    Who would drop an ORM for straight SQL? Also, who would drop SQL entirely for an ORM? Neither of those make sense, and it’s incorrect to say that WebForms::HTML as ORM::SQL.

    Tools should be used to simplify work. ORMs, without a doubt, simplify interaction with DBs. WebForms don’t do that. They not only make the work harder, but abstract it with stupid conventions that only work consistently in VS’s browser. It’s a handicap for developers who refuse to think outside of an event driven model, and consequently require a ton of garbage to be written to the browser to maintain state.

    WebForms allow developers to pigeon hole web apps as stateful, event driven applications, which as @jbogard talked about, isn’t HTTP.

    In a nutshell, if you liked DareDevil, you’ll like WebForms, and nobody will like you.

  • I think that WebForms got some things right. I love the RAD aspect of WebForms, and it is one of the things that really attracted me to ASP.NET moving from JSP/Java Servlets/JavaBeans, specifically, Struts – also an MVC framework. I didn’t do any ASP/VB development.

    I’ve been a web developer for 14 years and am definitely familiar with the details of the HTTP/REST model. It’s understandable that people have been searching for some abstractions over the statelessness of the web, the primitive breadth of HTML form controls, and the lack of built-in client-side validation. I ended up rolling my own “server controls” in JSP (and ColdFusion) with built-in client side validation, albeit without viewstate and postback.

    Since ASP.NET MVC is so young, it’s hard to tell what v1.0 will include, but we’re not really that far away from an RTM (granted, out-of-band support, think ASP.NET AJAX before .NET 3.5). The young/grassroot server/user controls, state persistance (e.g.: viewstate), and validation stories are what concern me the most that in some aspects it may temporarily be a step backwards.

    I love the open nature vision of ASP.NET MVC, with its pluggable architecture, but “off-the-shelf” it needs to have MS-supported baselines/defaults for server/user controls, state persistance (e.g.: viewstate), and validation, IMO, to be ready for production and broad consumption. It at least needs to catch up to MonoRail.

  • I don’t mind when some problem is abstracted for me. But WebForms, as a concept, is past its due date. But these days, it’s abstracting a problem that isn’t actually all that hard to understand anymore.

  • @Kyle

    Indeed. I just would like to see ASP.NET MVC not swing the pendulum too far back towards ASP. I know there’s Monorail, et. al., but unfortunately corporations still are very dependent on that MS-blessed label. That’s why I like the direction ASP.NET MVC is going, especially with a pluggable architecture. ASP.NET MVC with a Brail view engine is still technically ASP.NET MVC.

  • Lucas Goodwin


    I haven’t been doing this as long as you, but I must say ViewState is probably the most USELESS feature I’ve ever dealt with. ProMesh.NET has a much better way of dealing with the need to persist data across posts. Instead of ViewState, the framework automatically rebinds the value of controls between posts.

    No ViewState corruption. No ViewState timeouts. No ViewState load. The single thing I HATE about WebFroms is ViewState. Followed very closely by the Event model, but that’s been harped enough.

    All that being said, I maintain and build many web-apps, some written with WebForms, some using various MVC frameworks, and yes, the immediate RAD of WebForms is highly attractive. At the same time, that RAD breaks down pretty quickly when you go back to add more advance features, etc. It becomes a real maintinance nightmare fairly quickly.

    My personal experience has shown MVC FW based applications to be MUCH easier for us to maintain.

  • @Troy

    Looking at ASP.NET MVC, you’ll find that its templating system hasn’t really changed much since ASP 3.0. Some of the other templating engines provide some more powerful features. It definitely has some catching up to do, but it’s 1.0, right?

  • @Lucas

    To clarify, I am not defending ASP.NET WebForms as a good implementation, when I say it “got some things right”. I am referring to its vision and attempt to be usable abstration layer, especially circa 2001. Granted, as Kyle points out, it is getting a bit dated to still be using basically the same abstraction architecture.

    Yes, viewstate is the one thing that still has me scratching my head about WebForms. Before ASP.NET, with or without MVC (Struts), I kept state on the server side and re-populated upon load. I’m not sure why MS ever went the client-side route.

  • @Jimmy

    I guess I am expecting much more from MS in v1.0 when it comes to MVC since they’ve arrived so late in the game that it affords them the opportunity to avoid previously disclosed dangers and draw from (i.e.: copy) those that went before them.

    But, yes, I think it may be safe to infer that you also mean, “Give ‘em a break, dude, it’s only been 8 months so far”. And to that I would concur and say that I couldn’t do it any faster. But it doesn’t keep me from expecting more. :-)

  • Bender

    My opinion might be a little biased, but I think that the WebForms framework has it’s merits.

    Technically, it is horrible. I’ve seen my share of horrendous code written in it. People that don’t get web programming hack their way around it until their boss is happy.

    In the same time, if you are beginner you have an easy entry point into web programming. This is very important. Even the smartest person will have troubles coping with HTML, CSS, JavaScript and HTTP, if he does not have prior experience. Who wants to tell them about all the browser bugs? Having an abstracted version of the web applications might be beneficial at this point. Any smart person will soon grasp the concepts and will gradually start searching for better and less abstracted alternatives.

    But some people don’t want to learn. For them it is important to have a standard tool, so they can complete their 9 to 5 tasks without breaking a sweat. I don’t like this approach, but WebForms has a lot to offer to those people. They can buy off the shelf components and do their work (mostly) easy. The “proper” web application frameworks will hardly appeal to those people.

    I’ve got little away from the technical side. I just wanted to add some “real life” context to the discussion.

  • @Anonymous Glenn

    Due to petty insults and name-calling, I’m deleting your comment. Although you have some good points, it’s unfortunate they were overshadowed by the negativity. Hopefully you can elevate yourself and the discussion back into a civilized atmosphere.

    I won’t hold my breath.

  • Glenn

    People who can’t decipher content from style usually aren’t worth having a conversation with.

    I’ll leave you to bask in the gentler comments of people who primarily agree with you.

  • Mike Lasseter


    The point I was trying to make is the majority of the developers don’t read and learn outside of work. They go to work put in there day and then they are done. You can make your own opinions on whether that is wrong or right. These are the people that will never use the MVC framework and are happy to keep chugging along with WebForms. My point is I don’t see the MVC framework catching on with the same number of users as WebForms.

  • @Anonymous Glenn

    I dunno, I see cowardice behind anonymity. I have a Contact link. I’d be happy to have a throwdown discussion through email. Just not through blog comments, it’s a terrible medium for discussion, and anonymous posters can use abrasive styles that detract from an honest debate.

    Reading the original post again, nothing I said implied anything about users of WebForms. So I fail to see why your tone is necessary.

  • @Mike

    I’d agree with you there. But I’d say WebForms is used only because it exists and MS pushed it, not because it’s simple or easy to use. It demos well, though.

  • @Glenn:

    Challenge and debate, but don’t insult. It’s wholly appropriate to question the intelligence of someone who can’t present their arguments intelligently.

    If you think Jimmy is wrong, then tell him why and refute him.

  • @Bender

    “But some people don’t want to learn. For them it is important to have a standard tool, so they can complete their 9 to 5 tasks without breaking a sweat. ”

    WebForms only let you do your job “without breaking a sweat” if you’re building brand new greenfield code. Once you have an application of any appreciable size, and you want to keep it maintainable, you tend to adopt a solution that is essentially an end run around WebForms. Either that, or it becomes an unmaintainable mess. I’ve seen way too many of those to want to consider continuing that way.

    Comments like the one by Glenn up there that got deleted are usually written by people who have gotten so used to hack-patch-hotfix-repeat that they don’t try anything else. It’s like Stockholm Syndrome… you’re beginning to “identify with your kidnappers” and you’ve lost perspective that there might be other ways to do things besides what you’ve always done.