I've heard Jeff Atwood, Joel Spolsky, and many other legendary people talk about how the ASP.NET Web Forms model sucks (so this question is kind of directed to them, hopefully Jeff is reading).

Now, I highly respect their opinion, given their background and expertise, but truth be told, I absolutely LOVE Web Forms. I think the model is brilliant, and it sucks if you have no idea what you're doing, but once you understand how to control ViewState, when to use handlers instead of pages, etc, it is generations ahead of all the other models.

So every time I hear someone complain about how it sucks, I can't help ask the same question...
Why? What is it that's so bad about it?

I appreciate all opinions. I'm assuming there's probably a post at Jeff's blog talking about this too...

+48  A: 

I wouldn't say it sucks -- It's really more of a mindset thing. WebForms is great if you're coming from a Windows development background. The same skills are almost directly transferable. You can handle button clicks, etc. with events and delegates and the ViewState / PostbackModel handles all of the complexity for you.

Sometimes, however, the ViewState / Postback model can get in your way and really make things more complicated. That's where the ASP.NET MVC Framework comes in. If you would prefer to be closer to the standard method of Web Development and do not want to deal with ViewState, etc. that is the way. There are numerous other advantages for MVC if you want to seperate concerns / test but I won't get into that here.

Neither is the one true way to develop a website. I prefer MVC but it really depends on the mindset of the developer / team.

Ryan Lanciaux
In what ways does the ViewState / Postback model get in your way? What is the standard method of web development, MVC I'm guessing? You didn't provide any substance.
Sorry this was not enough 'substance.' My intent was on answering Daniel's question. For more information please check out There is a lot more data available there regarding the differences between WebForms and the MVC Framework.
Ryan Lanciaux
@Ifoulkrod: I actually prefer the Webforms model, but I can see Ryan's point. You have to understand the page lifecycle etc, but once you do, I love the abstraction. why re-invent the wheel right?
"WebForms is great if you're coming from a Windows development background." - What you're saying here is that it's great if you don't want to learn the proper way of doing it on the web. The Web is a stateless place, and trying to make a semi-working abstraction above that is just stupid in my opinion. If you're going to develop for the web, learn it. When you've learned it, Webforms is both complex to work with, to understand, and limits you a lot if you want to make quality web apps.
Arve Systad
And what's good about the MVC Framework versus Webforms is not the Model-view-controller setup itself, but the fact that it communicates the proper way - totally stateless. It requires no hidden viewstate-values or ugly IDs on your elements!
Arve Systad
@Arve, as Winston Fassett said - it's our job to handle web as it's better for us. Telling that mvc > webforms cause web is stateless is like saying that mvc < webforms because web is built wrong in essence. It doesn't actually matter here.
Arnis L.
Arnis L: Webform tries to make web apps something they can never be. MVC treats the web as the web it is. If you want to make *quality web apps* with *clean HTML output*, you cannot choose WebForms. To me, as a web standards-lover, this is an important aspect. You cannot achieve proper best practice-HTML with Webforms (unless you cut away all webforms features, taht is)
Arve Systad
@Avre, having worked with Web Forms at a number of companies, I can say it is both frustrating and rewarding in equal measure. I would argue against saying a framework which helps mantain state is "stupid". It mostly works well in my opinion.
+26  A: 

ASP.NET doesn't "suck" per se; it attempts to address a situation that sucks, viz, interacting with the user over a stateless network barrier, in a way that is transparent not only to the user, but as transparent as possible to the developer.

This approach to the problem reminds me of #3 from Joel's Three Wrong Ideas from Computer Science.

Network software should make resources on the network behave just like local resources.

Ultimately, you just can't get the kind of seamlessness you want in that environment.

+38  A: 

It does not suck. In many ways MVC is a step backwards. Go ahead, vote me down.

I have been evaluating ASP.NET MVC, and I plan to stick to the current web forms model. I realize that the web forms page lifecycle is sometimes a challenge, and it does not cleanly separate the view and the controller (in a traditional sense), but the purpose of that separation is to enable an entirely different view layer to be created on top of the other layers. For most of us, that is wasted effort.

And I really don't like the tag soup that you get with MVC.

And I really like my ASCX controls to be full-featured components that do more than just render html. I like ASCX controls that are aware of the database and can completely encapsulate their functionality without relying on a complex object model. And I like that they appear as clean xhtml tags to a designer.

Eric Z Beard
"the purpose of that separation is to enable an entirely different view layer to be created on top of the other layers"Not strictly true. Having a clean separation of concerns makes it easier to evolve and maintain the application. And then there´s testability as an added bonus.
Fredrik Kalseth
Lol @ Tag soup. Lol @ ASCX controls. Tag soup is only a problem if you do more than if/else or foreach. ASCX -> u have RenderPartials .. which are basically the same. Each to their own. Enjoy your WebForms!
How do you get Tag soup with ASPNETMVC, and *not with Webforms?!*Webforms badly abstracts away the *way the web is supposed to work* - nuff said.
Arve Systad
"the way the web is supposed to work" according to whom? Use whatever is best for your application and your team.
So... Web forms model sucks because you don't like "tag soup" that you get with MVC? Damn, this is getting confusing. ^^
Arnis L.
If you're getting tag soup in MVC, you're doing it wrong.
Adam Lassek
Reminds me quote: "Resharper is bad for real life projects, because .aspx gets huge and Resharper just crashes". :D
Arnis L.
+1 I would vote this up 100 times if I could. MVC is total step backwards. This is especially true in terms of productivity. I have to write most controls that exist in forms all over again in MVC (pointless). I refuse to use MVC until they have a decent suite of controls.
MVC is a great framework, but it is a productivity nightmare in real-world environment with tight deadlines. Unless you're willing to dedicate serious resources to 'figure it out' and not only that, but explain your business staff why you're 'wasting' time instead of getting projects completed, you will not stand a chance. It's probably different from one company to another, but it's hard for me to see a typical .net shop converting unless they really really see tremendous benefits.
+13  A: 

One major reason it "sucks" is it's very difficult to unit test (nigh impossible?). There is no separation between presentation and business layers so unit tests have to drive the UI to test other bits. There is NUnitAsp but I've only used it on one project because it's pretty nasty (it's also no longer supported).

+101  A: 

