在每個用戶界面背後，我們都在使用 MVC 模式，也就是模型-視圖-控制器（Model-View-Controller）。MVC 發明的時候，Web 尚不存在，當時的軟件架構充其量是胖客戶端在原始網絡中直接與單壹數據庫會話。但是，幾十年之後，MVC 依然在使用，持續地用於 OmniChannel 應用的構建。
Angular 2 正式版即將發布，在這個時間節點重估 MVC 模式及各種 MVC 框架為應用架構帶來的貢獻意義重大。
我第壹次接觸到 MVC 是在 1990 年，當時 NeXT 剛剛發布 Interface Builder（讓人驚訝的是，如今這款軟件依然發揮著重大的作用）。當時，我們感覺 Interface Builder 和 MVC 是壹個很大的進步。在 90 年代末期，MVC 模式用到了 HTTP 上的任務中（還記得 Struts 嗎？），如今，就各個方面來講，MVC 是所有應用架構的基本原則。
MVC 的影響十分深遠，以致於 React.js 在介紹他們的框架時都委婉地與其劃清界限：“React 實現的只是 MVC 中視圖（View）的部分”。
當我去年開始使用 React 的時候，我感覺它在某些地方有著明顯的不同：妳在某個地方修改壹部分數據，不需要顯式地與 View 和 Model 進行交互，整個 UI 就能瞬間發生變化（不僅僅是域和表格中的值）。這也就是說，我很快就對 React 的編程模型感到了失望，在這方面，我顯然並不孤獨。我分享壹下 Andre Medeiros 的觀點：
React 在很多方面都讓我感到失望，它主要是通過設計不佳的 API 來引導程序員[…]將多項關註點混合到壹個組件之中。
作為服務端的 API 設計者，我的結論是沒有特別好的方式將 API 調用組織到 React 前端中，這恰恰是因為 React 只關註 View，在它的編程模型中根本不存在控制器。
到目前為止，Facebook 壹直致力於在框架層面彌合這壹空白。React 團隊起初引入了 Flux 模式，不過它依然令人失望，最近 Dan Abramov 又提倡另外壹種模式，名為 Redux，在壹定程度上來講，它的方向是正確的，但是在將 API 關聯到前端方面，依然比不上我下面所介紹的方案。
Google 發布過 GWT、Android SDK 還有 Angular，妳可能認為他們的工程師熟知何為最好的前端架構，但是當妳閱讀 Angular 2 設計考量的文章時，便會不以為然，即便在 Google 大家也達成這樣的***識，他們是這樣評價之前的工作成果的：
Angular 1 並不是基於組件的理念構建的。相反，我們需要將控制器與頁面上各種[元素]進行關聯（attach），其中包含了我們的自定義邏輯。根據我們自定義的指令如何對其進行封裝（是否包含 isolate scope？），scope 會進行關聯或繼續往下傳遞。
基於組件的 Angular 2 看起來能簡單壹點嗎？其實並沒有好多少。Angular 2 的核心包本身就包含了 180 個語義（Semantics），整個框架的語義已經接近 500 個，這是基於 HTML5 和 CSS3 的。誰有那麽多時間學習和掌握這樣的框架來構建 Web 應用呢？當 Angular 3 出現的時候，情況又該是什麽樣子呢？
在使用過 React 並了解了 Angular 2 將會是什麽樣子之後，我感到有些沮喪：這些框架都系統性地強制我使用 BFF“頁面可替換模式（Screen Scraping）”模式，按照這種模式，每個服務端的 API 要匹配頁面上的數據集，不管是輸入的還是輸出的。