本文鏈接：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 整理。