MVC or WebForms: It’s more about client side vs server side

Scott Guthrie has posted on the growing debate over Webforms vs. MVC, a debate that seems to be raging everywhere (although there is more that one MVC framework out there too). I agree with Scott’s point about the nature of technical debates, and the acceptance that there are different schools of thought. However, that does not always imply that all schools are equally good solutions to a given problem.

The issue has been though I think not solely about the MVC pattern, it is also about the shift from providing rich client behavior server-side or client-side. In this area the renewed interest in AJAX and the emergence of Javascript libraries like Prototype, and JQuery have been game changers. And for me those RIA paradigms dovetail better with MVC apps than with Webforms applications. At the same time the growth of REST has meant many have re-engaged with the HTTP protocol and its resource oriented model, have turned attention away from page based approaches to web development toward resource oriented ones. There is a correspondence here, because as the use of client side scripting grows so does the perspective of the server as a resource provider used by the client.

It is in many ways this shift of paradigm that MVC supports better and why using MVP approaches with WebForms is not a ‘seperate but equal’ answer to modern web development. Its not simply about better conformance to Single Responsibility Principle.

What our frameworks do for us

Our average web framework has some pretty basic requirements – handle requests for resources from the server by returning an appropriate response. In our case this is HTML. The simple nature of this model underlies the success of the web.

To support this model our framework needs to route to an appropriate handler in our code that can read the request. Now we could just interrogate that request to pull out post data or query strings, but writing a lot of that code would get old fast, so it helps if our framework can map between form, params and query string values and part of our object model. That way we can manipulate the variables of the request more easily. Now we have to take an appropriate action in response to the request. Generally this is where most of our code plugs in. We get some data and compose a response, in HTML to return in the response. Now just using Response.Write() to output our HTML becomes hard to maintain, so most of us expect our framework to give us  some sort of template so that we can separate the static and dynamic portions of our response.

The MVC pattern enters the fray here when frameworks separate the responsibilities of template to provide view, model to provide response to action, and co-ordination between the two for a request. Criticism of Webforms as lacking effective separation cf concerns is because the aspx file is both responsible for rendering the HTML used as a response and providing the controller for the request. It thus has two reasons to change, because the template changes or because the co-ordination of handling a request changes. These may be orthogonal concerns and make maintenance harder. Some patterns such as MVP try to alleviate this by enforcing separation of these two responsibilities within the framework. this criticism is valid but not complete issue; the significance of ‘MVC’ frameworks is not solely their better separation of concerns.

Now for sure the devil is in the details, but that’s pretty much it.

Bare Bones

‘MVC’ frameworks such as ASP.NET MVC or Monorail ttend to have a bare bones approach to meeting these requirements. The framework takes requests and calls an action to service them, mapping request to action parameters. We then carry out the appropriate task and render html through a view engine. MVC frameworks add little on top of this paradigm. The big win here is that this makes them simple to learn and easy to use, because the surface area of the API is small. The surface area for ASP.NET MVC is smaller than that for Webforms and is easier for new developers to learn. It also works in harmony with http and thus expectations. The principle of least surprise is important to APIs because it makes them easier to discover. Understand the problem and you are likely led in search of the solution.

Rich Internet Applications

Now ASP.NET MVC etc. allow you to return an HTML response, but HTML has its limitations in that it is static. You need to post a request to the server each time you want some new action to occur. In some cases this ‘complete form and submit’ model works, but we have become used, from smart clients, to a more dynamic model that provides feedback as we make selections. We expect choosing from one dropdown such as country to restrict choices such as US State vs. UK county or Post Code vs. Zip Code.

Out-of-the-box support in web browsers for dynamic behaviour came in the form of Javascript and manipulation of the DOM. The browser is the smart client in this approach. The issue here is that Javascript development was a challenge for many developers and consequently many development shops. Why? Because folks found client side behaviour did not just require switching to another language, but also learning the DOM, which was also sometimes uncomfortably close to metal for developers weaned on smart client Forms frameworks like Windows Forms, VB, or PowerBuilder. In addition the browser wars meant that the model for programming against the DOM was not the same from browser to browser, further complicating the code that was needed to implement a rich client in the browser. In truth it was expensive. Finally the debugging experience was poor. We were back to tracing the state of variables in order to isolate and fix problems in the browser. For many MIS departments writing sites with a rich client, heavy on javascript, was out-of-reach in other cost or skills.

To solve this problem WebForms introduces the concept of server side controls – essentially shifting the rich interaction to the server. The server side control abstracts the html control from the client side. The benefit is that it allows you a development approach familiar to forms based programmers. You set and get control properties and write handlers to react to events. But as the events are raised client-side you need effectively mirror all of the control state from the client side to the server. The problem here is that html does not share this with you on a post. You also need to record the event raised for the server side too, as a post is all you know about from http. This brings in ViewState, which captures all the state which a post is not giving you. But once it is implemented I can provide all that dynamic behaviour on the server, skipping and jumping over issues like knowledge of Javascipt and the DOM, as well as browser compatibility issues.

