Stack OverflowWhy does the ASP.Net Web Forms model "suck"?
[+296] [39] Daniel Magliola
[2008-09-05 15:26:11]
[ webforms ]

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

(52) The bottom line is it tries not to use JavaScript, which makes writing dynamic pages impossible, the ViewStates make the page too large, viewstate validation is buggy, retaining JavaScript values between postbacks is impossible, all those postbacks make unit testing impossible and bug-elimination gets hard. URLs aren't SEO optimized, controls are clunky, javascript bugs in the .net framework can't be removed, variables get reset during postback, and there's no simple way for testing for session expired. And you can't add upload progress for a fileupload control. No way to do that in - Quandary
(21) My bottom line...everyone who knows how to code HTML, CSS, and Javascript in it's raw format to build web pages will not play well with WebForms. For those that don't know, or care to know, those technologies then WebForms is a nice SHORTCUT. BUT, if you ever care to learn those core web technologies (or if you ever have to "view source") then you will regret the day you ever chose WebForms. - Leon
(9) Any beer tastes good if you never had a better one before. - Kugel
(3) I must disagree...i been using Web Forms for over 5 years & i been able to add javaScript in any way I want, if you know what you are doing then either you working with MVC or WebFroms everything is possible, matter of fact I know little bit of MVC as well and I find it much easier to inject javascript using WebForms. - highwingers
To add to what @Quandary has mentioned, ViewState will track the values contained in controls, but will not track the controls themselves; it relies on the ASPX to determine which controls to draw. So if you've added any controls dynamically, you're responsible for re-adding them on every single post back. - Yuck
[+226] [2008-10-24 16:59:34] Winston Fassett

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. If you're still not convinced, remember TCP: it's also a stateful abstraction on a stateless protocol. This alone doesn't make it suck; to the contrary, it makes it a lot more useful in the right circumstances.
  • Partial PostBacks are much lighter weight than full PostBacks. Only need the properties of a Gridview and Filter Panel? Wrap them in an Update Panel. Much of the argument against PostBacks disappears when Partial Postbacks enter the conversation.

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.


(3) 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
(3) Yes, answers like these is what makes these very general questions actually useful. Great job, thanks. - Mr Grieves
Agreed, good answer! - willem
(3) 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
"we have to figure out how to manage state in our applications" This is not true. If the page doesn't reload (ajax), state never has to be managed, it just stays.\ - Chad Schouggins
about the disadvantages, it looks obvious to me what you list as disadvantages, are the things you have personal problems dealing with. except for the runat=server, but still, you can have more than one form, you can't have more than one runat=server forms, which is meaningless. You don't need more than one runat=Server forms in a page anyway. You probably don't know why you don't actually need more than one runat=Server forms in a page either. - Uğur Gümüşhan
(2) @PaulReinhardt - There are lots of tricks and techniques you can use to make a single server form work for you, but that doesn't change the fact that a single server form is not always ideal. For instance, when you want to post different data to different pages (rather than the current page). I know there are lots of ways to get around this, but it's still a limitation. Yes, it's correct that you don't NEED more than one form (ie, you can do anything you want with one form if you hack it enough) that doesn't mean having multiple server forms isn't advantageous in various situations. - Mystere Man
The number of times I have had to Literal.Text = "<div class='web-forms-sucks'/>"; in a web forms project... abstraction became a dirty word. - Scotty.NET
You actually can override the container naming strategy, I had to do this in a project when we upgraded from .NET 1.1 to .NET 2.0, the naming strategy broke for us and I had to force old naming conventions on certain controls. It was a PITA though. - Esteban Brenes
[+167] [2008-09-05 15:36:17] Ben Scheirman

I'm going to quote from Joey Beninghove's recent PPT posting [1] 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.


(11) 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. - Larry Foulkrod
the nasty urls part can be managed with url rewriting. But I agree on INamingContainer and ViewState part :) - mathieu
They are fixing INamingContainer and ViewState in 4.0. - Corin Blaikie
(8) If I understand right, the routing library is available for regular too now. So I guess nasty urls are out. - Boris Callens
(3) 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. - andy
(37) 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
(10) @lfoulkrod he is saying that MVC works with the stateless HTTP protocol rather than against it (WebForms). - Dal
(3) You forgot to mention viewstate adding huge bulk to the page, to serialize a lot properties that are largely redundant: - Chris S
The link to Joey's PPT is broken. - DOK
(1) "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." Perfect. This is exactly my problem with WebForms. - Robin Winslow
TCP is also a stateful abstraction on a stateless protocol, and yet it's great - if you apply it in the right circumstances. This by itself is a non-argument. A stateful abstraction CAN be EXACTLY what you need. The accepted answer is much better. - romkyns
[+73] [2008-11-19 00:03:17] Boris Callens

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
(27) 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. - Boris Callens
(5) 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. - Boris Callens
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. - Boris Callens
(4) You nailed it on the last line. - Simon Gibbs
Last comment or post line? - Boris Callens
The freak thing? Or the "it's your choice thing"? - Boris Callens
[+67] [2010-01-13 13:52:59] Chris S

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.

