在Web中充斥着所謂的MVC框架，而在我看來，因為一些關鍵性的技術原因，MVC在Web前端開發中根本無法使用(對的，是無法，而不是不該) 。
在MVC原始報告中指出：
view永遠不會知道用戶輸入，比如鼠標操作和按鍵。
很顯然，在Web前端，你無法做到這一點，因為Web的程序中，用戶的輸入必須通過監聽窗口、文檔和元素上的事件來獲得。——而這些東西常常被認為是View。
於是一些奇怪的認識誕生了，比如認為Controller應該是View操作Model的中介。
我曾經嘗試設計一個編程模型讓所有的事件流經Controller，但是事實上我發現這樣的做法非常糟糕。——這個嘗試讓我從MVC轉向了MVVM。
John Gossman（WPF的架構師）在他的文章中提到，
Model/View/ViewModel中的View表示可見元素，按鈕，窗體，圖形或者GUI中更復雜的控件，它會對快捷鍵進行編碼，並且控件自身會管理跟輸入設備的交互——這在MVC中本該是Controller負責的（現代GUI環境中發生在Controller上的事情是很長的題外話……我傾向於認為它只是隱藏到后台了，它仍然存在，但是我們不需要像是1979年那樣考慮那么多事情了）
MVC這樣的結構的正確性在於，任何界面都需要面對一個用戶，而Controller “是用戶和系統之間的鏈接”。在經典MVC中，Controller要做的事情多數是派發用戶輸入給不同的View，並且在必要的時候從View中獲取Editor來更改Model，而Web以及絕大多數現在的UI系統中，Controller的職責已經被系統實現了。下面的圖片說明了這樣的演進過程：
總而言之，對於MVC
- 為1979年的SmallTalk設計
- 界面和程序都由同一種語言編寫
- 用戶輸入完全由程序編寫者來處理
- View是單純用於顯示
對於MVVM
- 為2005年的WPF設計
- 界面多使用標記語言，程序則使用編程語言
- 用戶輸入經過UI系統底層處理和分發，多數以事件的形式被用戶程序所知
- View具有獨立性，能夠管理部分用戶輸入並且自行反應（它們常常被稱作控件，而非視圖）
作為一個Web開發者，在二者之間做出何種選擇是顯而易見的。