本文链接：https://blog.csdn.net/closurer/article/details/79526006
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
你可以选择在更底层，使用更灵活的方法去编程，也可以选择在更高的层次，使用简便快速的方法去编程，所以就不用说哪一种技术应该完全被淘汰了。
根据帖子：http://bbs.csdn.net/topics/392077893 整理。