(9) +1 for the "ignorance is bliss" statement. - BradB
(1) viewstate encryption is for xss prevention. learn before you post about it. - Uğur Gümüşhan
(7) @ugurcode what has xss prevention got to do with a large viewstate? - Chris S
@ChrisS an xss javascript code can read data from a page, it means it can also read from a viewstate object, so encrypting is prevents that. viewstate may conttain private or valuable data. - Uğur Gümüşhan
@ugurcode but what has that got to do with the viewstate being huge? The point is, you don't need the entire object graph of your page encrypted and base64'd on each postback, sql/js injects ("xss attacks") or not. Which is what I write in the last paragraph if you read... - Chris S
@ChrisS hashes are short, encrypted text is long by nature. Encryption is not for readability of the source on the client side You can't tell what output is 64 bit encryption by length only. thi s shouldn't bother you. Also, you can disable viewstate encryption - Uğur Gümüşhan
(1) @ugurcode Base64 is not encryption, nor does it offer any kind of protection against XSS. Try to decode the block above, you'll see lots of clear text, some of it usable to find attack vectors. - jv42
(1) @ugurcode it's asymetrically encrypted then base 64 encoded. The point of my post is unless you know about the overhead, it's needless crap added to the page weight. It's not there just to protect against SQL/HTML/Script injects (although it helps), those are protected against elsewhere in the ASP.NET framework - Chris S
@ChrisS functionality comes with overhead most of the time. You can disable viewstate. using the properties panel for each component. Also, there's no limit of optimization. Don't get stuck on that. It's an endless discussion. - Uğur Gümüşhan
@ugurcode Why are you telling me :P That's my point in the final paragraph. - Chris S
+1 This is indeed the most annoying thing in web forms - Venemo
[+63] [2008-09-05 15:30:30] Ryan Lanciaux

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.

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. - Larry Foulkrod
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? - andy
(42) "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
(4) 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
(2) @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.
(4) 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
(2) @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. - brumScouse
[+46] [2008-09-05 15:32:27] Eric Z Beard

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.

(4) "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
(36) 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! - Pure.Krome
(15) 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
(10) "the way the web is supposed to work" according to whom? Use whatever is best for your application and your team. - Ricardo
(1) So... Web forms model sucks because you don't like "tag soup" that you get with MVC? Damn, this is getting confusing. ^^ - Arnis L.
(4) If you're getting tag soup in MVC, you're doing it wrong. - Adam Lassek
(1) Reminds me quote: "Resharper is bad for real life projects, because .aspx gets huge and Resharper just crashes". :D - Arnis L.
(2) +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. - James
(8) 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. - Sergey
(1) @sergey I've found MVC much easier and more efficient than Webforms. I'm actually rewriting an app in it now, and it's much easier, cleaner and runs faster than the old one. The sad truth is anything I gained out of webforms, I can get in MVC more cleanly with JQuery and JQuery UI. - Telos
(1) @sergey Sure, MVC can be a nightmare if you don't know html, css and javascript in its natural habitat. Webforms on the other hand can be a nightmare when you want to create a maintainable, fast and responsive (aka quality) application. In my experience, if it had to be fast, its a nightmare to maintain. If I want the code clean, I'd had to sacrifice some of the speed. I don't necessarily like MVC either. If I'm creating a web application, I'd rather code it in pure html/javascript, driven by WCF services. - Mel
When working with javascript in WebForms, it's a nightmare trying to figure out how .NET chooses to parse the <asp:> controls into html code. In javascript you need to know what is in the html if you need to access the html elements. In modern web applications, the combination of html, javascript and css is alpha and omega. WebForms makes this difficult to achieve in a good way. It ends up with hacks. - awe
[+45] [2008-09-06 16:03:15] Dave Ward

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.

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
Agree with you completely. It turns out, I've been writing my ASP.NET systems using the MVVM design approach, long before I had heard of "MVVM" as a pattern unto itself. I always thought I was simply writing good code, with good encapsulation of different concerns. - mikemanne
[+35] [2008-09-05 15:32:15] harpo

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. [1]

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.


[+29] [2008-09-05 15:36:47] Kevin Pang

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.

[+25] [2010-03-15 06:20:10] Neil T.

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.

Thank you very much for your insight! - Daniel Magliola
(3) 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. - Peter
(3) I can't imagine even a half-decent WebForms dev not knowing (X)HTML, CSS, JavaScript, jQuery and AJAX. It's not like WebForms is WPF, you know. At the end of the day, even us WebForms developers have to write HTML..... - Mark Brackett
[+21] [2008-09-05 15:55:34] Daniel Magliola

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.