I'm going to quote from Joey Beninghove's recent PPT posting on his blog.

  • Page Lifecycle
  • Page/Control Hierarchy
  • Server Controls
  • Postbacks javascript: __doPostBack(‘$ctr2785$RepositoryDashboard$hypDownload','')
  • ViewState
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" 
  value="/wEPDwULLT9udHJvbHNSZXF1aXJlUG9zdEJhY2tLZXlfXxYCBTVjdGwwMCRjdGw..." />
  • INamingContainer
  • Meaningless Urls

I think he summed it up pretty well.

Basically it boils down to the fact that WebForms is a stateful abstraction over a very stateless protocol. It abstracts reality away from you and produces troves of developers who don't understand the basics of a simple form post. MVC frameworks embrace HTTP and HTML, and thus are much more suited to the web.

Ben Scheirman
Huh? So you are saying that the webform model does not embrace HTTP and HTML? How is that? When all is said and done both the webform model and the mvc model will deliver an HTML document via an HTTP request.
the nasty urls part can be managed with url rewriting. But I agree on INamingContainer and ViewState part :)
They are fixing INamingContainer and ViewState in 4.0.
If I understand right, the routing library is available for regular too now. So I guess nasty urls are out.
While that's true for my apps, I bet most ASP.NET devs will just ignore it. It's not default, it's not enforced or even encouraged in WebForms...
Ben Scheirman
@Ben: you could argue that your mentions are what makes webforms great. Maybe improvements could be made under the hood, but I think the abstraction is what's so great about webforms. I worked with ASP3 for years, but thats the past, why make life difficult? let the framework do the hard work.
Nah, these things, while they serve a purpose (and that is to perpetuate a flawed abstraction) have gotten in the way in EVERY SINGLE webforms application I have developed. Sure I have benefited from some aspects, but the tradeoff isn't worth it - to me ;).
Ben Scheirman
@lfoulkrod he is saying that MVC works with the stateless HTTP protocol rather than against it (WebForms).
You forgot to mention viewstate adding huge bulk to the page, to serialize a lot properties that are largely redundant:
Chris S
+18  A: 

It's a subjective topic, of course, but I will try to explain how the other side sees web forms.

The main beef that many ASP.NET developers have with the web forms model is that it attempts to inject state into what should be a stateless application. The idea was to make the transition for VB6 developers as easy as possible -- and it did.

However, along with the ViewState and postback-driven event model came some annoyances. Specifically, large ViewStates in the rendered HTML that affects the performance of the application and an overall lack of control over the rendered HTML. The naming conventions of the server controls also makes it difficult to use Javascript as well.

But most importantly (in my opinion), the web forms is extremely difficult to unit test. Test-driven development (TDD) has become all the rage, and web forms are too tightly coupled. The page lifecycle makes it next to impossible to test how your app handles user input.

Kevin Pang
+10  A: 

I can think of a couple issues that experienced web developer may have problems with.

First, it seems to be designed to allow windows developers to build web apps without having to understand that they're no longer dealing with their familiar technology. This is one of my pet peeves - I've lost it on junior developers more than once for using a "link button" that requires a postback just for basic navigation. Sure, you can get something built, but it won't be any fun for your users.

The whole postback/viewstate/event model seems like a bit of a hack, too. It's great until it stops working, and the tools to trace thru some of the event processing are lacking (or, I'm just missing something). Nothing quite as frustrating as code that should work but doesn't. You might love viewstate, but I bet a lot of your pages are twice the size they should be.

"It's great until it stops working". I've been doing ASP.NET for 6 or 7 years, and have no idea what you're talking about.
I've come across some cases where I though "hmm, this should work, but it's not". Sometimes it's hard to figure out why something is not working in an webforms app since it pretty much generates all the HTML and Javascript for you.
This post smacks of developer snobbery - ASP.NET does an excellent job of lowering the learning curve for web developers. This is a good thing. ASP.NET has pros, and it has cons, especially if used irresponsibly. The same can be said for all development environments.
Richard Ev
@Richard it lowers the learning curve by fooling you into thinking the web behaves like winforms. It just sets you up for much greater problems when this leaky abstraction breaks.
Adam Lassek
+2  A: 

I'm going to have to agree with what Ryan says as one of the biggest problems I have found with WebForms is that the ViewState / Postback model can sometimes get confusing and get in your way when you are working on something.

I started ASP.NET after working with PHP and ColdFusion at previous jobs and found that it was simple to pick-up due to the similarity to the typical Windows development, but at points in time it behaves in unexpected ways. However, I also think that some of the complaints that you hear might just be due to the learning curve and getting used to do things differently.

+7  A: 

The ASP.NET Web Forms model can be seen as going against the grain of the Web since it tries to make web development like Windows forms development, which can make for a pretty leaky abstraction. It makes it easy to forget about the intricacies of the client-server request/response model as well as streaming once-per-request rendering whereas in Windows, you have paint-on-demand (or compose-and-display in WPF).

There's also the classic criticism that it makes it very easty to intertwine logical code with presentational mark-up but ASP.NET MVC isn't without that issue when using WebForms or some of the other templating engines as a View layer.

Mark Cidade
agree with you completely. In the midst of delegates and onclicks, you sometimes forget you are developing for the web, and are periodically reminded of it very inconveniently:)
+15  A: 

Thanks for your responses.


I understand the idea that it tries to make a webpage behave like a winform, and that if you assume that's how it works, you'll screw it up. That's why I started saying that you NEED to understand what's going on. You have to understand HTTP, and use the useful parts of ASP.Net and not the ones that bother. Ultimately, it depends a lot on what you're coding, and it DOES give you the flexibility to choose what to do.

