Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
@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 Nov 13 '11 at 12:29
@Darknight whatever makes you happy -> if you like WebForms go crazy with it ;) – Raynos Nov 21 '11 at 13:22
@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 Nov 29 '11 at 18:44
IMO, never use webforms when you can use MVC instead. – scottschulthess Jan 15 '13 at 19:23
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). – MasterMastic Jan 24 '13 at 14:09

20 Answers 20

up vote 87 down vote accepted

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.

share|improve this answer
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. – P.Brian.Mackey Jul 22 '11 at 19:26
@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 Jul 22 '11 at 19:39
@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 Jul 23 '11 at 19:20
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 Nov 29 '11 at 20:27
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. – The Muffin Man Apr 3 '13 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.

share|improve this answer
+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 Apr 3 '13 at 14:42
The most of things you mentioned here are not true (but I won't give you a downvote). Nothing prevents you to turn off the viewstate in WebForms and use ViewModels and if/for loops instead of data binding and server side controls. – šljaker Nov 27 '13 at 22:59
@answerer , you haven't pointed out the most important , test driven development with mvc is very easier,, and does it possible to do the same with ? – vishal sharma Mar 2 '14 at 11:25
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 Jul 30 '14 at 10:02
@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. – Kuncevic Dec 27 '14 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.

share|improve this answer
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 ( Calling him an "expert" is an enormous understatement ;-) – codegecko Aug 15 '12 at 18:09
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 Sep 23 '12 at 16:47
"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. – John MacIntyre Jan 17 '13 at 0:37
"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 May 29 '13 at 7:22

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. :)

share|improve this answer
+1 for the nice picture delivered with "playing both sides of the fence from a nifty code-behind file". – Marcel Feb 7 '13 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. – frostymarvelous May 8 at 10:43

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.

share|improve this answer
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 May 13 at 23:28

This answer is going to get downvoted into oblivion but, on the whole I see WebForms as being for cargo-cult programmers, while MVC is the technology of choice for more seasoned developers who understand the importance of simplicity & maintainability.

share|improve this answer

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.

share|improve this answer
@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 Jun 17 '12 at 16:46
That's 1/4 of a day. – mootinator Jun 18 '12 at 0:12
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 Jun 18 '12 at 0:19
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. – Dementic Jun 20 '12 at 15:41
@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 Jun 20 '12 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 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

share|improve this answer

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. 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.

share|improve this answer

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.

share|improve this answer
could you explain in more details why you think so? – gnat Jan 16 '13 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 – scottschulthess Jan 16 '13 at 14:16

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.

share|improve this answer
+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. – P.Brian.Mackey May 2 '13 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.

share|improve this answer
Would you mind listing some of these features you say require Windows Server 2012? – MikeTeeVee May 18 '13 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.


share|improve this answer

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?

share|improve this answer

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.

share|improve this answer
So WHEN should webforms be favored over MVC? This does not answer the original posters question. – Steven Striga Jul 22 '11 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.… – Ryan Hayes Jul 22 '11 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 Dec 1 '15 at 8:52

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

I think the gap between these two technologies isn't as wide as it used to be.

  • Web forms can use the routing engine that MVC uses ( or something very similar).
  • The script manager can combine scripts, load from a CDN, and even delay the loading of scripts.

To directly answer your question I think it comes down to preference and/or what the project is. They both take a significantly different approach to development. Personally i've been working on moving towards MVC, but still enjoy working with Webforms. I think the answer to wether you should use MVC or Webforms is for you to decide through experiencing both technologies.

share|improve this answer
Webforms and MVC recommend a radically different web development attitude by default, this is important, few developers deviate from "the default". Both of them can be used to achieve the same thing though. – Raynos Jul 23 '11 at 18:26

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.

share|improve this answer
Why was this downvoted? – lunchmeat317 Oct 23 '13 at 2:07

protected by Community Apr 14 '14 at 11:11

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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