Of course we can quickly see that with any complex enough page ViewState will grow. As it is embedded in a page it increases the page weight which can hamper performance In addition because we must do an http post to transfer the state of our application back to the server, and then display the response, events are handled by a page refresh. This has the consequence of making the system slower than one which handles the event locally, giving rise to user complaints of flicker or slow response. In addition if you try to cope by adding some AJAX callbacks from your client  the question quickly becomes ‘who owns this state’ as you may have copies of the state both on the client and in ViewData being marshalled back and forth to the server.

Webforms is also a more complex API than MVC and thus harder for developers to learn. Most of us have been at an interview where we have asked, or been asked the question – what is the Webforms lifecycle? Understanding the stages, where viewdata is available and modifiable is not an insignificant learning challenge.

Given that, for some time I used to recommend building applications using WebForms server-side control model over building applications with client side behaviour. Why? Because of the cost and difficulty of building rich client behaviour in Javascript with the DOM outweighed the cost of learning Webforms.

What Changed?

MVC trades the complexity of server side controls for a simpler programming model, supported by client side controls. The emergence of the new breed of Javascript frameworks like Prototype, JQuery, and, made it far cheaper to code the client behaviour on the client. The elegance and simplicity of these frameworks, their abstraction of browser API differences, and their rich ecosystem of control providers, lowered the barrier to entry for client-side development providing solutions to common needs such as  grids . The availability of many free controls lowers the cost of common UI widgets that have often been the preserve of expensive vendor solutions.

In addition the debugging experience for Javascript has significantly improved from the old trace and dump model with browser plugins such as Firebug and Visual Studio.

With a lower cost it has become commercially viable for more development shops to build rich client applications. Best of breed applications do not suffer from the postback flicker issue because they manipulate state locally on the browser and use AJAX calls to the server. With effective client side development, the user experience is akin to smart clients of yesterday, with none of the distribution problems for central IT departments. This rich experience available for the web lies at the heart of the SaaS revolution.

The MVC model truly shines with AJAX where the target for an AJAX call is just an action on a controller. The affinity to http’s resource based model allows for easy definition of the server side support for rich clients. The advatange of MVC frameworks is the ease with which they dovetail to client-code using frameworks like JQuery. Client-side programming is back, using modern Javascript libraries!

It is this, IMO, which has shifted the balance in favour of MVC. I do not think it any accident that the ASP.NET team shipped JQuery with ASP.NET MVC. I think it was essential to shipping an ASP.NET MVC application that a modern Javascript client library was included to support rich client behaviour on the browser instead of server side.

From my cold dead hands

The attitude of many developers may be ‘you will pry Weforms from my cold dead hands’. The march of progress is threatening to do just that. Much of theresistance is based on prior experiences with the cost of client-side development using Javascript, without understanding that the new frameworks available have significantly lowered the barrier to entry there. In addition, Silverlight opens a second front against Webforms by offering rich client development using XAML. If Javascript does not replace Webforms, then XAML will. Server-side controls had their day. They built careers, companies, and fortunes but they are legacy applications now. Client-side controls have returned with fresh offensives that will see their end. If you are building a new web project today you should be looking at an MVC framework.

For my part the question of Webforms vs. MVC is already an irrelevance. That is yesterday’s fight and victory has been declared despite a few units continuing to fight on. The next war is likely to be between Silverlight and Javascript for ownership of the smart client…


