I know that Microsoft has said

ASP.NET MVC is not a replacement for WebForms.

And some developers say WebForms is faster to develop on than MVC. But I believe speed of coding comes down to comfort level with the technology so I don't want any answers in that vein.

Given that ASP.NET MVC gives a developer more control over their application, why isn't WebForms considered obsolete? Alternatively, when should I favor WebForms over MVC for new development?

  • 57
    @Darknight :\ that's highly biased and simply wrong. MVC is not for simple CRUD apps. I'd argue WebForms is for generic CRUD apps (i.e. database -> some shiny grid control).
    – Raynos
    Commented Nov 13, 2011 at 12:29
  • 17
    @Darknight whatever makes you happy -> if you like WebForms go crazy with it ;)
    – Raynos
    Commented Nov 21, 2011 at 13:22
  • 16
    @Darknight You obviously have a poor understanding of MVC if this is your opinion... There are some huge sites built with mvc... do some research sir.
    – Robotsushi
    Commented Nov 29, 2011 at 18:44
  • 32
    IMO, never use webforms when you can use MVC instead. Commented Jan 15, 2013 at 19:23
  • 10
    I'm not one to speak so this is just my opinion. After reading most of the answers I came to conclusion that the answer is just never. MVC is just awesome and the only drawback I found is that I keep seeing ; at my webpage (If you're just beginning with Razor you'll get the joke). Commented Jan 24, 2013 at 14:09

19 Answers 19


Webforms vs. MVC seems to be a hot topic right now. Everyone I know touts MVC to be the next great thing. From my slight dabblings in it, it seems ok, but no I don't think it will be the end of webforms.

My reasoning, and the reasoning as to why webforms would be chosen over MVC, has more to do with a business perspective rather than what one is better than the other.

Time/money are the greatest reasons why webforms would be chosen over MVC.

If most of your team knows webforms, and you don't have the time to get them up to speed on MVC, the code that will be produced may not be quality. Learning the basics of MVC then jumping in and doing that complex page that you need to do are very different things. The learning curve is high so you need to factor that into your budget.

If you have a large website written all in webforms, you might be more inclined to make any new pages in webforms so that you don't have two very different types of pages in your site.

I'm not saying it's an all or nothing approach here, but it does make your code harder to maintain if there is a split of both, especially if not everyone on the team is familiar with MVC.

My company recently did three test pages with MVC. We sat down and designed them out. One issue we ran into is that most of our screens have the View and Edit functionality on the same page. We ended up needing more than one form on the page. No biggy, except then we wouldn't use our masterpage. We had to revamp that so that both the webforms pages and MVC pages could use the same masterpage for common look and feel. Now we have an extra layer of nesting.

We needed to create a whole new folder structure for these pages so that it followed the proper MVC separation.

I felt there were too many files for 3 pages, but that is my personal opinion.

In my opinion, you would choose webforms over MVC if you don't have the time/money to invest in updating your site to use MVC. If you do a half arsed approach to this, it won't be any better than the webforms you have now. Worse, you could even be setting this technology up for failure in your company if it's messed up, as upper management might see it as something inferior to what they know.

  • 14
    This is a good answer. I gave you +1 because your personal experiences are appreciated. But, this is failure due to a lack of experience/skill-set of the developers which I asked to avoid. I am not convinced that Microsoft would choose not to mark a technology obsolete simply because of a fear of the learning curve for MVC. This may be the case, but I'm not yet convinced. Commented Jul 22, 2011 at 19:26
  • 6
    @P.Brian.Mackey - I didn't say that forms development is faster than MVC. You asked to leave that argument out of it. Arguing time and money to train your staff is a different argument. MS won't mark webforms obsolete for one big reason: Enterprise clients have spent years developing web clients in webforms and won't look kindly on having to invest time and money to update.
    – Tyanna
    Commented Jul 22, 2011 at 19:39
  • 16
    @Raynos - If everyone on the team was proficient in MVC, and your company was starting a new project, then the only reason I could see someone choosing webforms is personal choice.
    – Tyanna
    Commented Jul 23, 2011 at 19:20
  • 3
    I know both technologies intimately. All my web projects are done with mvc and work at a company where I have free reign to do whatever is the best approach. I always chooose MVC.
    – Robotsushi
    Commented Nov 29, 2011 at 20:27
  • 6
    I started with Webforms and once I discovered MVC I switched to that. I don't know how anyone could defend webforms. Page lifecycle and one form for the entire page? Are you kidding me? Yahoo sitebuilder was probably the intended customer for it but even they didn't want that junk. Commented Apr 3, 2013 at 21:32