To truly understand the benefits of MVC, you need to get first hand experience with a real world project. I thought I saw the benefits with MVC back in the days when I was working with WebForms, and I concluded with it looks good for certain types of applications, but not the type of applications I work with. Then I started on a new project that was going to be MVC all the way, and I realized I was wrong. MVC is right for all kinds of applications. - awe
[+16] [2010-04-07 21:02:10] Jeff

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.

(2) +1 for bringing up the page-controller point. - Charlie Flowers
[+15] [2008-09-05 15:35:56] xanadont

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 [1] but I've only used it on one project because it's pretty nasty (it's also no longer supported).


[+13] [2008-09-05 15:37:54] chris

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.

(1) "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. - Torbjørn
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. - dtc
(3) 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
(3) @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
[+13] [2008-09-06 19:53:05] Dave Ward

@ Radu [1]: 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 [2] 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.

[1] #47760

+1 great 'quickly thrown together site' - The_AlienCoder
+1 Dave, I chose to go the same route (web services) or BL encapsulation, so really, it IS up to the developer. - sarsnake
So you're saying that WebForms is good for rapid-prototyping very simple sites. I don't disagree. WebForms is, however, very bad for anything other than toys. - Yuck
@Yuck: [citation needed] - Dave Ward
[+11] [2008-12-02 00:08:11] graffic

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 it, or use it for things you don't care about. Of course you need itto detect changes and execute events. But that's all, you go faster without it.

Anyway, 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. If you need some specific functionality that smells like these controllers people talk about then 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 and ask yourself: What is the useful stuff? Is there any original control left?

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. - graffic
[+9] [2008-09-05 15:43:59] Mark Cidade

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.

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:) - sarsnake
[+9] [2008-09-06 15:41:14] Orion Edwards

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

[+9] [2008-09-16 18:49:45] BlackTigerX

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!

[+7] [2008-10-21 20:27:29] ulu

Re: testability. You can unit test webforms, as well as MVC views, with Ivonna [1]. 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.


[+6] [2008-09-05 20:42:02] Daniel Magliola


Take a look at this:

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

I'd been looking for this article for ages. I read it just after it came out but lost the link! - Slace
[+6] [2009-07-04 04:03:43] Muffintop

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.

(1) 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? ;) - Matt
[+6] [2010-02-11 05:11:07] Charlie Flowers

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.

(1) 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
You do know that you can write a method to return HTML in WebForms, too - right? And that you can create your own server controls, not just use those black-boxes you're given? And use a javascript grid? And, that at the point you "slice up functionality into reusable classes and methods...using C# code to build up a set of custom abstractions for generating HTML", that you'll basically end up with a server control? - Mark Brackett
@Mark, yes, I do know that you can create server controls with WebForms. What I am saying is the WebForm "control" model hurts us as much as it helps us (or more). So, sure, you could do WebForms, but just never use anything but custom server controls you built yourself. But that would be dumb, because ASPMVC is much more compatible with that approach. Also, server controls in WebForms do not offer the specific features for "slicing up functionality into reusable classes and methods" that MVC offers, such as Html helper extension methods, etc. - Charlie Flowers
(2) +1 i wish i could +10 this. @ My new job we have a huge code base. The hardest thing is figuriing what the hell is going on in a page. Code is strewn across multple controls since they are event driven, good luck trying to trace. I hate all the stupid magic. I just want to be able to trace the code, not think about the lifecycle of every freaking control. I hate with a passion. I'd rather use CGI perl at this point. - Byron Whitlock
[+5] [2008-09-23 20:44:33] Fredrik Kalseth

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.

[+5] [2010-03-15 05:32:30] Matt Vaughn

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.

[+4] [2008-09-07 18:22:56] Radu094

@ Dave [1]: 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).

[1] #47773

[+4] [2009-12-14 16:17:26] Monoman

Having used Monorail [1] 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
@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. - Monoman
[+4] [2010-01-22 11:50:05] Steffen

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?" :)

[+4] [2010-01-28 23:23:37] IrishChieftain

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 [1] (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] [2008-09-05 15:38:07] rob

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.

[+3] [2008-09-05 16:08:14] chris


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.

(1) I see more horrible php sites than anything else. - Daniel Coffman
I see dead people - Gordon Carpenter-Thompson
[+3] [2008-09-06 19:28:34] Radu094
 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 - Radu094
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
[+3] [2009-06-05 19:16:05] Matthias Hryniszak

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.

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? &lt;input type="text" name="Email" value="&lt;%=Request.Form("Email"%&gt; /%gt; - Daniel Magliola
[+2] [2008-09-05 16:11:45] Daniel Magliola


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

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
@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. - joedotnot
[+2] [2008-09-06 09:53:40] Andrei Rinea

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


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. - Armstrongest
[+2] [2008-12-01 04:46:42] Travis

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. - Travis
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. - jamisonLikeCode
[+2] [2008-12-02 00:24:49] orip

Like Ayende says [1], 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? - orip
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
[+1] [2008-12-01 04:15:49] IrishChieftain

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 :) - graffic
[0] [2008-12-12 15:18:58] justin

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