關於服務端渲染與客戶端渲染的優劣，網際網路上已經有過很多的文章進行過分析，在這裡我談一下我個人的見解。
首先，還是來老生常談一下關於兩種渲染方式的主要優劣：
服務端渲染（僅列出當下最突出的優劣）：
優：
- SEO友好（目前現狀下，我認為是最大的優點，也是最大的需求）
- 首屏渲染速度快（不用下載臃腫的bundle.js）
劣：
- 增加伺服器壓力（在訪問量猛增時，這是非常致命的，可能直接導致伺服器掛掉）
- 互動方式單一，無法進行非同步重新整理（可以通過後端在html中插入js程式碼繫結事件來實現非同步重新整理）
客戶端渲染的優劣則與服務端渲染相反。
在十幾年前，那時候javascript還沒有興起，web開發還是使用傳統的ASP、Java、PHP等語言，渲染方式也就侷限於服務端渲染。但是隨著jQuery的發展，非同步載入技術的成熟，前端所做的事情也就越來越多。隨著一批批前端開發人員對於互動體驗的不斷完善，頁面效能的極致追求，在近幾年不斷湧現出非常優秀的前端框架庫，比如說當下最流行的Angular、React、Vue和處於成長階段的next.js、阿里的beidou框架等。可以說，如今js真可謂是百家爭鳴了。
從一開始後端語言驅動的服務端渲染，到如今React等前端框架引領的客戶端渲染，不管是使用者體驗方面，還是效能方面，都有了一個質的提升。當我們正享受著客戶端渲染帶來的舒適時，一部分網際網路企業又悄悄的變回了服務端渲染，這樣一個逆著發展方向的做法，實屬無奈的選擇，很大一方面是為了應對國內某度尷尬的SEO。為了針對服務端渲染的需求，React還實現了renderToString的方法用來將根據資料生成的dom結構轉成相應字串，方便由後端輸出給前端。至於Vue和Angular有沒有實現類似的方法還沒有去了解過，用興趣的同學可以去他們的官網查下文件。
據我所知，Google已經實現了可以通過執行頁面中js程式碼的方式來爬取資料，也就是說，Google已經有能力爬取客戶端渲染的頁面了（不是崇洋媚外，確實人家做的比國內好），而國內某度，還停留在爬取html的階段。單純的客戶端渲染，html檔案是沒有實質性內容的，所有內容都是通過js非同步載入來的，於是某度面對客戶端渲染的頁面，只能兩眼一黑。
不過，國內搜尋引擎終究也會實現對客戶端渲染頁面的爬取的，這只是一個時間問題罷了。雖然說在當下，服務端渲染這個最大的優點還是客戶端渲染無法解決的，但是隨著時間的推移，網際網路的進步，這都將不再是問題。
再來說說首屏渲染的問題。用過React或者Vue的同學都知道，打包出來的bundle.js檔案大小通常都在1M以上，而這個入口js通常要在渲染首頁之前完全下載完畢，然後再執行其中的js獲取資料、渲染頁面，這是spa頁面載入的一個機制。js的執行、資料的獲取、頁面的渲染這些都是瀏覽器的工作，基於現在的V8引擎，這些步驟都可以很快完成，而這個1M以上甚至更大的入口js的下載就是一個非常大的問題了。如果是pc端，在目前國內正常使用者的網路環境下，這點大小的檔案還不成問題，但如果是移動端，就要好好考慮一下了。在4G網路環境下，這1M的檔案可以說下載起來非常輕鬆，1秒就可以下載完畢；如果使用3G網路，則1M大概需要下載4到5秒，這個時間已經影響到使用者體驗了；如果使用2G網路，或者在訊號不好的地方，那這個時間就慘不忍睹了，使用者需要等待漫長的白屏，甚至會造成當前頁面已經打不開了的誤解。
客戶端渲染流程
針對這種網路狀況不好的情況下，首屏渲染極慢的問題，有人提出了同構的思想。其意為前後端使用同一套程式碼，首屏使用服務端渲染，將渲染好的html直接交給瀏覽器去渲染，瀏覽器渲染出首屏之後繼續下載bundle.js，執行js，並且重新渲染頁面。由於渲染好的html流相較於bundle.js來說，體積小了很多，所以採用同構方式的web頁面，一定程度上解決了首屏渲染慢的問題，而且合理利用快取策略還可以一定程度減輕伺服器壓力。當然這種模式當中還存在著其他問題，在這裡就不細說了。
同構渲染流程
使用同構這種開發模式，雖然不能完全解決SEO的問題，但是首屏是可以被爬取的，如果說專案不是類似於淘寶這種內容型網站（網站內部各個頁面都有SEO需求），那麼這種模式就非常優秀了，解決了純客戶端渲染在當下面臨的兩個最大的問題。
在今年舉辦的第12屆D2前端大會上，筆者又聽到了一個十分優秀的想法，並且阿里已經將之實現並申請了專利————智慧降級策略。具體名字是不是這個已經記不太清了，大致內容是在同構的基礎之上，優先使用服務端渲染，當訪問量激增導致伺服器負載超過設定的閾值之後，智慧將部分渲染任務交給客戶端處理，使伺服器承受壓力降低（想想就很厲害啊，畢竟阿里，有錢有人有才）。
毫無疑問，同構或者智慧降級在面對當前國內網際網路發展狀況下，是非常有發展空間的。但是如果需要考慮到開發成本和硬體成本，單純的客戶端渲染還是佔有優勢的。同構或許是web開發的一個方向，但是絕不僅僅是唯一的一條路，具體採用什麼樣的方式構建專案，還是需要根據具體專案的需求來確定。
文中圖片來源於 以同構之名，再談 Redux/Vuex 的必要性