I developed ASP .Net WebForms applications for 3 years, and after one day of doing an MVC tutorial I was sold. MVC is almost ALWAYS the better solution. Why?

  • The page lifecylce is simpler and more efficient
  • There is no such thing as controls besides html controls. You don't need to debug your output to see what ASP .Net is generating.
  • ViewModels give you immense power and obviate the need to do manual control binding and it eliminates many errors relating to binding.
  • You can have multiple forms on a page. This was a serious limitation of WebForms.
  • The web is stateless and MVC matches the architecture of the web more closely. Webforms introduces state and the bugs you have with it by introducing the ViewState. The ViewState is automatic and works in the background, so it doesn't always behave the way you want it to.
  • Web applications need to work with ajax these days. It's not acceptable to have full page loads any more. MVC makes ajax so so much better, easier and more efficient with JQuery.
  • Because you can have multiple forms on a page, and because the architecture is driven by calls to urls, you can do funky things like ajax load a different form, like an edit form into your current page using JQuery. Once you realise what this lets you do you can do amazing things easily.
  • ASP .Net WebForms is not only an abstraction over html, it is an extremely complex one. Sometimes you would get a weird bug and struggle with it for much longer than need be. In many cases you could actually see what it was doing wrong but you are unable to do anything about it. You end up doing weird workarounds.
  • WebForms does not make a good technology for designers. Designers often like working with html directly. In MVC it's a view, in WebForms it's half a day of work.
  • As the web platform is evolving fast WebForms wont keep up. It's not aware of new tags or features of HTML5, it will still render the same stuff unless you get (often) expensive 3rd party controls or wait for Microsoft to issue an update.
  • Controls in WebForms limit you in so many ways. In MVC you can just grab a JQuery library and integrate it into your templates.

I know some of the issues above have been addressed to some extent as WebForms evolves, but that was my original experience. All in all I would find it extremely hard to find a business case for WebForms unless a project is already using it.

  • 6
    +1 for pointing out multiple forms. Plus the fact that the HTML webforms generate is most of the time not very SEO friendly (as in: large chunks of viewstate on top of the page)
    – jao
    Commented Apr 3, 2013 at 14:42
  • 5
    I have to agree 100% with this answer. At the end of the day, WebForms makings doing things on the client side (html / browser) so much harder. You literally have to fight the framework to get somethings done. An aspx page ends up with so much more code due to server controls than a cshtml page typically does. @šljaker If you start turning off ViewState and avoid server controls, you've abandoned much of WebForms at that point. I don't see that argument as particularly convincing.
    – Andy
    Commented Jan 17, 2014 at 17:37
  • 12
    You can have plain html controls in WebForms, no one force you to use Server controls. You can have full stateless Webform, no one force you to use ViewState. You can use full ajax and jQuery in Webforms, no one is restricting you from using jQuery. You can implement URL routing, no one force you to use static file base URL. Manually drawing a page with CSS consume the time as much as MVC needed. You can design HTML page directly on Webform.
    – mjb
    Commented Jul 30, 2014 at 10:02
  • 5
    @mjb: If you don't use server controls, ViewState and so on, why use WebForms at all when MVC is closer to what you're doing? It's like driving a tractor to work but not doing any offroading or using the shovel/hoe or stabilizer bars. At that point why not just use a car? Commented Dec 23, 2014 at 2:04
  • 3
    @Tjaart It is not quite right that you cant have multiple forms on ASPNET page. You could have as many forms as you want in ASPNET page but you could have only one server form - form with runat="server" attribute. Commented Dec 27, 2014 at 6:37

I emailed Scott Guthrie, an MVC expert at Microsoft. And probably the most qualified man to answer this question. He was kind enough to reply:

"Different customers look for different programming approaches, and a lot love WebForms and think it is great. Others love MVC and think it is great. That is why we are investing in both. "

