因为webform确实，企图通过在html标签中的runat=”server”,在iis接受请求后，通过aspx页面引擎解析，想在服务器端，将所有标签构建成对象，各种Label对象，Button对象，然后还有一大堆属性Css,Style等等，包含一大堆本该服务器不应该关心的东西。
我认为只有对html页面进行数据填充的地方，才需要服务器端关心，其他地方都不是服务器端的责任，软件开发时，页面表现，前端工程师都写好了，不该是服务器关心的。
然后Webform为了干预这引擎生成的对象，以及深入的说干预最后生成的html页面（字符串）加了很多事件！这个就是页面生命周期，这个本来没什么问题。但是每次事件回传都要把这些事件执行一遍就有点问题了。
每次事件回传，都对页面重新生成，将客户端提交的form表单元素解析，然后还原html字符串中各个地方的值，这是是楼主说的框架设计的问题吧！
服务器控件的存在，页面生命周期的过长，这些与ajax确实是冲突的，如ViewState的完整性验证，不允许客户端修改服务器控件生成的内容，这个只能在服务器端对内容进行更改，这样就可ajax冲突了。比如：
刚开始用服务器控件做了个多级联动，然后如果在前端用ajax修改了控件生成的内容，再次提交到后台就会验证出错，不得不关闭安全验证。
ajax请求也不得不再写一个ashx页面，不能请求自身这个文件，不然的话，又一次生命周期，又一次状态还原。整个框架给人的感觉是想要精细控制的话，自己又必须写很多代码，或者以前的框架做了过多的事情，不够清爽！
—————————————————————————————————————–
在很多很多年前以前，我们绝大部分“项目”的 webform 页面，首先要设置 EnableViewState 为 false，其次要删除默认的 <form runat=”server” />。这样 webform 就是一个傻瓜化的“页面”，已经去掉了传统的 webform 绝大部分机制。更何况也可以使用 ashx 作为页面宿主。
所以说 asp.net webform 的“落后”，不等于说那个没有什么组件技术的 asp.net mvc 就有用了。实际上 mvc 这个“梗”应该越过去（现在还是某些人用来忽悠老板的手段），直接用轻量级的 asp.net 核心来支持现代的前端开发。
很多很多年（其实也不是很长，大约在2001年左右吧），asp.net 出来时，浏览器的功能还不是很强大，客户端达不到现在那么好的效果，也做不出很强大的功能，所以很多功能在服务端做也很正常的。总之我的映象中，在02年之前所见过的BS系统中，浏览器没有出现过日历、树这种现在很流行的控件。在05年的时候，javascript都无法进行调试的，我所知道的一款 javascript 调试工具只能在 firefox 上运行，并且是以插件形式存在，并且并且在 firefox 上调试好的 javascript 不一定在IE上是兼容的。所以当时流行的是瘦客户端。
现在有了CSS3、HTML5、jQuery……客户端能够干很多事了，前后端逻辑分享的思想成熟了，经验丰富了，所以富客户端又流行起来了。
当年我们很多同事都认为做WEB开发没前途，因为浏览器上的用户体验很难做到象CS那么好，当然事实证明当年我们错了。
web form 其实是一个超前的设计。
每个厂商都希望服务器端和客户端采用同样的语言编程，这是为了商业利益考虑，如果能实现，对程序员来说，也是一个福音。
sun 在服务器端有 java，在客户端就做了 javascript，但据说 javascript，的设计者其实不太喜欢 java，所以它们只有名字是相似的。
微软在 asp 的时代，有一种叫 vbscript 的客户端脚本，如果页面只在 ie 上跑，其实有很好的编程体验，因为 asp 的服务器端代码，就是用 vb 写的。可惜的是，微软在浏览器并没有在桌面市场那种垄断的号召力，vbscript 并没有流行起来。
现在使用 javascript 的群体，也可以使用 node.js 在服务器端编程。
进入了 .net 时代，微软并没有放弃统一客户端和服务器端编程方式的努力，web form 就是一种尝试。它使得程序员可以完全忽略客户端，只使用 .net 家族的语言就可以进行 web 编程，客户端的 javascript，完全是在服务器端生成的。
web form 还有一个目标，就是统一 web form 和 win form 的编程体验，你可以看到 web form 的事件模型和 win form 非常的相似，也和 win form 编程一样，有可视化的界面编辑器。
这种统一程序员在各平台的编程体验，降低学习成本的想法本身是很好的。我个人认为在立意上是比 struct 更高明的设计。那么，是什么造成了 web form 的接受度强差人意呢？
web form 的阻力，只从技术的方面考虑，我认为有两个原因：
一、体验糟糕的 post back。web form 编程模型要求整个页面回发，这个回发在局域网的带宽内传输是没有问题的，但是公网会有点困难。中国的家庭宽带，上行要比下行的带宽小得多。运营商的广告上面说的，都是下行的带宽，直到现在，很多家庭宽带的上行都只有 512kb，转换成存储的字节单位，只有 64KB/s。csdn 的一个帖子页面，一般都在 20KB，如果整个页面回发，即使网速跑满，时间都占了约 300ms，这对用户体验是有明显的影响的，何况带宽一般都是跑不满的。也就是说，web form 这种先进的编程模型，是依赖于高速的带宽，包括高速的上行带宽的。这也是现在很多企业的内部系统，喜欢使用 .net 的原因之一。
二、与前端编程思维的抵触。web form 的编程模型使用的是 .net 家族的语言，如果完全按照这种思维，是完全不需要前端 javascript 的开发的。但现实的情况是，有很多优秀的控件，是完全基于 javascript 去开发的，如果你要使用这些控件，那么需要转变你的编程思维。虽然这也不难，但是很多程序员要完成这种思维转变，还是需要一点时间的，论坛上很多人问客户端的 html 怎么写，就是这个原因。毕竟习惯了使用 C# 或 vb 去控制服务器端控件，或者直接使用可视化界面编辑器去控制样式，突然间变成要用 javascript，需要一个适应的过程。
现在 web form 之所以大量被使用在企业内部系统，也是它的特点所决定的。
除了带宽足够大，企业产品对界面的要求不高，很多做企业产品的团队，根本就没有前端工程师，也不存在什么分工合作不顺畅的问题了。
web form 的开发速度快，是得到大多数人的认同的。比如做几个下拉菜单的联动，用 web form 的事件模型会很简单，当然了，每次下拉选择完成之后，整个页面都会刷新一下，这对企业用户来说不算什么。毕竟，一个企业内部系统，目的是整个企业的信息管理，而不像社交平台那样，只为用户爽。
基于 web form 做公网产品的种种不足，mvc 是必然要做的，也就是说，mvc 更适合做面向公网的产品。
很多程序员会说，在 mvc 出来之前，就已经不使用 web form 的回发了，这样的程序员，其实已经不需要 mvc 了，因为他们已经在更基本的层次去解决了问题。
现在 .net 的 web 编程，选择很多：.aspx .ashx .cshtml，.aspx 也可以选择不用服务器端控件，不使用 form，不使用 view state
你可以选择在更底层，使用更灵活的方法去编程，也可以选择在更高的层次，使用简便快速的方法去编程，所以就不用说哪一种技术应该完全被淘汰了。
