在前端MVC越來越成熟Ajax大量運用的今天，傳統的MVC等數據處理完畢再顯示的方式有何優勢？

01-26

傳統意義上的MVC不考慮M的話，基本工作方式為C把數據採集過來，交付V進行顯示，但是不採用特別處理的話，一般都是所有的數據都處理完後最終頁面才能顯示，這樣一來問題有：
1. 載入快的數據需要等待載入慢的數據
2. 一旦載入過程中一部分發生錯誤，整個頁面都無法載入
通常的辦法都是將頁面分塊載入（例如上下左中右），然後在前端再逐塊整合，更複雜些的每塊內再進行流式處理，事情不少。
然而如果使用Ajax的話，似乎就可以將頁面每個功能都分小塊，例如1-20，前端css第一時間搭好框架，然後分別ajax請求20個controller，這樣一來似乎任何一個掛了都不影響其他，也不需要解決互相等待造成的效率問題？如果說這樣做SEO會有問題的話，那也可以讓搜索引擎只看傳統頁面。

如果這樣的話，傳統的V還有那些優勢和存在的必要性呢（除SEO外）？

速度加快。Twitter在2012年開始重新採用伺服器端生成頁面，所需要時間（主要是time to first tweet，從輸入網址到能發tweet的時間）減少到了原來ajax方式的1/5。在他們的技術博客上有專門的一篇文章介紹（如果沒有被牆）：

Improving performance on twitter.com

文章內容主要有這麼幾點：

1. JavaScript運行慢，如果用戶的計算機比較舊，那就更慢了。

We discovered that the raw parsing and execution of JavaScript caused massive outliers in perceived rendering speed. In our fully client-side architecture, you don』t see anything until our JavaScript is downloaded and executed. The problem is further exacerbated if you do not have a high-specification machine or if you』re running an older browser. The bottom line is that a client-side architecture leads to slower performance because most of the code is being executed on our users』 machines rather than our own.
We took the execution of JavaScript completely out of our render path. By rendering our page content on the server and deferring all JavaScript execution until well after that content has been rendered, we』ve dropped the time to first Tweet to one-fifth of what it was.

2. 把JavaScript模塊化，只載入需要的模塊，越小越好。

We need to minimize the amount of JavaScript we use: smaller payload over the wire, fewer lines of code to parse, faster to execute. To make sure we only download the JavaScript necessary for the page to work, we needed to get a firm grip on our dependencies.
To do this, we opted to arrange all our code as CommonJS modules, delivered via AMD. This means that each piece of our code explicitly declares what it needs to execute which, firstly, is a win for developer productivity. When working on any one module, we can easily understand what dependencies it relies on, rather than the typical browser JavaScript situation in which code depends on an implicit load order and globally accessible properties.

另外有一篇專門探討客戶端vs伺服器端生成頁面的博客，Client-Side vs. Server-Side Rendering，同樣贊成伺服器端生成，論點是：

1. JavaScript需要兩次http請求，下載並運行JavaScript，慢。

2. 開發人員不知道用戶的計算機會是什麼配置，甚至有可能是移動設備，運行JavaScript速度不理想。開發人員自己的開發用的計算機通常是高配置，運行前端JavaScript速度如飛，但並不能assume用戶也是如此。

3. 雖然可以cache JSON，但是瀏覽器總是要花時間生成html。如果伺服器端返回生成好的html，客戶端直接顯示就行。

4. 從帶寬方面來看，似乎html比json大一些，返回json應該更快。但是伺服器應該對json和html都進行壓縮，差別不是很大。

Bonus read: Separate REST JSON API server and client?

「純Ajax」載入資源和數據的方式，實際是在模仿Native App。如：SPA（single-page application）。

這種做法的最大「好處」是給了前端er更大的自由度。後端er也無所謂，因為該做的還是那樣做，只是C層的數據封裝成json的介面而已。

但這種做法畢竟是在模仿Native App，哪怕學得再像，畢竟有些條件是先天缺少的。

1、違背了W3C的標準。

Web的發展以W3C為根基，當開發者沒有遵循標準時，最終的產品就不能很好的享受那些Web原有的資源，畢竟這些資源都是根據標準而發展而來的。

如：SEO、瀏覽器載入優化..

2、以己之短，攻敵之長。

剛開始，大家都只是簡單的模仿Native App載入數據的方式，感覺也還算ok。

當該模仿的都模仿夠了，大家就開始折騰怎麼去優化。發現一個大坑：載入慢，資源請求過多。

因為Web的資源都要向伺服器請求，靜態資源加上數據介面的請求，這堆開銷絕對不少。相比Native App，代碼都早已安裝在本地了，所有請求也只不過數據請求。

為了克服這個坑，manifest也就出台了。

乍看之下也的確是個好東西，離線Web App終於可以有了！但其實，用過的人都想哭，真的誰用誰知道啊！

Web Page最大的特點（優勢）就是能快速迭代。當資源有更新時，瀏覽器就能第一時間從伺服器中獲取到更新的數據。而這方面正正是Native App的短板。

好了，現在是什麼局面？

我們為了模仿別人，結果丟掉了自身原有的優勢。

3、慢是根本原因。

哪怕JavaScript再快，也還是快不過靜態語言。（在這裡就不累贅了）

4、內存管理

JavaScript怎麼管理內存？等GC？呵呵...

越說好像越偏了。

上面一些觀點，估計也會被很多人吐槽。

例如：「SEO優化，Google早就有對SPA的方案了！！」

上面採用SPA來做論述，只是為了站在一個傳統網頁的對立面。

實際應用中，大部分都是兩者相結合的：後端輸出整體頁面 + Ajax刷新局部數據

先這樣，吃早餐去。歡迎留言交流..

我覺得這個問題看你怎麼看，以及你對AJAX如何理解，我認為AJAX並不一定非要用JavaScript請求JSON、XML等所謂的純數據類型，然後對這些數據進行解析並顯示在頁面，我認為也可以用JavaScript直接請求一段HTML，然後直接將HTML顯示在頁面指定的位置，這樣我覺得反倒能減輕客戶端壓力和前端編程的複雜度，同時還能提升可用性。我之前在某電商公司的團隊中曾經提出過一個概念「HTML既是數據」，按照該理念，伺服器端將不再給客戶端返回JSON、XML等純數據，而是在伺服器端直接生成良好的HTML，將HTML直接返回給客戶端，客戶端需要做的就是用jQuery的append方法將HTML顯示在指定的位置即可，這樣做大大減輕了前端開發者的壓力（將前端近萬行的腳本減少到不足兩千行，當然也需要感謝前端同事的努力），並且為了頁面局部進行了調整，只需要修改伺服器端View即可。

按照這樣的做法，我總結了一下，主要帶來了以下幾個好處：

1. 極大的簡化前端開發，減輕前端開發的壓力；

2. 實現了很好的前後端開發分離，前端開發工程師甚至不需要知道後端返回的數據格式，只需要知道請求地址即可執行開發；

3. 具有良好的可用性，即便是在客戶端腳本出錯的的情況下，系統基本功能都能夠正常運行；

4. 對SEO友好（我們的系統中並沒有體現出這個優勢，因為我們的系統主要是業務流程）。

我個人寫的框架，之前公司項目應用時候，都是這樣寫的：

默認分塊並各自實現各自的 view，整體的用 include 或者函數實現載入各個區塊，ajax 請求也實現個字的 view，這樣第一次載入實際上是 PHP 生成的，而後面的刷新是 ajax 只刷局部的。