So, to me this says that its not a technical issue. Its more of a "soft issue", if you will. One of personal preference. This is in line what several of you have said.

Thanks for all the answers.

  • 14
    Scott Guthrie invented the MVC framework for ASP.NET while on a flight back from London to Seattle in 2006/7. Come to think of it, he pretty much invented .NET too (en.wikipedia.org/wiki/Scott_Guthrie). Calling him an "expert" is an enormous understatement ;-) Commented Aug 15, 2012 at 18:09
  • 29
    That's a nice political answer from Scott Guthrie. If he himself were investing his own Web application you'd see an MVC project and for anything that couldn't be done in MVC, Silverlight would be the fallback. Don't take this as a comment negative towards WebForms, I think WebForms are great for smaller-scoped internal applications that can benefit from 3rd party components such as those created by Telerik. I'm glad Microsoft is moving forward with both technologies.
    – Sean Chase
    Commented Sep 23, 2012 at 16:47
  • 10
    "Scott Guthrie invented the MVC framework for ASP.NET while on a flight" I think that really trivializes MVC. I don't know Scott Guthrie, but I'm willing to bet he had been peculating how MVC might be implemented in ASP.NET for a while, and used that long flight to implement a bare bones prototype as a proof of concept. Commented Jan 17, 2013 at 0:37
  • 6
    "That is why we are investing in both." And when we see that web forms starts to decline, we will mercilessly drop it because investing in an ultimately dead product is not in our best business interest.
    – Quandary
    Commented May 29, 2013 at 7:22
  • Until it is no longer taught in schools, for many years, it will always be applicable in the business world. Colleges and high schools continue to offer intro and advanced courses in vb.net. Its NOT going anywhere!!!
    – htm11h
    Commented Jun 27, 2017 at 14:47

This is a stale question with a lot of answers but none had the answer I would have expected to be listed.

The short answer is:

  • Use ASP.NET MVC if you intend to properly build a web application with modern programming conventions and industry embraced patterns for the ASP.NET platform. On the down side you will be expected to know how HTML and client-side resources (Javascript, CSS) work as well as ramp up on the MVC programming mindset which has a steep learning curve but reaches a sudden end once grasped.
  • Use ASP.NET Web Forms if you're using or want to use a GUI-centric, RAD (Rapid Application Development), drag-and-drop approach to prototyping something very quickly, i.e. push-button / data grid behavior wired up within 15 minutes, and the solution is not intended to be something supported by developers. Or, Use ASP.NET Web Forms if you have a background in GUI or Windows Forms development and you desire to transfer your knowledge to the Web.

But to look at this properly, you have to understand the history of each.

ASP.NET Web Forms was Microsoft's answer to those who had been building dynamic web applications using Visual Basic 6 ActiveX controls, VB6 DLLs on the server, and ASP Classic. At the time, web development using these Microsoft tools was a real mess. Along with the entirety of the .NET Framework which was the output of Microsoft essentially going back to the drawing board on how to do productive business programming on the Windows stack, ASP.NET Web Forms was, in its day, amazing and beautiful.

The whole approach was to give developers the best of both worlds of something very similar to Windows application development, but with the power of internet services. The idea was that, just as with a VB6/WinForms "Form" (a window) likewise a web page is a form (just like a window, see), and on that form you could drag-and-drop labels, textboxes, data grids, buttons, and other things that VB/WinForms GUI developers were accustomed to.

To make a button do something, after dragging-and-dropping it you just double-click it in the designer and boom you're in the code editor, telling the form what to do when that "click" event happens. This was exactly how Windows GUI developers created software using GUI tooling of VB6 and competing tools, except now the code is executing on the server! Wow!

This was 2002 technology. Amazing and beautiful in its time as an answer to internet-enabled GUI solutions for RAD development, it brought a sense of power to a messy world of software developers that had business objectives that they needed to accomplish.

Unfortunately, this programming model emphasizes so much the metaphor of Windows GUI programming that it carries with it the burden of its necessary implementation details, all the encumbering baggage necessary to accommodate the event life cycles and the tucking away the ugly details of the simple HTML and script that these drag-and-drop components and controls would output. And at the end of the day, developers supporting real applications inevitably had to dig deep into these components or write their own, and consequently they would fight battles with this infrastructure, battles which would leave behind piles upon piles of cruft, pulled hair, and tears.

