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
  • As of ASP.NET 4.0, it is possible to change the naming strategy ^[1] for IDs of the 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.

Clarifications

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

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

ctl00_ctl00_ctl00_bhcr_ctl01_ctl00_ctl00_ctl02_TitleBarSearchDropDownList

• Meaningless Urls

http://www.nastyurls.com/tabid/283/Default.aspx

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.

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

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

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="dDwyMDY4MTQ0OTQ4O3Q8O2w8aTwwPjtpPDE+Oz47bDx0PDtsPGk8MT47aTwyPjs
+O2w8dDw7bDxpPDA+Oz47bDx0PEA8R290RG90TmV0OiBUaGUgTWljcm9zb2Z0IC5
ORVQgRnJhbWV3b3JrIENvbW11bml0eTtcZTtcZTs+Ozs+Oz4+O3Q8QDxcZTtcZTs+Oz
s+Oz4+O3Q8O2w8aTwwPjtpPDQ+O2k8Nj47PjtsPHQ8O2w8aTwxPjtpPDM+O2k8Nz4
7PjtsPHQ8O2w8aTwwPjs+O2w8dDw7bDxpPDM+Oz47bDx0PDtsPGk8MT47aTwzPjtpP
DU+O2k8Nj47PjtsPHQ8cDxwPGw8Rm9udF9TaXplO18hU0I7PjtsPFN5c3RlbS5XZWIuV
UkuV2ViQ29udHJvbHMuRm9udFVuaXQsIFN5c3RlbS5XZWIsIFZlcnNpb249MS4wLjUw
MDAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iMDNmNWY3Z
jExZDUwYTNhPFhYLVNtYWxsPjtpPDEwMjQ+Oz4+Oz47Oz47dDxwPHA8bDxXaWR0
aDtfIVNCOz47bDwxPDIwMHB4PjtpPDI1Nj47Pj47cDxsPG9uS2V5UHJlc3M7PjtsPGphd
mFzY3JpcHQ6U3VibWl0U2VhcmNoX2N0bDFfU2VhcmNoQm94MSgpXDs7Pj4+Ozs+O
3Q8cDxsPG9uQ2xpY2s7PjtsPGdvU2VhcmNoX2N0bDFfU2VhcmNoQm94MSgpXDs7Pj
47Oz47dDxAPF9jdGwxX1NlYXJjaEJveDE7X2N0bDFfU2VhcmNoQm94MV9UZXh0Qm
94UXVlcnk7L1NlYXJjaC9TZWFyY2guYXNweDtfY3RsMV9TZWFyY2hCb3gxO19jdGw
xX1NlYXJjaEJveDE7Pjs7Pjs+Pjs+Pjs+Pjt0PDtsPGk8MD47PjtsPHQ8O2w8aTwwPjs+O2
w8dDw7bDxpPDE+Oz47bDx0PHA8bDxfIUl0ZW1Db3VudDs+O2w8aTw1Pjs+PjtsPGk8
MD47aTwxPjtpPDI+O2k8Mz47aTw0Pjs+O2w8dDw7bDxpPDE+O2k8Mz47aTw1Pjs+O
2w8dDxwPDtwPGw8b25DbGljazs+O2w8ZXhwYW5kaXQoJ19jdGwxX1JpZ2h0TmF2aW
dhdGlvbk1lbnVfTWVudVNlY3Rpb25zX19jdGwwX1NlY3Rpb25QYW5lbCcpOz4+PjtsP
Gk8MD47PjtsPHQ8cDxwPGw8SW1hZ2VVcmw7PjtsPC9pbWFnZXMvbGVmdG5hdl9hc
nJvd3VfbmV3LmdpZjs+Pjs+Ozs+Oz4+O3Q8cDxsPG9uQ2xpY2s7PjtsPGV4cGFuZGl0K
CdfY3RsMV9SaWdodE5hdmlnYXRpb25NZW51X01lbnVTZWN0aW9uc19fY3RsMF9TZ
WN0aW9uUGFuZWwnKTs+Pjs7Pjt0PHA8O3A8bDxzdHlsZTs+O2w8ZGlzcGxheTpibG9
ja1w7Oz4+Pjs7Pjs+Pjt0PDtsPGk8MT47aTwzPjtpPDU+Oz47bDx0PHA8O3A8bDxvbkN
saWNrOz47bDxleHBhbmRpdCgnX2N0bDFfUmlnaHROYXZpZ2F0aW9uTWVudV9NZW
51U2VjdGlvbnNfX2N0bDFfU2VjdGlvblBhbmVsJyk7Pj4+O2w8aTwwPjs+O2w8dDxwPH
A8bDxJbWFnZVVybDs+O2w8L2ltYWdlcy9sZWZ0bmF2X2Fycm93ZF9uZXcuZ2lmOz4
+Oz47Oz47Pj47dDxwPGw8b25DbGljazs+O2w8ZXhwYW5kaXQoJ19jdGwxX1JpZ2h0T
mF2aWdhdGlvbk1lbnVfTWVudVNlY3Rpb25zX19jdGwxX1NlY3Rpb25QYW5lbCcpOz4
+Ozs+O3Q8cDw7cDxsPHN0eWxlOz47bDxkaXNwbGF5Om5vbmVcOzs+Pj47Oz47Pj47
dDw7bDxpPDE+O2k8Mz47aTw1Pjs+O2w8dDxwPDtwPGw8b25DbGljazs+O2w8ZXhwY
W5kaXQoJ19jdGwxX1JpZ2h0TmF2aWdhdGlvbk1lbnVfTWVudVNlY3Rpb25zX19jdGwy
X1NlY3Rpb25QYW5lbCcpOz4+PjtsPGk8MD47PjtsPHQ8cDxwPGw8SW1hZ2VVcmw7
PjtsPC9pbWFnZXMvbGVmdG5hdl9hcnJvd2RfbmV3LmdpZjs+Pjs+Ozs+Oz4+O3Q8cDxs
PG9uQ2xpY2s7PjtsPGV4cGFuZGl0KCdfY3RsMV9SaWdodE5hdmlnYXRpb25NZW51X
01lbnVTZWN0aW9uc19fY3RsMl9TZWN0aW9uUGFuZWwnKTs+Pjs7Pjt0PHA8O3A8b
DxzdHlsZTs+O2w8ZGlzcGxheTpub25lXDs7Pj4+Ozs+Oz4+O3Q8O2w8aTwxPjtpPDM+O
2k8NT47PjtsPHQ8cDw7cDxsPG9uQ2xpY2s7PjtsPGV4cGFuZGl0KCdfY3RsMV9SaWd
odE5hdmlnYXRpb25NZW51X01lbnVTZWN0aW9uc19fY3RsM19TZWN0aW9uUGFuZW
wnKTs+Pj47bDxpPDA+Oz47bDx0PHA8cDxsPEltYWdlVXJsOz47bDwvaW1hZ2VzL2xlZ
nRuYXZfYXJyb3dkX25ldy5naWY7Pj47Pjs7Pjs+Pjt0PHA8bDxvbkNsaWNrOz47bDxleH
BhbmRpdCgnX2N0bDFfUmlnaHROYXZpZ2F0aW9uTWVudV9NZW51U2VjdGlvbnNfX2
N0bDNfU2VjdGlvblBhbmVsJyk7Pj47Oz47dDxwPDtwPGw8c3R5bGU7PjtsPGRpc3BsYX
k6bm9uZVw7Oz4+Pjs7Pjs+Pjt0PDtsPGk8MT47aTwzPjtpPDU+Oz47bDx0PHA8O3A8bD
xvbkNsaWNrOz47bDxleHBhbmRpdCgnX2N0bDFfUmlnaHROYXZpZ2F0aW9uTWVudV
9NZW51U2VjdGlvbnNfX2N0bDRfU2VjdGlvblBhbmVsJyk7Pj4+O2w8aTwwPjs+O2w8d
DxwPHA8bDxJbWFnZVVybDs+O2w8L2ltYWdlcy9sZWZ0bmF2X2Fycm93ZF9uZXcuZ2l
mOz4+Oz47Oz47Pj47dDxwPGw8b25DbGljazs+O2w8ZXhwYW5kaXQoJ19jdGwxX1JpZ
2h0TmF2aWdhdGlvbk1lbnVfTWVudVNlY3Rpb25zX19jdGw0X1NlY3Rpb25QYW5lbCc
pOz4+Ozs+O3Q8cDw7cDxsPHN0eWxlOz47bDxkaXNwbGF5Om5vbmVcOzs+Pj47Oz4
7Pj47Pj47Pj47Pj47Pj47dDxwPHA8bDxUZXh0Oz47bDxHb3REb3ROZXQ6IFRoZSBNaW
Nyb3NvZnQgLk5FVCBGcmFtZXdvcmsgQ29tbXVuaXR5Oz4+Oz47Oz47Pj47dDw7bDx
pPDc+O2k8MTE+Oz47bDx0PDtsPGk8MD47PjtsPHQ8cDxsPF8hSXRlbUNvdW50Oz47b
DxpPDU+Oz4+O2w8aTwxPjtpPDI+O2k8Mz47aTw0PjtpPDU+Oz47bDx0PDtsPGk8MD
47aTwxPjtpPDM+Oz47bDx0PEA8Ni8yNDs+Ozs+O3Q8cDxwPGw8VGV4dDtOYXZpZ2F
0ZVVybDs+O2w8RjhDb250cm9scztodHRwOi8vRmlndXJlOFNvZnR3YXJlLmNvbS9GOE
NvbnRyb2xzLmFzcDs+Pjs+Ozs+O3Q8cDxwPGw8TmF2aWdhdGVVcmw7PjtsPGh0dHA
6Ly9GaWd1cmU4U29mdHdhcmUuY29tL0Y4Q29udHJvbHMuYXNwOz4+Oz47Oz47Pj47
dDw7bDxpPDA+O2k8MT47aTwzPjs+O2w8dDxAPDYvMjM7Pjs7Pjt0PHA8cDxsPFRle
HQ7TmF2aWdhdGVVcmw7PjtsPFNuLiBBU1AuTkVUL0MjIFVJIERldmVsb3BlcjtodHRw
Oi8vd3d3LnlvaGl0LmNvbTs+Pjs+Ozs+O3Q8cDxwPGw8TmF2aWdhdGVVcmw7PjtsPGh
0dHA6Ly93d3cueW9oaXQuY29tOz4+Oz47Oz47Pj47dDw7bDxpPDA+O2k8MT47aTwz
Pjs+O2w8dDxAPDYvMjM7Pjs7Pjt0PHA8cDxsPFRleHQ7TmF2aWdhdGVVcmw7PjtsPE
tpbmV0aWNhUlQgLk5FVCBDb21wb25lbnRzIGFuZCBTb2Z0d2FyZTtodHRwOi8vd3d
3LmtpbmV0aWNhcnQuY28udWs7Pj47Pjs7Pjt0PHA8cDxsPE5hdmlnYXRlVXJsOz47bD
xodHRwOi8vd3d3LmtpbmV0aWNhcnQuY28udWs7Pj47Pjs7Pjs+Pjt0PDtsPGk8MD47aT
wxPjtpPDM+Oz47bDx0PEA8Ni8yMjs+Ozs+O3Q8cDxwPGw8VGV4dDtOYXZpZ2F0ZV
VybDs+O2w8Rm9vbGluZyBWUyB0byBkZXZlbG9wIEFTUC5ORVQgYXBwbGljYXRp
b25zIGluIGh0dHA6Ly9sb2NhbGhvc3Q7aHR0cDovL3d3dy5ob3d0b2RvdGhpbmdzLmNv
bS9zaG93YXJ0aWNsZS5hc3A/YXJ0aWNsZT03Mjg7Pj47Pjs7Pjt0PHA8cDxsPE5hdmln
YXRlVXJsOz47bDxodHRwOi8vd3d3Lmhvd3RvZG90aGluZ3MuY29tL3Nob3dhcnRpY2x
lLmFzcD9hcnRpY2xlPTcyODs+Pjs+Ozs+Oz4+O3Q8O2w8aTwwPjtpPDE+O2k8Mz47P
jtsPHQ8QDw2LzIyOz47Oz47dDxwPHA8bDxUZXh0O05hdmlnYXRlVXJsOz47bDxBU1
AuTkVUIHVwbG9hZGVkIGltYWdlcyBhcyB0aHVtYm5haWxzO2h0dHA6Ly93d3cuaG93
dG9kb3RoaW5ncy5jb20vc2hvd2FydGljbGUuYXNwP2FydGljbGU9NjgyOz4+Oz47Oz4
7dDxwPHA8bDxOYXZpZ2F0ZVVybDs+O2w8aHR0cDovL3d3dy5ob3d0b2RvdGhpbm
dzLmNvbS9zaG93YXJ0aWNsZS5hc3A/YXJ0aWNsZT02ODI7Pj47Pjs7Pjs+Pjs+Pjs+Pjt
0PDtsPGk8MD47PjtsPHQ8cDxsPF8hSXRlbUNvdW50Oz47bDxpPDU+Oz4+O2w8aTw
xPjtpPDI+O2k8Mz47aTw0PjtpPDU+Oz47bDx0PDtsPGk8MD47aTwxPjtpPDM+Oz47bD
x0PEA8Ni8yMzs+Ozs+O3Q8cDxwPGw8VGV4dDtOYXZpZ2F0ZVVybDs+O2w8Q3V
zdG9tIERhdGFzZXQgRGF0YSBFeHRlbnNpb24gZm9yIE1pY3Jvc29mdCBSZXBvcnRpb
mcgU2VydmljZXMgKFZCKTtodHRwOi8vd3d3LmdvdGRvdG5ldC5jb20vQ29tbXVuaXR
5L1VzZXJTYW1wbGVzL0RldGFpbHMuYXNweD9TYW1wbGVHdWlkPTA5Zjc5NW
FjLWJhMGMtNDNjZS04YTc2LTQ0NTlkZTljMThkYTs+Pjs+Ozs+O3Q8cDxwPGw8T
mF2aWdhdGVVcmw7VmlzaWJsZTs+O2w8aHR0cDovL3d3dy5nb3Rkb3RuZXQuY29tL
0NvbW11bml0eS9Vc2VyU2FtcGxlcy9EZXRhaWxzLmFzcHg/U2FtcGxlR3VpZD0wOWY
3OTVhYy1iYTBjLTQzY2UtOGE3Ni00NDU5ZGU5YzE4ZGE7bzxmPjs+Pjs+Ozs+Oz4+
O3Q8O2w8aTwwPjtpPDE+O2k8Mz47PjtsPHQ8QDw2LzIzOz47Oz47dDxwPHA8bDxU
ZXh0O05hdmlnYXRlVXJsOz47bDwgQyMgRGVtb25zdHJhdGlvbiBQcm9qZWN0IGZvciB
1c2Ugd2l0aCBLaW5ldGljYVJUIE9QQyBDbGllbnQgLk5FVCBDb21wb25lbnQ7aHR0cD
ovL3d3dy5nb3Rkb3RuZXQuY29tL0NvbW11bml0eS9Vc2VyU2FtcGxlcy9EZXRhaWxzL
mFzcHg/U2FtcGxlR3VpZD02ZDBhOTc0ZS03NzBmLTQ2OGQtYWE2My01NjNmYWR
hODJmZjI7Pj47Pjs7Pjt0PHA8cDxsPE5hdmlnYXRlVXJsO1Zpc2libGU7PjtsPGh0dHA6Ly
93d3cuZ290ZG90bmV0LmNvbS9Db21tdW5pdHkvVXNlclNhbXBsZXMvRGV0YWlscy
5hc3B4P1NhbXBsZUd1aWQ9NmQwYTk3NGUtNzcwZi00NjhkLWFhNjMtNTYzZmFk
YTgyZmYyO288Zj47Pj47Pjs7Pjs+Pjt0PDtsPGk8MD47aTwxPjtpPDM+Oz47bDx0PEA8
Ni8yMjs+Ozs+O3Q8cDxwPGw8VGV4dDtOYXZpZ2F0ZVVybDs+O2w8ZGF0YWJhY
2t1cCAtIEJhY2t1cCBhbmQgcmVzdG9yZSBNcyBTcWwgU2VydmVyIGRhdGFiYXNlczt
odHRwOi8vd3d3LmdvdGRvdG5ldC5jb20vQ29tbXVuaXR5L1VzZXJTYW1wbGVzL0Rl
dGFpbHMuYXNweD9TYW1wbGVHdWlkPTRlNmU4YzM4LTUwYjUtNDY1ZC05OD
hlLTU3ZWM1MjYxYmYwYzs+Pjs+Ozs+O3Q8cDxwPGw8TmF2aWdhdGVVcmw7Vml
zaWJsZTs+O2w8aHR0cDovL3d3dy5nb3Rkb3RuZXQuY29tL0NvbW11bml0eS9Vc2VyU
2FtcGxlcy9EZXRhaWxzLmFzcHg/U2FtcGxlR3VpZD00ZTZlOGMzOC01MGI1LTQ2N
WQtOTg4ZS01N2VjNTI2MWJmMGM7bzxmPjs+Pjs+Ozs+Oz4+O3Q8O2w8aTwwPjt
pPDE+O2k8Mz47PjtsPHQ8QDw2LzIxOz47Oz47dDxwPHA8bDxUZXh0O05hdmlnYX
RlVXJsOz47bDxDdXN0b20gQ29udHJvbHMgOiBJbmhlcml0ZWQgVGV4dENvbnRyb2
w7aHR0cDovL3d3dy5nb3Rkb3RuZXQuY29tL0NvbW11bml0eS9Vc2VyU2FtcGxlcy9E
ZXRhaWxzLmFzcHg/U2FtcGxlR3VpZD05OGZhZTQ1ZS03M2M1LTQ3MWYtYjExO
C03M2MxZjI1ZTg1ODY7Pj47Pjs7Pjt0PHA8cDxsPE5hdmlnYXRlVXJsO1Zpc2libGU7
PjtsPGh0dHA6Ly93d3cuZ290ZG90bmV0LmNvbS9Db21tdW5pdHkvVXNlclNhbXBsZ
XMvRGV0YWlscy5hc3B4P1NhbXBsZUd1aWQ9OThmYWU0NWUtNzNjNS00NzFm
LWIxMTgtNzNjMWYyNWU4NTg2O288Zj47Pj47Pjs7Pjs+Pjt0PDtsPGk8MD47aTwx
PjtpPDM+Oz47bDx0PEA8Ni8yMTs+Ozs+O3Q8cDxwPGw8VGV4dDtOYXZpZ2F0Z
VVybDs+O2w8QnVpbGQgUnVsZXMgRVg7aHR0cDovL3d3dy5nb3Rkb3RuZXQuY29
tL0NvbW11bml0eS9Vc2VyU2FtcGxlcy9EZXRhaWxzLmFzcHg/U2FtcGxlR3VpZD1hM
zMyNmViMy1hNDY4LTRmNjctOTFhOC1mODQ0NjlmYzQ5ZTI7Pj47Pjs7Pjt0PHA8c
DxsPE5hdmlnYXRlVXJsO1Zpc2libGU7PjtsPGh0dHA6Ly93d3cuZ290ZG90bmV0LmNv
bS9Db21tdW5pdHkvVXNlclNhbXBsZXMvRGV0YWlscy5hc3B4P1NhbXBsZUd1aWQ
9YTMzMjZlYjMtYTQ2OC00ZjY3LTkxYTgtZjg0NDY5ZmM0OWUyO288Zj47Pj47Pjs
7Pjs+Pjs+Pjs+Pjs+Pjt0PDtsPGk8ND47aTwxNj47PjtsPHQ8cDxwPGw8VGV4dDs+O2w
8wqkgQ29weXJpZ2h0IDIwMDQgTWljcm9zb2Z0IENvcnBvcmF0aW9uLiBBbGwgUmlna
HRzIFJlc2VydmVkLjs+Pjs+Ozs+O3Q8O2w8aTwwPjs+O2w8dDw7bDxpPDA+Oz47bD
x0PDtsPGk8MT47PjtsPHQ8cDxsPF8hSXRlbUNvdW50Oz47bDxpPDU+Oz4+O2w8aT
wwPjtpPDE+O2k8Mj47aTwzPjtpPDQ+Oz47bDx0PDtsPGk8MT47PjtsPHQ8cDxwPGw
8TmF2aWdhdGVVcmw7SW1hZ2VVcmw7VG9vbFRpcDs+O2w8aHR0cDovL3d3dy5hb
mdyeWNvZGVyLmNvbTsvdWkvY29tcG9uZW50cy9jb250cm9scy9Db2RlV2lzZS9JbWF
nZS5hc3B4P21lbWJlcklkPTEwO2FuZ3J5Q29kZXI7Pj47Pjs7Pjs+Pjt0PDtsPGk8MT47Pj
tsPHQ8cDxwPGw8TmF2aWdhdGVVcmw7SW1hZ2VVcmw7VG9vbFRpcDs+O2w8aH
R0cDovL3d3dy5hc3BhZHZpY2UuY29tOy91aS9jb21wb25lbnRzL2NvbnRyb2xzL0NvZG
VXaXNlL0ltYWdlLmFzcHg/bWVtYmVySWQ9MTI4O0FTUCBBZHZpY2U7Pj47Pjs7P
js+Pjt0PDtsPGk8MT47PjtsPHQ8cDxwPGw8TmF2aWdhdGVVcmw7SW1hZ2VVcmw7
VG9vbFRpcDs+O2w8aHR0cDovL3d3dy5jb2RlcHJvamVjdC5jb207L3VpL2NvbXBvbm
VudHMvY29udHJvbHMvQ29kZVdpc2UvSW1hZ2UuYXNweD9tZW1iZXJJZD0zO0Nv
ZGUgUHJvamVjdDs+Pjs+Ozs+Oz4+O3Q8O2w8aTwxPjs+O2w8dDxwPHA8bDxOYXZ
pZ2F0ZVVybDtJbWFnZVVybDtUb29sVGlwOz47bDxodHRwOi8vd3d3LmRldnguY29tO
y91aS9jb21wb25lbnRzL2NvbnRyb2xzL0NvZGVXaXNlL0ltYWdlLmFzcHg/bWVtYmVy
SWQ9MTk7RGV2WDs+Pjs+Ozs+Oz4+O3Q8O2w8aTwxPjs+O2w8dDxwPHA8bDxO
YXZpZ2F0ZVVybDtJbWFnZVVybDtUb29sVGlwOz47bDxodHRwOi8vd3d3LmRvdG5ld
Gp1bmtpZXMuY29tOy91aS9jb21wb25lbnRzL2NvbnRyb2xzL0NvZGVXaXNlL0ltYWdlL
mFzcHg/bWVtYmVySWQ9MTM7RG90TmV0SnVua2llczs+Pjs+Ozs+Oz4+Oz4+Oz4+O
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.

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.

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.

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.

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.

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.

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.

Thanks for your responses.

@Ben,

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.

@Kevin,

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.

@Chris,

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.

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 asp.net 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 asp.net. 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 asp.net doesn't encourage good practices.
5. Page-Controller - By default asp.net 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 asp.net other than using browser driven testing methods such as watin.
7. Web Controls - In an effort to make asp.net 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 asp.net 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 asp.net web forms has it's place in the intranet and internal reporting applications but that is about it.

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

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.

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

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.

Viewstate

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

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.

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

I always question the same thing, I have managed to write large and quite complex web applications using asp.net, 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!

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.

Rob,

Take a look at this:
http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

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

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.

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.

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.

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.

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

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.

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

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

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.

@Daniel:

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 asp.net sites than anything else.

 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.

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.

@Chris,

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

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.

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.

Like Ayende says ^[1], it's a leaky stateful abstraction over stateless web.

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 ;-) www.codersbarn.com

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.