In response to your points:

  • What's wrong with the page lifecycle and the hierarchy? Again, once you've learned it, it lets you do things you can't do in PHP, for example, because you're outputting as you execute down the page (the old ASP model that was good when it got invented, but we're past that now, frankly)

  • Server controls seem like a great abstraction too. They're extremely easy to handle. Would you rather have to output an <input> manually, and concat the value in there? Then read the value manually back from the POST?

  • Javascript postbacks: I'll give you that one. If you want to make a site work without JS, you lose the events model. But you're not in a worse position that you'd be in PHP...

  • Viewstate is another great idea, again, provided you know how to use it. It's much more comfortable than having to manually output and then read hidden inputs.

  • Naming Container is another one of those things I can't really hate. It automatically names my controls and there's no conflict. The ONLY case where this is a problem is if you want to manipulate those through JS, because you don't know in the client what they'll be called. So put a class in them, and use jQuery or Prototype. In the alternative, you don't get the Repeater, which lets you save much more time.

  • Meaningless URLs: URLs are just as controllable in .Net as in any other language, with a rewriting module, which you should be using anyway. Also, I don't see how .Net's URLs are worse than PHP's.


So again, the model is bad if you try to read a couple tutorials on it and consider yourself an expert. But once you get the handle of it (and it took me 3 months, it wasn't that bad), you can be many times more productive than with any other platform I tried.

I haven't tried .Net MVC, though. But truth is, given what I read, I think you're losing out on a lot of the things that ASP.Net DOES do well.

I do see the point about unit testing, though. And Ill admit that I don't have enough experience with unit tests (ie. never done one) to have an opinion. To me, everything is hard to unit test, as long as there's a UI.


Nope, my pages are not that much bigger than they should. If I had to output hidden input controls myself they'd be even more bloated. Once more, the problem comes with not understanding the model, and believing the marketing idea that you'll just code websites like a desktop app. That IS false, but once you get over it, it's an amazing model.

Daniel Magliola
+1  A: 


You may understand the model, and take the time to do things "right". Sadly, that makes you the exception.

There are too many "developers" who drag-and-drop their way to an ugly, unmaintainable user-hostile mess. While you can mess up in any language/platform, I see more horrible sites than anything else.

I see more horrible php sites than anything else.
Daniel Coffman
I see dead people
Gordon Carpenter-Thompson
+1  A: 


Right, which is why if "some dude" around there blogs about ASP.Net and doesn't like it, I don't really care.

That's why my question started "Why do guys like Jeff Atwood or Joel Spolsky think it's bad?" I mean, those 2 are obviously not "developers" who drag drop stuff... My point being... If experienced people that know their stuff don't like it, there must be some legitimate reasons BEYOND the learning curve.

Unit testing is the only one REAL reason i've been able to find. And technically, in MVC you need to write a controller class. You CAN write that controller class in the web forms model, if i'm not mistaken. I don't think Jeff or Joel will be obsessed about each byte that goes out in their HTML, or the ugly IDs that .Net generates (which again, i've done a lot of AJAX and i've never had a problem with).

Daniel Magliola
Look at the source of this page and then tell me how much you think Jeff cares about the HTML that is output from the webserver ...
@Travis: hmmm good point, i looked at the html and it looks unusually clean. But as long as the generated HTML from the WebForms model works without bugs and crashes, does anyone really care or stop to admire it's beauty? A larger page size will probably only make a marginal difference when page is being served to your browser.
+5  A: 


Take a look at this:

You should be able to radically reduce the size of that viewstate.

Daniel Magliola
I'd been looking for this article for ages. I read it just after it came out but lost the link!
+1  A: 

A little (just a litttle!) offtopic : The link regarding the understanding of the ViewState that Daniel provided is the best thing I've seen to describe the ViewState. Nothing else compares to this.

Andrei Rinea
Thank you. (this parenthesis added just to comply with stupid 15 char limitation)
Daniel Magliola
I love that article. I love re-reading that article.
+6  A: 

My Opinion: It's all about the leaky abstractions.

All abstractions leak, sure, but the 'quality' of them I believe can be gauged by how much, and how elegantly they do so.

Thinking of a web page as a 'form' is a nice abstraction, but as far as leakiness goes, it's marginally less watertight than the titanic. There are so many places where the forms model causes problems or make things difficult.
And when you do need to get around the forms model, it's ugly and difficult to integrate that code along with your forms code.

That is why the ASP.NET forms model sucks

Orion Edwards
+23  A: 

I keep hearing how WebForms mix the presentation and business logic, but it doesn't force me to do this in my sites. Does it in yours?

There's nothing keeping us from strictly separating our model (DAL), view (ASPX), and controller (BL classes) in the WebForms paradigm.

The fact that many current developers don't is a problem of education, not a problem of the platform. The same developers who poorly implement WebForms are likely to create just as much trouble with unmaintainable MVC tag soup.

No platform can compensate for people who don't know or care about what they're doing.

Also, suggesting that this is an ASP.NET only problem is a mistake. Suggesting that it's caused by too much leaky abstraction is also a mistake. Take a look at some of the (less abstracted) PHP code in popular applications such as WordPress, vBulletin, and phpBB, and you'll never complain about WebForms again.

Dave Ward
You're right that a lot of PHP code (probably most) lacks abstraction and ends up as a big ball of mud that makes ASP.Net look like a dream. Frameworks like CakePHP are allowing a much greater level of abstraction with MVC though. I see ASP.Net MVC as something similar.
Matt Ephraim
+1  A: 
 protected void Page_Load(object sender, EventArgs e)
            if (!IsPostBack)

For a seazoned developer, the code above will look messy. And for me personally it urges me to refactor everytime I see it.

But if I can pick one root problem with the Webform is that the Internet, the HTTP protocol, even the browsers where not designed to use POST requests as constant postbacks to the same page.

POST requests are just that: POSTs of data to the server. The browser SENDS something to the server, and GET requests means the browser is asking for some data.

The Webform model takes over this and perverts it and uses it in a way that it was not intended. As a result, you get a big hidden __VIEWSTATE in all your pages, you lose the ability to click on the Back button on your browser, and you loose functionality if JS is not enabled on your browser.

It's an abstraction, sure, but it's a bit pulled and twisted and you can see that when you design the app. You can then feel it when you code in it, and eventually you end up Hating it after a few years.

Webforms do a heck of a job in building Windows Forms application on a browsers, but do poorly in building a website or a public webapp.

"but do poorly in building a website or a public webapp"Wow, I didn't realize that. Maybe I should go back and rewrite all of those websites I built.
Chris Stewart
maybe you should
Right, but in the end, you can CONTROL all this. You can leave it as default for crappy internal apps, but when you're making a REAL website, you're not posting back all the time, you don't really have to, except in the cases where it IS useful. Yes, you have to *understand* what you're doing, but once you're past that, I don't see how "it sucks"
Daniel Magliola
+6  A: 

@Radu: The choice to poorly implement any of that functionality is 100% in the hands of the developer. The framework doesn't force you do to anything a certain way.

I've been developing WebForms since the ASP.NET 1.0 beta, and still haven't grown to hate them at all. For example, take a look at the source and functionality of this quickly thrown together site that I made with WebForms.

How big a difference will MVC make for me on that site? Very little, I think.

Additionally, since everything that happens on the site is encapsulated in either the business logic layer or a web service call (that leverages the same BL), it will be easy for me to migrate it to MVC if I wish.

Listening to people on the Internet talk about WebForms, you would think that I was forever stuck with an impossible ball-of-mud. My own experience leads me to believe that it's completely up to the developer, regardless of framework or platform.

Dave Ward
+1 great 'quickly thrown together site'
+2  A: 

@Dave: What I found relevant in this topic is that nobody can come with a respective list of this and that that makes the framework "suck". Some minor gripes,yes, but most of them are nitpicking,let's be honest.

There is nothing you can put your finger on, really, nothing much you can blame. I guess it just feels unnatural to some (as I'm sure MVC might feel to others).

+3  A: 

I always question the same thing, I have managed to write large and quite complex web applications using, and I'm able to have a clear separation of layers, into pieces that are fully testable. I can't be the only one that has figured this stuff out

I do mix it with MVC though, I do have a view and a controller for each control/page on the site, but it all works really well, it's easily extensible (through plugins), testable, etc... I don't get it either

maybe is just a bunch of "experts" that get stuck on something and because it doesn't work their way, then it must suck!

+4  A: 

Vanilla ASP.NET has been to a very large degree aimed at RAD (Rapid Application Development), with designers and codegeneration galore - which has shown itself to seriously hurt maintainability and testability.

ASP.NET MVC is an attempt to answer the paradigm shift we´re seeing with respect to practices like agile, TDD etc gaining more and more uptake in the industry.

It is not that we cannot build maintainable and testable applications with ASP.NET, it is just that supporting these practices has not been a priority in the design of the framework, which makes doing it more difficult than it should be.

Fredrik Kalseth
+6  A: 

Re: testability. You can unit test webforms, as well as MVC views, with Ivonna. It turns out that WebForms are much more testable: they have a very clear object graph, while MVC views are just long unstructured strings. On the other hand, since MVC views are just a mess of html mixed with code, and no design time support, there's no guarantee that you even closed your tags properly until you manually open the page. So, testability of the view is important, although nobody has mentioned that.

+109  A: 

I'm glad we're talking about this.

It's not so much the model / philosophy of WebForms (being component-oriented, that is) that sucks as it is the implementation. And even that bit is not all bad.

While WebForms definitely merits criticism, I think it's incorrect to jump to the conclusion that MVC is a better / more virtuous concept. It's not. It depends on what you are trying to do.

Regarding the "patterns"

I'm not sure if the WebForms "pattern" has an official name, but let's call it a component framework. There are others, like JSF, which is a bit newer, and could perhaps teach us a few things. Contrast this with MVC, which is not component-oriented. Some people are opposed to componentization. For example, DHH in the rails community (the source of all the recent MVC hooplah), rants against components. However, his justification is more of an appeal to people to re-invent/re-work the wheel every time, because his goal is to make development "so very easy that you will treasure the application-specific solutions of your own rather than long for [components]". It is possible to hack up primitive reusable "components" in MVC. However, the more sophisticated and reusable you make your component, the more hackery you will have to do, because the goal of MVC is simplicity and separation, rather than composition / componentization.

Good Things about WebForms

  • You can compose very sophisticated, nicely encapsulated "controls" that can manage their own state, behavior, and rendering, and combine them into more sophisticated controls
    • Through them, you can accomplish a lot simply through declarative (.aspx) code.
    • For example, you can easily add a date picker that provides both client and server side validation because it has its own lifecycle.
    • Things like GridViews and DataSources - with robust editing, paging, sorting, and filtering capabilities, for example, are a very useful mechanism that couldn't be fully implemented outside of a component-oriented framework.
  • This is largely due to:
    • The component tree and naming containers
    • The page lifecycle - Page_Load, Page_PreRender, etc. enable several hooks that allow the entire view to be composed in one pass, but also modified before rendering in another pass (which is very useful if you are doing anything modular at all)
  • Mechanisms for tracking state (very useful when you need them):
    • ViewState
    • PostBacks (LinkButtons, etc)

Bad Things about WebForms

Again, most of these have to do with how WebForms is implemented.

  • The page / control lifecycle is complex.
  • ViewState is poorly implemented by the components, i.e. the convention of storing every property in ViewState, or that DropDownList doesn't work with ViewState disabled
  • There is no alternative to postbacks. Doing GET / QueryString-based forms is painful. And you can't have more than one <form runat="server">
  • There is no way to override the naming container strategy, which means ugly names for HTML elements
  • WebForms is stale and hasn't gotten many improvements. Probably due to concerns about compatibility, several new controls have been added, but the underlying architecture / mindset hasn't changed much.
  • Much of the framework and controls are mysterious and poorly documented. Plus it's closed source and that means that unless we want to live in Reflector, we are largely stuck with what we get.
  • Binding is horrible. The reflection breaks occasionally, Two-way binding is hard to use and unintuitive. There is no declarative way to bind to the QueryString. So we often spend a lot of time writing mindless binding/plumbing code. (I truly believe that a big reason people like MVC, and why people liked Struts and Rails for that matter, is because they handle binding well.)
  • WebForms is full of tight coupling that makes automated testing very difficult.


  • Regarding the URL-rewriting point, that's just not true. We are doing URL rewriting with WebForms. The .aspx extension is avoidable.
  • That the protocol is stateless is a moot point. It underscores the fact that we have to figure out how to manage state in our applications, and sometimes things like ViewState or PostBacks are the best solution. The flaw in the WebForms mindset is in assuming they are.

I'm hesitant to throw out the baby with the bath-water. We used WebForms for our social media site. We did a PoC in ASP.NET MVC as well, and found that it made a lot more sense to build robust, composable controls that could easily be moved from page to page, than to grapple with the limitations imposed by MVC's simplicity (and, in the case of the ASP.NET MVC framework, immaturity). I would much rather see MS overhaul WebForms, clarify the pros/cons with MVC, open up much of the source, and have the dev community support it as we have the MVC stuff, than for it to continue to be shunned (and neglected) as all of us jump onto the MVC bandwagon.

Winston Fassett
what do you mean "DropDownList doesn't work with ViewState disabled"?I mean, you need to fill it up every time, obviously... It'd be magical if it worked without viewstate and without refilling...Also, if you fill the Dropdownlist in IT's Init event (not the Page's), you don't need to disable VS
Daniel Magliola
Thanks for your thorough and very well thought answer.
Daniel Magliola
Yes, answers like these is what makes these very general questions actually useful. Great job, thanks.
Mr Grieves
Agreed, good answer!
Some of those implementation issues are improved on in Webforms 4.0. For example, check out the "Setting Client IDs" section in this whitepaper:
Luke Quinane
+37  A: 

Disclaimer: Junior developer speaking (<3 years).

I researched, printed and studied the whole page life cycle. At some point I even got it (I think) but I fail to see how the offered features were better then the things you lost because of it.
Because a list was requested, a list is given:

I didn't like because:

  • controls generate horrible HTML
    • use of tables for lay-out
    • id's are ridiculous
    • unnecessary tags
    • in-line styling all over the place
    • in-line scripting all over the place
    • invented attributes
    • mostly geared towards IE rather then standards
    • creating validating pages is hard
  • no way of altering HTML
  • Controls are a black box. I like control over my HTML.
  • dependency on JavaScript
  • generated code is unfriendly to CSS (even the CSS friendly set)
  • generated code is unfriendly to JS
  • URLs shouldn't need rewriting to be useful
  • bad HTML makes accessibility a joke (screen readers, font resizing etc)
  • Post-back model makes things state-full
    • hot-linking / bookmarking needs extra consideration to rebuild state somehow
    • viewstate needs tender care to limit bloat (my MVC pages don't have a single hidden control in it)
    • call me picky, but I didn't get why I should tolerate multiple page loads (post back model)
  • Raping the original REST model (without offering the features in an other way)

This doesn't mean I don't have some gripes with MVC either, but that wasn't the question..

Thank you for your answer. You make very valid points.I guess I come from a pragmatist place, where I don't really care whether my HTML validates (or has invented attributes), as long as it works correctly in all browsers.As for CSS, I found that you just need to get used to using Classes, not IDs
Daniel Magliola
And you can escape the Postback model in several ways. In fact, in my case, most pages won't post back, they simply show information and have links to other pages. And when they're for entering information, they also would postback if I were doing this in PHP/ASP Classic, etc.
Daniel Magliola
I do agree that inline styling is a HUGE pain sometimes.Clarification: I'm just posting my opinions here, not invalidating yours, to try and enrich the dialogue.I do agree with your points, they are very interesting.Thanks again.
Daniel Magliola
In my experience invalid HTML never works in all browers. Most (not all) differences in rendering are caused by browsers trying to interpret incorrect code in a way the developers think most suitable. These solutions lead to hacks, hacks lead to anger, anger leads to hate, hate leads to suffering.
classes and id's have seperate functions. Id's make an element unique, classes don't. With carefull programming you could off course emulate an id by using the class only once. There are other consequences too though:e.g.DOM traversing will suffer perf hits when searching for classes vs id's.
Thanks, I too am not forcing anything on anyone. But for me personally web dev was a pain in the ass before MVC came by. But again, that's me. I'm a control/order/perfection freak.
You nailed it on the last line.
Simon Gibbs
Last comment or post line?
The freak thing? Or the "it's your choice thing"?

I haven't played with ASP.NET MVC yet, but I'm looking forward to trying it out and testing with it. That said, I think the main reason Microsoft introduced it was to win over a lot of the open source PHP guys who were more familiar with the traditional model... that plus the fact that IIS7 serves their stuff up quicker!

Anthony ;-)

Not only the IIS7 many versions before. Now even apache can serve ASP.NET 2.0 :)
+1  A: 

It's a matter of perspective and priorities. Winforms absolutely suck if you have the 'right' set of priorities.

For many of you, you MVC would suck because you would resent having to do extra work just to get the same results. Bah!

Myself, I value separation of concerns and testability over most anything. Following that, I value control. I'm more than happy to spend a bit more time writing things myself because I know that they will work as I intend for them to work. And I don't have to jump through hoops to get controls to render how I want. And I HATE the page lifecycle ... every time I hit a bug that has some rendering dependency on those events I just want to scream "Why? Why am I having to deal with this?"

With MVC, that doesn't happen. I create my data. Good. I render my data. Good. Oh, and I'll handle a post here and there. Good.

What you're saying is that having to have control over everything, and doing more work, makes you more effective at your job? That's an interesting point of view...
Daniel Magliola
What I was trying to say (but did a poor job of expressing) was that with MVC I do a little more work upfront, and save a lot of time in effort in maintenance and bug fixing. I spend more getting the first version done, due to writing tests and explicitly handling more of the rendering, but in the end, I save a lot of time as there are less bugs due to the webforms's rendering pipeline and control oddities.
As a webforms developer since ASP.NET 1.0 beta, and an MVC developer since preview 3 who's built numerous apps in both... I can assure you it's far more work to "simplify" a webforms app than it is to "complexify" an MVC one.
+4  A: 

WebForms are for rapid development. You're free to like it, to use it, to get rich with it. But from there to the point of "Brilliant" there is a big step.

You said everything. When you understand the viewstate and the handlers. In that moment you can see how people can complicate their lives to get to the same point.


In the end is better not to use them, or use them for things you don't care about. Of course you need them to detect changes and execute events. But that's all, you go faster without it.

You have learned that: hey! viewstate is useful but use it carefully (and avoid it if you can). What's next in our list?

Handlers and Modules

The work usually is done through your "Page" extended classes. But you need some specific functionality that smells like these controllers people talk about. So you create a handler for your (let's make it easy) your file type, or process some headers, or even prepare some data for your "Page".

Well, where are now these drag and drop server controls? Where is the viewstate? You're programming more close to the server-client architecture than before. Web forms have disappeared from the map.

In the end

You organise your code, avoid viewstate and create modules and handlers to make your life more easy. Now is when you look at your web forms area, what's useful form there? There is any original control left there?

Does it S...

If it gives you money, perhaps the Brilliant here is you and the next question on stackoverflow should be: How to get rich with ASP.NET WebForms. :)

I agree with what you're saying, which is basically agreeing with me . I want to add is the abstraction that is left from WebForms is in any place where I need to have Forms that post data to the server, which you always end up needing at some point. MVC is WAY behind Webforms in this regard, and I don't think it'll ever catch up, precisely cause it's conceptually opposed to the idea of abstraction. Where I don't have Forms and my sites are all AJAXy, then yes, I'm not taking that much advantage of WebForms, except for the points where the *forced discipline* of MVC will make my life harder.
Daniel Magliola
@Daniel. I'd like to know more about that "way behind". As far as I know in many MVC forms are abstracted. And they're so abstracted that with an object they create the form for you, and you get back the object. So you don't type HTML, you get validations and you get back an object not a bunch of fields.
+1  A: 

Like Ayende says, it's a leaky stateful abstraction over stateless web.

I profundly disagree with him.
Andrei Rinea
@Andrei: it *is* a stateful abstraction over stateless web, so do you disagree that it's leaky?
Yes, it is, but it's easy to control the leaks, and they don't bother you in 99% of the cases, while they help most of the time. I've found MVC standing in my way in a lot more cases than WebForms, and also lacking a lot of useful functionality, and i've NEVER seen anything that it's easier in MVC than WebForms...
Daniel Magliola

I think the main difference is javascript. In webforms you have server controls that can encapsulate a small bit of functionality, in normal web development (mvc) you have javascript widgets that encapsulate functionality.

It is my opinion that most webforms developers don't know javascript very well and so they they stick with the server side controls. It is also my opinion that doing it in this manner lowers the quality of the end product.

Give me the same project in mvc and webforms and I can guarantee the end result will be better in mvc (and I know webforms fairly well). Don't get me wrong, you can do everything in webforms in the same way you do it in mvc, but there is going to be more friction during development to do so.

Whether webforms developers know javascript or not is their choice. That doens't make WebForms suck per-se. Again, I'm talking about people that *understand* how WebForms work. Also, your claim that "anything you do will be better in MVC" is bogus, can you justify that? I tended to find MUCH more friction in MVC than in WebForms, because precisely of the lack of abstractions. It's going back to the ASP Classic world, only that now I have to declare more stuff to pass information between the Controller and the View.
Daniel Magliola

In my opinion WebForms as an idea is not bad, not bad at all. It allows you to rapidly create web user interface for lots of purposes and even a very inexperienced programmer can achieve miracles with it. But...

It's always about the "but"'s. First of all ASP.NET along side with JSF tries to be "stateful" in a stateless environment which is wrong by definition of the web. Secondly they concentrate on "pages" instead of "content" to begin with. And last but not least since it is easy people tend to mix all sort of things with the presentation logic which leads to unmaintainable code.

The answer (a very very old one) to most of the issues stated above is MVC as a pattern. It should be of no surprise to anyone that the rapidly growing community of web frameworks like Ruby on Rails, Grails and Django are based on this pattern instead of MVP (like WinForms and JSF in Java world). It's simply easier to work with things like HTML, JavaScript and CSS than to learn tons of components and believe in miracles.

The worst part of WebForms along side with JSF is that at the end of the day you're completely out of control over what's being sent to the user. You might say that there are ways to actually take back the control but it's all artificial since the whole concept of statefull components is about hiding the browser from the programmer and exposing a more functional behavior. That in turn leads (in the case of some sets of components) to situations where you can't even do the simplest thing because someone else has already done something that forms a road block for you.

In my opinion the MVC pattern is not something that's going to be the silver bullet for web programming. There's still lots of applications written in WebForms with more JSF-based apps to come in the Java world. People simply like it right up to the point where they need to do some customization that would be done in a matter of minutes in pure HTML and it takes forever (or is even not possible at all) in the statefull world.

Matthias Hryniszak
Why is it wrong to try to be stateful on the web? In MOST web applications you NEED this to some extent. I agree the abstraction they try to make does leak, if you use it as if it's magic, but once you UNDERSTAND how it works, it's much better than all the alternatives.How many times have you written this in ASP/PHP?<input type="text" name="Email" value="<%=Request.Form("Email"%> /%gt;
Daniel Magliola
+3  A: 

Like many have noted, it's a stateful abstraction of a stateless protocol. There are far better ways to maintain state in a web application than using .NET Web Forms. Gmail does it just fine.

Web forms are an unmitigated disaster when working with a skilled team of JavaScript developers who are trying to develop rich client-side apps. Yes, Microsoft has developed their own AJAX code libraries but that only serves to further bind the back end to the front end. And yes, an ASP.NET developer can throw together some AJAX controls, but good luck getting fine-tuned control of your front end that way. We've all seen the garbage JavaScript that web forms create for its postbacks and the name mangling that it does to the form elements.

Here you DO have a point that is a pain for me. Controlling IDs, to be able to get a handle of controls in JS. I've resorted to using unique classes instead, and Prototype's $$ operator which is slower, but you just cache the results once. Either that, or declaring the actual ClientID in a JS variable when rendering.Both suck, this is very true.That said, I believe I'm a skilled JS developer and i'be been able to do very rich apps quite well. It's true that I'm not using the Webforms goodness in many cases, but I've found that Webforms gets i n my way much less than MVC
Daniel Magliola
Gmail uses Webforms doesnt it? ;)

I posted this in: What are the key strengths of ASP.NET Web Forms. (

Relatively fast construction of web applications, but relatively hard to maintain.

Relatively easy to learn. You don`t need to know html, css and javascript. However if you already know html, css and javascript other web development technologies might be easier to learn.

It's relatively easy to adopt web forms if you come from different technologies, because it doesn't require a strict methodology to be effective and because it supports multiple languages.

It's a relatively mature technology.

It's relatively easy to add new functionality to a web application, but it's relatively hard to change existing functionality while maintaining good quality of code.

Easy integration with windows applications, because it's event driven.

Many third party libraries available.

Relatively easy to deal with application state.

Relatively easy to deploy.

Platform independence (I do not have any experience with this, so I don`t know if this is true)


In theory it has good performance, but in practice it doesn't. Compiled code does not lead to better performance, because this is not the bottleneck in a web application. The bottlenecks are the amount of html that is send to the browser, how fast it can do string operations and the speed at which the database can be queried. It is one of the worst products on the market when it comes to these points.

Fast construction of web applications can be an advantage in simple applications or innovative projects where rival companies are developing a similar product, but in the majority of the time application maintainability is much more important than construction time.

The state-full nature of web forms is a disadvantage compared to stateless systems, because it will lead to many problems. External websites or bookmarks will not be able to link to all content directly as some content will only be available after performing a couple of user actions, so instead of linking directly to the website will have to link to and give the user some instructions on how to get to the referenced content. Most search engines will not be able to find most of the content. Using the back button in a browser can lead to errors. Connectivity problems or hibernation of the client can lead to errors. It can not take advantage of proxies which leads to bad performance in some cases. Proxies, gateways and cache can cause errors. Surfing the website while the website is updated causes errors.

I agree with sontek on that it can be easy to test if architected in the right way, but I disagree with sontek on that this is an advantage of web forms. Because in software architecture every advantage you create by architecture will also lead to a disadvantage. In this case it will lead to a disadvantage in construction time which is pretty much the main strength of web forms, so if you want a testable system it doesn`t make sense to use web forms, because then you can better use MVC or something like that.

I think you're straying from the point. You're mostly saying that .Net sucks because it has more than one language, and that things can be done badly (ie. search engines can't access content) if you want.I'm trying to compare Webforms to MVC, where all the problems you mention still hold. You still have 2 languages, and in every single platform you can choose to only show things after user actions, this is not inherent to WebForms.
Daniel Magliola
I agree.I copy/pasted too fast...
+2  A: 

Having used Monorail intensively for about an year before being forced, by a job switch, to get back to ASP.NET I can say that:

-- ASP.NET Page Life-cycle is it's biggest drawback, it tries to abstract too much. It would be nice if we could more easily mix things: server-treated events, server-direct-actions (which would need multiple post targets, perhaps multiple forms) and client-javascript. You can get part of it with Ajax controls and jQuery, but it then gets in trouble because of...

-- Naming of controls, which really messes things up for javascript, but seems to be improving in ASP.NET 4, and we still have lots of trouble with...

-- Viewstate, which easily gets bloated and is unusable in the client-side.

From the perspective of my 30+ years developing software, I think Monorail (and ASP.NET MVC as an evolving second-best) is preferable for large web applications over even the latest beta of ASP.NET 4.

Off-topic and i dont mean to be nasty, but using your perspective of more than 30 years in developing software does not necessarily add more authority to your opinion :-) Heck, i spent 30 years in software development, but did i tell you it was in maintaining Cobol or CICS apps ?
@joedotnot: Being a bit more clear 30 years, developing custom applications for businesses, shrink-wrapped desktop solutions, public websites, and also complex intranets. I've being developing in dozens of languages, such as Assembler, VB, C/C++, Java, C# and some Cobol, too.In the last 15 years I've developed web apps using: old CGI (with C), ISAPI (C/C++), old ASP, ASP.NET (since beta of 1.0), Java Servlets, Struts, JSF+JEE (all combinations of versions) and Monorail. So I believe my opinion is indeed backed by that experience and may be useful to readers here.
+8  A: 

I would sum it up in a single very long sentence:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="dDwyMDY4MTQ0OTQ4O3Q8O2w8aTwwPjtpPDE+Oz47bDx0PDtsPGk8MT47aTwyPjs
z4+Oz4+Oz4+Oz4+Oz4+Oz7HaZ9TtMVnMvFA2LTDoOKjt+xrLA==" />

Obviously the more astute developers know how to keep the 4-eyed ViewState beast in its cage, but for a large portion of ASP.NET web apps out there ignorance is bliss.

Chris S
+1 for the "ignorance is bliss" statement.
+2  A: 

This one is probably more than answered. But I want to add my cents anyway.

WebForms does not necessarily suck. It just uses a very unconventional way to solve the stateless-problem, which often seemed not to work out as intended.

I have had a LOT of hard times with webforms. Struggling with dynamically created ChildControls to get their events fired, being permenantly confused about UniqueId, ClientId and Id. In complex scenarios, it was a pain to get the correct ids assigned to recreated items, as this is required to get those events off. Obviously, I am not the only one facing this kind of problem.

The mvc framework puts you back in control. I really love it. But I will stop here, as you asked "why does webforms model suck?" and not "why is mvc better than webforms?" :)

+3  A: 

I think it might be worth the ASP.NET detractor's time to read a recent blog post from Scott Guthrie on this very topic:

About Technical Debates (and ASP.NET Web Forms and ASP.NET MVC debates in particular)

I quote:

"I often find debates around programming model appropriateness and abstractions a little silly. Both Web Forms and MVC are programming web framework abstractions, built on top of a broader framework abstraction, programmed with higher level programming languages, running on top of a execution engine abstraction that itself is running on top of a giant abstraction called an OS. What you are creating with each is HTML/CSS/JavaScript (all abstractions persisted as text, transmitted over HTTP – another higher level protocol abstraction). "

+3  A: 

Having used both, I will say this: what is very, very nice about MVC is that you have complete and utter visibility into everything. In WebForms, you're using Server Controls, and they do what they do. Yes, they offer properties, and also events and ways to plug into the lifecycle. That is a nice set of extensibility points ... but with MVC, you don't need extensibility points because the entire world is open to you.

Now someone will say, "Yeah, but you have to build everything yourself ... you have no components. If you want a grid, you have to build a grid."

Technically, that is true, but in reality, it's not quite like that. As an exaggeration to make the point (and this is hypothetical, like a "thought experiment"), consider this: if I wanted, I could start a WebForm project, drop a grid on the canvas, configure it to my heart's content, bind it to some data, run the app, and then View Source and copy all the html.

At that point, I can write a method in my MVC app that returns the html. At that instant, I have completely replicated the final output of the grid component. Now, I can start refactoring that method into a bunch of methods (and/or classes) according to my needs.

Ultimately, I will end up with something that generates the desired html, with no hidden parts, and over which I have complete control. It will be shaped by my own refactoring such that it provides the features I need.

The point of the thought experiment is this: Anything WebForms can do, I can do in MVC, but I have infinitely more control over the implementation in MVC, and infinitely more visibility into the implementation.

Would I do that? NO. That's why I said it was hypothetical. But the point is, C# code is good at slicing up functionality into reusable parts (classes and methods) and letting you build something complicated from smaller pieces. It's fantastic to use plain old C# code to build up a set of custom abstractions for generating html that are just right for your project. There are no longer any hidden places.

And putting the hypothetical aside, when I need a grid, there are so many excellent javascript grids to choose from. Same for any other component.

So I gain complete control and visibility, and I lose nothing as far as I am concerned.

Charlie Flowers
Ok. The part I hate about it is that you *have* to build everything yourself, but I do see and appreciate your point. Thank you!
Daniel Magliola
+1  A: 

Wow, I guess my head has been in the sand for awhile. I've really been missing out on this debate. It is like, "Who is prettier, Ginger or ,Mary Ann"? Sorry, if most of you miss that analogy - it is classic American pop-culture, "Gilligan's Island".

Maybe your technology flavor is personal taste. Not everyone likes red heads or blondes. The answer is whatever works for the problem at hand. The solution that makes sense. As people who solve problems and get paid for it, we should probably be adept at using either technologies when required.

I really think many have fallen victim to the Microsoft engine. Yes, it is the latest from the "dark side". That doesn't mean we have to accept it or deny it. Just use it if you need to. And if you don't, don't. I personally do not see MVC as a mature set of tools yet. But maybe later if more adopt it. My investment in ASP.NET 1.x and 2.0 has served me well. For the kinds of applications I build, I will continue to use it.

Please develop responsibly. Please develop responsibly. Properly abstract your code layers and separate your concerns. This is just good practice. No matter if ASP.NET MVC existed or not; you should be doing this anyway. Write good code and respect your craft. Use the right tools for the job. Stop arguing about which is better, when it is really a matter of personal taste or the right solution for the problem.

Technologies will come and go. But your approach, patterns, and designs should be based on principles that stand the test of time, not on what is on the cover of the latest MSDN magazine.

Matt Vaughn
+6  A: 

Just to give a little background...I've been a professional desktop developer since 1984. I've seen technologies come and go, and I've worked with many of them. I've been architecting and coding in .NET (C# and VB) full-time since 2002 and ASP.NET since 2004. Broadbench rated me at mentor level in ASP.NET, and I worked my tail off to become proficient enough in that technology to be a reliable information source to any development team I worked with.

In February 2009, I was first exposed to ASP.NET MVC after spending some time actively looking at Ruby for Rails. There are 13- and 14-year-olds out in the world developing comprehensive web sites using open source technology, like RoR. I consider myself a reasonably smart person, so I figured that there had to be a simpler path to web development that allowed you to produce professional, high-volume, high-transaction web sites without going through the literal pain that ASP.NET WebForms proficiency inflicts. When I found ASP.NET MVC, I thought that this path would allow me to see how the other half lives, while allowing me to leverage the C# knowledge I had already acquired, so I chose the framework for my next project.

A year later, I made the decision to never go back to ASP.NET WebForms. The primary reason is that I no longer need the crutch of an IDE-based development platform in order to build quality web solutions. The largest advantage of ASP.NET WebForms is that it was a very smooth transition to the WindowForms developers who were used to using designers, property inspectors, event-driven programming and other visual development tools to write their programs. WebForms is nothing but a Microsoft-created layer that sits on top of HTML, CSS and JavaScript...and it's a heavyweight layer. A lot of the frustration experienced while I was learning the nuts and bolts of the web was unlearning what I had learned as a WebForms developer.

ViewState, the page cycle, code bloat, no framework-enforced separation of concerns...those are easy targets of complaint when you're talking about WebForms. For me, the biggest reason to never go back to WebForms is that because I spent the last year learning XHTML, CSS, JavaScript, jQuery and AJAX in their actual forms (and not as Microsoft translated it to fit within the VB3 development model), I gain the following benefits:

  • access to a very LARGE cross-platform developer community
  • standards and frameworks that only change in response to the needs of that community, and not to the needs of corporate shareholders
  • extra money in my pocket and extra time to do things I want because I don't have buy and learn a new version of Visual Studio every 18-24 months because the next version of .NET is coming out and my current VS IDE won't work with it
  • working with Firebug without worrying about the fact that VS doesn't handle Firefox as smoothly as it does Internet Explorer

Don't get me wrong...WebForms opened many doors for me, and I am grateful for that. However, if I had the chance to do it all over again, I would probably pass on WebForms altogether and open a few of my own doors.

Neil T.
Thank you very much for your insight!
Daniel Magliola
I was building websites for years in PHP before I started using WebForms. When I started using WebForms I asked myself how other languages compete. Frankly going in the other direction (web development -> webForms) gives you a much brighter view of webForms. I think your experience just shows that developers should learn the basics of web development before touching a framework. At my job we've been doing web developer interviews. I can't tell you how many desk top developers we get who "built a web app" but can't tell you what the style attribute is used for.
+3  A: 

I think most of the points have been hit on but I would summarize web-form failings as follows.

  1. ViewState - This becomes bloated and page size and page load times are critical. Also, viewstate can be a pain in a server farm environment.
  2. Mangled Ids - This makes it hard to interact with javascript and css. I work with front end designers and html developers who build out a static version of pages html, javascript and css. The translation process is much more straight-forward with an mvc.
  3. Post-Backs and Single Form - These sort of work but not if javascript is disabled. I want my site to still maintain a level of functionality even with javascript turned off. In addition, what if you want multiple forms on the same page or if you want to post back to a different page. You have to do hacky stuff to support this.
  4. Code-Behind - We all thought this was a great idea when we moved from asp to That the markup would be in the aspx file and the code would be in the code-behind file. The only problem is what kind of code is in this file. On most of the projects I have seen, in ends up being an ugly mess of view related code to hide and show things, while at the same time business logic/controller code interacting with services and Business Objects. I know it doesn't have to be this way but doesn't encourage good practices.
  5. Page-Controller - By default follows what is called the page controller patter where each page is its own controller. This creates problems as the application gets larger. Imagine you have several 100 pages and someone asks you how a certain multi-step process works. You end up having to open 10 or 20 code behind files to see the flow of the application. With MVC you can organize controllers into logical groupings so it is easy to see in one class the different actions and flows.
  6. Unit Testing - It sucks in other than using browser driven testing methods such as watin.
  7. Web Controls - In an effort to make familiar to app devs they added properties for colors and other things. This encouraged people to use these and we ended up with a bunch of inline styles instead of css based styling of controls. These controls are also often less flexible when you want more control over the html.

I could on an on. In short if you want control over your html for a public site and a framework that encourages a proper separation of responsibilities i think mvc is the way to go. Not to say that web froms isn't improving and with discipline you can accomplish most of the same things but it doesn't encourage you to do this. I think web forms has it's place in the intranet and internal reporting applications but that is about it.