Back up. Wash your hands. Let's look at the business problem again. What are our business objectives?

We need to build and manage web applications. Our constraints are that we have the World Wide Web, which sits on HTTP, HTML, Javascript, and CSS, and on the server we have business rules, databases, and a small handful of great programming languages (e.g. C#). Do we really need this Windows GUI metaphor to drive our development methodology? Why can't we just focus on the application problems and do away with the GUI metaphors?

This is where ASP.NET MVC comes in. It started out by a rebellion of developers who called themselves "Alt.Net" who wanted to get back to proper and pure software development principles. No more muss and fuss, just focus on business objectives and software best practices.

What this really translates to in this case is:

  1. Separation of concerns. For example, a data component doesn't need to know how its data is going to be rendered, nor should view markup be encumbered with database connection configuration details, and in this way a developer can focus in on his area of concern when editing and testing code.
  2. Exposure and full support for exposure to the nitty gritty of HTML and related resources. In Web Forms, HTML is tucked away, developers are discouraged from fussing with that. In ASP.NET MVC, developers are rather encouraged to manage those details; in fact it's a necessity. The advantage here is that the developer can re-learn to appreciate the clean semantics of HTML, CSS, and script, and work with it rather than against it.
  3. Testability of business objects. Controllers and models are much better suited for programmatic unit testing, so that implementations can be validated to meet business objectives, and changes can be verified that they will not break. With Web Forms it was difficult to test as components were not designed to be tested individually and the entire development output revolved around page forms and their event lifecycles with the muck of business logic and presentation logic deeply intertwined.

Note that HTML is already a very high-level markup language, as is Javascript a high-level programming language. The whole story would have been different if we were dealing with Assembly language and C.

Expanding upon #2, then, another objective of ASP.NET MVC is to enable developers to organize the front-end details of the 'view' portion of their solutions and take advantage of the rich foundation that the rest of the industry has built upon the front-end client platform.

You will find that ASP.NET MVC developers feel at home utilizing rich Javascript libraries and client-side templating techniques without fighting with the server-side architecture. This was not originally the case with ASP.NET Web Forms, because Web Forms doesn't want you to look at the HTML or script at all, except if you really have to, in which case, beware, it is not for the faint of heart.

  • This is a good answer, but #1 and #2 are wrong (WF does not require a component to know where its data comes from, it is an option and you have always added HTML to your ASPX files to support the asp tags you are rendering. You have never needed to dig deep and fight the controls unless you were trying to access an ASP feature not intended for developer interaction. The big points are testability and design pattern.)
    – Trisped
    Commented May 13, 2016 at 23:28

I am a complete and total convert to ASP.NET MVC and have not looked back, that said I do still have to maintain several very large WebForms apps. Here's my take on it:

Use these when you have some serious heavy lifting to do with grids. The grid controls are really very nice when you have a simple dataset that fits nicely in a tabular format and you want to provide a simple way for users to update records. Yes, I know that MVC 4 has a really snazzy Ajax list-type thing that you can use which works great but, in our business we often need to get something running yesterday and good old-fashioned grids work great and users are happy to be able to tab across a grid with glee. For me that's really the best thing about WebForms for me; but, as Ryan pointed out WebForms can be a big time mess because you're playing both sides of the fence from a nifty code-behind file. It can be both a rose and a thorn at the same time to keep all of your controller-type stuff intermixed with your view(s).

Use this when you really want to roll your own and you have the opportunity to start an application from scratch. Having a clearly defined MVC application is a bit more work to get started with but its benefits in maintainability outweigh the initial setup cost. If you want to do interesting Ajax interactions, prefer to write your model with code, like clean url's and routes, and be able to control the entire flow of your app then this is definitely the way to go. It takes some getting used to at first but I think it's the better option for greenfield apps.

In conclusion, for me, it comes down to grids and !grids. :)

  • +1 for the nice picture delivered with "playing both sides of the fence from a nifty code-behind file".
    – Marcel
    Commented Feb 7, 2013 at 9:40
  • Very helpful this one. I'm doing a very heavy grid based app and I've ruled out silverlight, xbap and it was down to a show down between these two. Commented May 8, 2016 at 10:43