About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • luis

    such an old post. MVC is going no where. MVC is a much cleaner frame work.

  • MVCvsWebform

    Webform was absolutely not flexible in terms of output. Its output was always HTML. But if you see the recent client types like javascript they are more comfortable with JSON , and other clients probably need different output format. If you want to change the output in Webforms you need to set the response.Contenttype and do response.end etc.

    In the same way there are many such issues around flexibility. I think they went too aboard to please the RAD developers leading to view based architecture for action based requirement. Below is a article where i have explained the same in more detail

  • Melvin Cañafranca

    See MVC 4 now and let me know your thoughts. :)

  • Pingback: Exam Ref 70-486: Developing ASP.NET MVC 4 Web Applications | Jinal Desai .NET

  • Anonymous

    I agree with you… MVC looks to me like a modern ASP platform… it’s easier for amateurs developers but it’s a “spaghetti” approach for professionals developers…
    For me Silverlight is the best… but Apple’s desire for simply html apps changes microsoft’s plans

  • Anonymous

    Webforms aren’t going anywhere despite what you think. And it’s not about what you think. MS does not see MVC as a replacement for webforms. It’s their opinion that matters.

    Unless you need multiple views for the same controller, MVC requires more code/work to get the same job done.

    There’s NO requirement in webforms to use bulky server side controls. I almost never use them. I have the same flexibility with webforms as I do with MVC.

    MVC is nothing more than webforms with server controls stripped out and the forced use of routing (which you can use with webforms) added in. Webforms separate the view and the controller, it’s VS that makes it visually seem that they’re combined.

    MVC in ASP development is still a tiny fraction of new projects. Not sure where you got this “balance has shifted” idea from.

    Sure, you’re one of those developers that jumps on the latest trend/buzzword bandwagon and probably works with others who do the same. From your perspective, MVC is the NEW way to do web app dev with MS. MVC is old news. You could do MVC with winforms for a long time now if you wanted to, it’s just a design pattern.

    Razor leaves a lot to be desired and honestly, it just as clunky as the server controls it replaced.

  • Ricka Anderson

    Amazing read for such an old article- the information is just as valid today.  I agree, the trend is toward rich clients and MVC facilitates that.  I’m not speaking for Microsoft here, just for me and I do work for the ASP.NET MVC team.
    zesus writes: I would be willing to bet MVC is going to be a fade technology and go to the back burner at some point similar to Microsoft BOB :)I’ll take that bet :) ASP.NET MVC has proven to be a winner.

  • pearl jewelry
  • Pingback: Differences MVC versus WebForms « A Programmer with Microsoft tools

  • Max Colti

     In general the validation on the client side should be the same(or very similar) to the validation on the client side.You are right when you say “…postback model is that you have to submit, fail and get feedback..” but you can’t avoid that or at least you should not for the reasons posted by Dennis.
    One of the corcern of MVC is separate the UI from the “Model” that means that instad of using an HTML page I could post “stuff” to the server using whatever I like (XML,etc) without “change anything” on the controller
    worst case the javascript could be disabled on the client

  • Tesla

    Doesn’t this all come down to the underlining issue that we are developing against an ancient technology of the internet or is it a browser issue. Why by todays technological advances to build a RIA you need to know more then five different other language driven development arenas. I think is time to put HTML to bed. It’s overdue to be replaced.

  • zesus

    I build both webforms and MVC sites and with all due respect MVC is probably the worse possible choice for web development in most cases.

    The UI validation is horrible with MVC which is a big problem. MVC is like coding in the 80’s you good very good at writing HTMLHelper very quickly.

    The amount of MVC code in most cases is double or triple that of a webform application and as far a providing a rich client experience I am yet to find anything done in MVC that can’t be done in webforms from a user prespective.

    Even with MVC there is still code running server side it is just called controllers and webservices.

    Seriously the only reason to use Microsoft tools for development is speed of deliverly of the application. If you want to get “close to the metal” then go open source.

    There are not many major players jumping on the Microsoft MVC bandwagon. MVC has been around a long time and ruby is probably the best MVC framework and that is yet to make any major in roads.

    I would be willing to bet MVC is going to be a fade technology and go to the back burner at some point similar to Microsoft BOB :) … People are hyped because it is new and buying into the Microsoft marketing spin machine.

    At best it I would advise to take a wait and see approach before jumping on the MVC bandwagon.

  • Ryan Riley

    I thought you made an excellent point in the title but didn’t quite drive it home in the article, aside from the fact that this is clearly the best article on WebForms vs. MVC I’ve read. :) I think people forget that these are really SERVER frameworks, not CLIENT frameworks. Yes, you can use JavaScript or Silverlight clients, and a lot of people consider those a part of the same application, but you still have a fairly clean separation between the MVC and client code. This of course is muddled because we inevitably embed a reference to our client code into our rendered resource representation, a.k.a view.

    It would be nice to see more clean separation between resource representations (html, xml, json, etc.) and UI views (jQuery UI, YUI, Silverlight,
    etc). Maybe WebForms would do well to evolve into a UI platform rather than a server platform, possibly something more like a working implementation of XForms.

  • Jakobsson


    None argues that you should put business logic on the client side, that does, of course, belong on the server side. But today when we build public sites we often need a interactive ui to get people to use our site. Today we have a lot higher expectations on the sites we visit.

    Thats why its important that the server side framework doesn’t work against you when creating the ui. The webforms framework is a framework that can give you a lot of trouble when creating your ui. And that is not that odd, considering it is a 8 year old framework. Webforms simply doesn’t fit in to well with the requirements we have today.

  • Ian Cooper


    I think we need to seperate domain logic – encoding our understanding of business process from prevention of invalid input. When folks talk about client side logic they usually mean some sort of validation. Validation logic on the client and the server should probably not be the same thing. On the server I am interested in stopping invalid state changes. On the client I want to help you not to make those invalid choices in the first place. The problem with the postback model is that you have to submit, fail and get feedback. A rich user experience does not let you make mistakes in the first place. Nothing drives user experience down than allowing the user to enter invalid changes, such as date ranges, forcing them to post back, and then telling them they got it wrong.

    In addition generating the appropriate js for rules defined against the model is a common approach. See for example the xval framework:

  • Ian Cooper

    Note – edited to include improved js debuggin experiences today, which I missed out in the first pass

  • Dennis Gorelik

    Ian, you are overestimate the importance of JavaScript (and browser-side code in general) and underestimate the importance of server-side code.
    1) Business logic must be implemented on server-side.
    It’s optional to replicate the same business logic on browser side. It’s not optional to implement it in the first place in server-side code.
    2) Developer cannot trust results generated by JavaScript code, because that code is not controlled by server.
    Malicious user can tamper browser-side code but has no power over server-side code.
    3) Considering that duplicating business logic both in server code and browser code is costly and considering that you cannot drop server-side code — when it’s time to cut development and maintenance cost — javascript is stripped away (or not implemented in the first place).

  • Michael J. Ryan

    I’ll chime in on the JS vs. Silverlight. One of the biggest suggestions in terms of keeping Webforms over JS I’ve seen is the need to become much more familiar with HTML markup, CSS and JavaScript (another language). I would say that this is still a lower barrier to entry for most established webforms devs than learning XAML with the event and data models in their current choice of server-side language.

    Then again, I remember writing a lot of cross-browser DHTML in the bad-old v4 browser days. Today is a dream by comparison. I started with prototype when it came out, but have since jumped into the jQuery camp. I like to keep my JavaScript object/language extensions out of the DOM extensions, and jQuery is better isolated from the language.

  • Stacy Murray

    Thank you very much! This is the most useful, no-drama, no-bias article on the subject that I’ve read.

  • Phil

    I liked your conclusion. I really don’t see this as a debate anymore. Perhaps the blogs that I regularly read are not diverse enough, but from what I can tell nobody is championing Web Forms anymore. Let’s start getting some posts about JS vs Silverlight.

  • Jay Kimble

    FWIW, this is the most intelligent discussion of this topic I have found. Mainly because it avoids other wars (TDD, Agile, etc) and focuses just on the technologies.

    I guess the other reason I think it’s the most intelligent post on the subject is that I agree 100%. Or at least mostly. I have come to the conclusion that WebForms is ONLY a choice when it’s something that needs to be done quick and WILL be thrown away at the first opportunity.

    The only thing that WebForms really has going for it at the moment is the large 3rd party tools out there (and I expect that to change rapidly in the next year or so).

    I say all this as a non-TDD coder. I am agile in some of my techniques (but God forbid that I call myself that.. the flame throwers would immediately come out).

    I use ASP.NET MVC and have found myself recommending it more and more especially when Ajax is a topic of discussion for the project..

    Jay Kimble
    – CodeBetter Alumnus

  • vkelman

    P.S. Since ASP.NET MVC was developed by a team of Microsoft developers I cannot understand what causes that strange shyness which prevents MS developers team from acknowledging the simple fact that *in most cases* ASP.NET MVC is better or more suitable for Web development than an obsolete WebForms model.

  • vkelman

    Thanks for a good article. To me, an advantage of MVC (MVC.NET) over WebForms is also in the fact that MVC does not try to hide underlying HTTP Request / Response mechanism and to replace it with unsuitable and alien Win Forms logic. Every time someone tries to mix client and server technologies together or to completely generate client code on server instead of establishing well-defined client-server communication protocol, it leads to greatly overcomplicated unnatural code. Look at how overcomplicated ASP.NET Ajax is vs. simple and transparent Ajax support of jQuery…

    Rob Conery described it very well in his famous article at

  • Colin Jack

    Definitely, I agree and thats why I think having Scott say it was so useful. I’ve not monitored the Web Forms debate closely but my impression was MS quite often presented them both as viable approaches but even Scott is indicating that MVC is probably a more suitable solutions to most problems we meet.

  • Paul Speranza

    I love this post. I couldn’t have written a fairer explanation. I will save this for when I have to justify moving away from webforms.

  • Ian Cooper


    Sure but I don’t think that is what causes shops to use Webforms today. I think its the skillset reliance on server-side controls. I don’t think those shops will move without friction unless they understand the need to move to current js frameworks.

    Webforms will always be there for Supporting legacy, so its not much to express that.

  • Colin Jack

    I thought the best thing about this latest part of the debate was where Scott replied to Karl about situations where he considers Web Forms to be the correct choice. Worth reading his comment (starts @Karl) but essentially it looks like its when you are using SharePoint, or using existing server controls, or need to support older browsers.