My experience:

  • Wrote CakePHP projects for one year.
  • Completed a medium sized Webforms project over six months.
  • Worked on a Windows Forms project for three years.

After that experience, I tried writing another app using webforms, and got frustrated after struggling for about a day with how webforms attempts to shield the developer from the reality that they're developing an application which uses html, javascript and css.

I then tried MVC out, and having more direct control over the output (and some experience with the MVC paradigm from CakePHP) I was able to complete that simple app exactly the way I wanted it in about 1/2 a day.

The availability of powerful UI frameworks like jQuery very much eliminates the appeal of giving up direct control of the output in favor of using often bulky pre-built UI components.

  • 2
    @JimG - Uhh, anything which involves a person entering records without interesting associations into a database, and having that person or someone else read/print them at some other point can be basically scaffolded using an MVC framework. Granted, that isn't most apps, but it's a heck of a lot more than you can do with Forms. I guess your -1 proves my point.
    – mootinator
    Commented Jun 17, 2012 at 16:46
  • 1
    That's 1/4 of a day.
    – mootinator
    Commented Jun 18, 2012 at 0:12
  • 1
    But if the requirements amount to "I need an app with two roles, one to record some information, the other to look at it, and I don't really care what it looks like." Then, yes, that's quite doable.
    – mootinator
    Commented Jun 18, 2012 at 0:19
  • 3
    im sorry, but developing a webforms app to enter data and view data is so simple, that it can be done in a few hours. creating the structure of an MVC app, Controllers, Views and Actions, would take the same amount of time, but will not get you to a finished product. Commented Jun 20, 2012 at 15:41
  • 2
    @Dementic Usually for a simple MVC app one builds models, then scaffolds controllers and views and/or generates scaffolded controllers/views. Nothing really time-consuming there.
    – mootinator
    Commented Jun 20, 2012 at 18:32

I prefer webforms because my background is windows development.

Speed of developmnt is a key issue, and I can easily pass a problem to someone in india to fix overnight with forms, also, if I have a speed issue on a page, a really good book about asp.net speed is handy ( Rick Kiessig is the man ).

webforms is for ex windows people mvc is for web people

but, in the modern world, where Rick has written an awesome book, with servers increasing in speed daily and cheap coders in India, well, webforms has the edge


My 2 cents is to always use ASP.NET MVC for new projects if you have the option. In my opinion, webforms is not a good way to develop web apps, period.

I think abstracting away basic REST is bad, the entire postback model is bad, the way html/css is handed with a reliance on the GUI editor is bad, the emphasis on stuff like wizards and GUIs to set stuff up is bad, the URLs are bad.

  • could you explain in more details why you think so?
    – gnat
    Commented Jan 16, 2013 at 7:49
  • i think abstracting away basic REST is back, the entire postback model is back, the way html/css is handed with a reliance on the GUI editor is bad, the emphasis on stuff like wizards and GUIs to set stuff up is bad, the URLs are bad, etc and so on Commented Jan 16, 2013 at 14:16

I have read all the answers and feels my personal experience would add something to the answers above.

3-4 years back, I developed 2-3 website projects using Webforms. Around that time, MVC wasn't around or i didn't heard of it. The development was naturally(I was coming from Win-forms development with no prior web development experience) fast for me, since i need not to learn HTML in details and web-controls helped a lot (a hell lot, it made life easier).

Now, after all that time, i wasn't working any web project until recently and merely building some windows application using WPF.

Few days back I had an idea for a website and thought of developing it : this time around in MVC (since its talked about everywhere, besides i needed to learn either, so i choose MVC). The project is still in development phase, since i am still learning and building together.

So, the Key differences i find b/w the two are following :-

  • For someone coming from windows development, Web forms will always be favorable. Asp.net learning curve for a windows developer is bit steep

  • For someone coming from web development in some other technology, MVC will be favoured since it mocks the latest of them all.

  • Development is easier and cleaner in MVC if you are equipped with good knowledge of HTML and CSS

  • Deployment is still an issue. In web forms one just needed to do copy and paste. But, this requires some things to be done.

In short, both of them will stay here for a while.


I've not seen this consideration put forward amongst the existing 15 answers to this thread yet, but I think it's worth considering.

From my experience Web Forms is more similar to Win Forms and WPF than MVC is. Given this, I think one might consider choosing Web Forms when the team has most experience in that kind of tech, or when the Web Forms project will deliver an interface on to the same data set as an existing (or concurrently developed) Win Forms or WPF project. Doing so allows developers to cross between projects more easily, since application logic may be quite similar between the two.

As other answers have pointed out, development on the MVC framework is more similar to web development in Ruby, PHP, Python etc than its Microsoft counterparts; so naturally the choice of MVC can be influenced by the teams experience in those areas, along with the factors submitted in other answers.

  • +1 Certainly a reasonable argument for Webforms. My fear is that teams follow this mindset to avoid learning new things. MVC is filled with many patterns that may be unfamiliar to a team. Learning these types of patterns and implementing them leads to better adherence to SOLID principles which translates to better overall maintainability. These proven techniques are the also the real key to re-useability. Commented May 2, 2013 at 13:17

Our reason for not going to MVC a few years ago was it was an immature technology from Microsoft. Over the past few years we are now on a more mature version (4) and MS seems to have worked out where they are going with this. However, we are still reluctant on developing major LOB apps using MVC as the features we want to use in version 4 require a windows 2012 server (re web sockets via IIS8). I reckon in 1 more year we will be more accepting of MVC as hopefully more third party controls will be available, the technology will have settled, and we will have the infrastructure to support it.

  • 1
    Would you mind listing some of these features you say require Windows Server 2012?
    – MikeTeeVee
    Commented May 18, 2013 at 18:49

This decision depends on your preferences, on your requierements or even on your knowledge and experience.

The time for training learning MVC or time to get a delivery. All this things matter to choose one or other aproach.

Is not that one is better than another, simply both aproach or frameworks have pros and cons.

Personaly I favor MVC 3, I recommend you to try an get your own experience, but I need to say that program in MVC is a clean, fun, flexible, extendible, secure and structured way.



The only reason why I would choose the WebForms instead of MVC is because you have much more 3rd party UI controls for WebForms than MVC. I choose MVC because I worked too much with WebForms and I want to work with something fresh / new, but still from MS shop :)

Basically, nothing prevents you to turn off the viewstate in WebForms and use ViewModels and if/for loops instead of model binding and server side controls.

Is this WebForms or MVC code:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

The only limitation I found in WebForms is that if you use Dependency Injection / Inversion of Control, you can't have constructor injection since WebForms pages must have parameterless constructor, so you have to use property injection. Is this really such a big deal?


ASP.NET MVC is really an answer to Ruby, and the new, trendy, and (IMO) better way of decoupling the browser(client) from the server as much as possible.

ASP.NET Webforms gives you a lot of control over the client from the server side, with direct access to pretty much everything. Essentially your view and controller are one in the same, which gives you a lot of power, and most times a lot of mess.

ASP.NET MVC separates the view and controller by detaching the tight coupling of a .aspx file and the .aspx.cs file which accompanies them in webforms.

Essentially, the difference is having your much more (typically all) of the processing to display data to the view file, and leaving the business logic and the rest in the controller, keeping them both cleaner by convention, but also with less access to each other than webforms allows.

  • So WHEN should webforms be favored over MVC? This does not answer the original posters question. Commented Jul 22, 2011 at 17:35
  • @WeekendWarrior - It does, when you want more server-side access to the client, choose webforms. If you want more decoupling of the client/server in your code, choose MVC. At the end of the day, they both do the exact same thing. Reroute filters do the same thing as the MVC urls and you can move webforms code behind to a separate middle tier to decouple it more. weblogs.asp.net/scottgu/archive/2010/01/24/…
    – Ryan Hayes
    Commented Jul 22, 2011 at 17:43
  • Regarding your third point, that business logic ends up in the .aspx.cs file -- I think this is the fault of developers. It's not /supposed/ to be there. In Webforms, the .aspx is the "view", the .aspx.cs is the "controller" equivalent, intended to process the code that directly relates only to the UI by polling a business layer or coarse grained business facade layer. The fact that people put business logic in the .aspx.cs is just poor programming. They could also put business logic right in the view in MVC! MVC doesn't force separation of these things.
    – James
    Commented Dec 1, 2015 at 8:52
  • Essentially he is more right then other answers posted here. ASP.net is the basic idea behind a modular web technology family as created by Microsoft. ASP.net MVC module might be a temporaly hype but for sure its not the last, it all starts with ASP.net, so when to choose ASP.net, if you dont think that MVC is not your thing, maybe your more into something else OWIN or ... , something more advanced, or made your own framework for your tasks. You might not even need ASP.MVC and skip it and go Owin or Katana, but untill your there use asp.net
    – Peter
    Commented Oct 24, 2016 at 14:31

In my opinion, they are related enough and have roughly the same capabilities that it should come down to preference.

A great WebForms developer can produce a product equally powerful as a great MVC developer. But the great WebForms developer trying to force himself/herself to adopt MVC is going to come up short. Same goes for a great MVC developer giving WebForms a shot.

They are not completely separate entities, and as long as Microsoft continues supporting both, I believe you will continue see a mixed group of exceptional developers for each.


This is all about personal choice, assuming we are all proficient with the technology we use. I have been using the WebForms design approach for many years, and I must say that the only downside is that due to it's simplistic approach, many people do not take their time to unearth it's vast capabilities.

I recently used MVC to complete a project, and while I quite like the design approach to application development (which gives you more control, clean urls, SOC, etc), there really isn't much it provides, that WebForms can't. In fact, the emergence of jQuery and it's workings with WebForms (as well as MVC) has made these arguments less of an issue. And when people talk about separation of concerns as an advantage MVC has over MVP, I ask them how much they know about Object Oriented programming and how much they put into use the principle of abstraction and polymorphism.

I am currently comfortable using both technologies and I pick and choose based on the situation. Frankly speaking, it is up to you, but the truth remains that not everyone takes their time to learn in depth what a particular technology is capable of.

  • Ditto on the vast capabilities of webforms. Most folks are seeing the training wheels of webforms and comparing this with MVC. Commented Aug 4, 2016 at 14:33
  • There is little sense in learning an abstraction on top of HTML and Javascript in this day and age (even in 2013). It'll do you no good for your future opportunities. HTML and Javascript is just fine the way it is. Fighting it is a losing battle.
    – user441521
    Commented Aug 10, 2017 at 19:18

When faced with a programming problem I often look to the web for answers. Webforms has tons of information/components on doing just about anything. In MVC due to fewer sources online and the layers of abstractions needed to make something work has put a limit in things that I could once do. MVC total kills my productivity as a developer while with Webforms it ain't. So for now I'm sticking to webforms until MVC has matured enough to replace it.


Well, WebForms have more learning resources available (simply due to the fact that it's older) and thus new programmers that aren't "in the know" will be more likely to find information regarding this older technology as opposed to the newer stuff like MVC.

Senior/experienced programmers are older and will be more proficient in the older technology due to the fact that they've programmed in it longer than they have in the newer one.

Unless you can spend the money and effort to get your guys as proficient in MVC as they are in WebForms applications, you're undoubtedly going to try and hold off upgrading to the new platform for as long as possible.

So it presents several logistical problems: Do the benefits of MVC outweigh the cost in terms of lesser quality and deployment time? If I have a site written entirely in WebForms, would it be worth the effort and money to integrate MVC into it?

As stated by a previous commenter, MVC also prevents you from achieving the same level of interface with the controller as you would be able to with WebForms. While I'm all for the "Keep the user from stuffing things up/learning" side of things, it can still be unreasonably troublesome for teams to deploy/implement a program that fanatically sticks to that paradigm for everything they write.


Let's imagine there is only MVC framework in .NET platform and someone says:

"we need to evolve a new framework specific for enterprise solutions, based on asp.net, that will focus on rapid business applications development and abstract html as an pre-designed presentation layer."

WebForms could be the outcome.

When I worked with WebForms I saw data controls, state management, modularity, composition ... not html. Html wasn't the case or focus.

Not the answer you're looking for? Browse other questions tagged or ask your own question.