react.js在伺服器端渲染有什麼好處？渲染是怎麼個流程？

01-02

貌似現在好多公司為了提升性能，用react.js在伺服器端渲染，具體渲染是怎麼個流程呢？還有渲染後台一定要是node.js嗎？(針對react.js而言)，react.min.js和jsx.min.js還有那個動畫的min.js每個都是100多KB啊，在移動端也太大了吧？

1. 有些回答中提到CPU負載和node.js效率問題。伺服器端渲染固然耗CPU，但可以使用伺服器端緩存的方式解決，並不是每個用戶訪問都需要重新渲染一遍。而且伺服器端渲染甚至可以潛在地增加伺服器效率（這點在參考資料第二個里有提到，不過是純英文的，我有空會翻譯下）。

2. 伺服器端和客戶端可以共享某些代碼，避免重複定義。這樣可以使結構更清晰，增加可維護性

3. 首次載入頁面的速度加快。客戶端渲染的一個缺點是，當用戶第一次進入站點，此時瀏覽器中沒有緩存，需要下載代碼後在本地渲染，時間較長。而伺服器渲染則是，用戶在下載的已經是渲染好的頁面了，打開速度比本地渲染快。

4. SEO。伺服器端渲染可以讓搜索引擎更容易讀取頁面的meta信息以及其他SEO相關信息，大大增加網站在搜索引擎中的可見度。

其實並不一定要爭個好壞，伺服器端和客戶端渲染各有各的優缺點。建議根據實際需求，在某些頁面使用伺服器渲染，某些頁面使用客戶端渲染，以達到最佳解決方案。

參考資料：

Flow Router 4.0 Future of Routing in Meteor

Server-Side Rendering with React and React-Router

謝邀。

先要明確一點，所有技術都有其適用範圍，包治百病的一般都是假藥。

目前業界開發通用的模式是：後端負責提供數據，前端負責數據展現（也就是渲染），這種開發模式中大量使用了ajax來實現頁面的局部刷新。

何為渲染？

如果我們只是想顯示一堆不變的數據，那麼我們直接寫一個a.html丟到伺服器上讓客戶端訪問就可以了。但這是基本不可能的事情，數據一般是變化的。你不可能為每套數據寫一個視圖，所以我們需要分離數據和視圖，然後使用一種技術將數據塞到視圖中，這種技術就叫渲染。這工作放在伺服器上做就是伺服器渲染，放在瀏覽器做就是瀏覽器渲染。

瀏覽器渲染

單頁應用用的基本都是瀏覽器渲染。優點很明確，後端只提供數據，前端做視圖和交互邏輯，分工明確。伺服器只提供介面，路由以及渲染都丟給前端，伺服器計算壓力變輕了。但是弱點就是用戶等待時間變長了，尤其在請求數多而且有一定先後順序的時候。

伺服器渲染

伺服器接到用戶請求之後，計算出用戶需要的數據，然後將數據更新成視圖（也就是一串dom字元）發給客戶端，客戶端直接將這串字元塞進頁面即可。這樣做的好處是響應很快，用戶體驗會比較好，另外對於搜索引擎來說也是友好的，有SEO優化。現在題主說的應該是nodejs層的伺服器渲染，這裡還有一個明顯的好處就是前端性能優化更順手了，可操作的空間大了。但是缺點也很明顯，如果不是增加一個node層的話，前後端責任分工不明，不能很好的並行開發。另外也增加了伺服器計算壓力（雖然可以做渲染緩存，但畢竟是多做了計算）。

根據以上特點，在用戶體驗要求比較高的頁面（首屏）、重複較多的公共頁面可以考慮使用伺服器渲染，減少ajax請求和提升用戶體驗。回到react上其實也是一樣的道理。

再看看其他人說的100s的例子，假如在伺服器上都需要1s的渲染，請問在瀏覽器端的渲染時間會是多長呢？如果這100個用戶需要的渲染結果都是沒有重用性的話，那的確伺服器渲染有點划不來。

seo。其實seo就是個「搜索引擎自己不做好逼著別人和他一起慘」的典型，我國政府差不多也這樣，怎麼就見你們罵政府不見你們罵google了（此人已死）

首屏性能。這個優勢是存在的，說react伺服器端渲染性能差的，沒讓你沒次都渲染啊，你把渲染結果緩存下啊，你撐伺服器壓力小偷偷渲染啊，你要雙十一活動頁了提前兩天半夜渲染好啊（此人狂暴）

還有一個好處，也許我可以拋開dom做組件測試（此人蛋疼）

純粹用React做伺服器端渲染（As a template lib）並沒多大好處，基本上是指的是『 isomorphic』

基本渲染的流程主要是

準備數據，一般從資料庫或外部API獲得 (一般要先 render React 一次，去觸發所需的API)
數據和React結合生成HTML Markup
除了把HMTL Markup輸出外，還要把"State"輸出，這要在客戶端才能保留"State"

不一定要用Node.js做整個後台，但Node.js 是必不可少的, 必須有一個JS Runtime 在伺服器端（Isomorphic ReactJS app with Ruby on Railsa€?a€」a€?Part 1: Server-side rendering a€」 Technically speakinga€|）
用isomorphic方式不代表你整個website都需要server render, 可以只要server render 那些需要SEO的，其它部分可以在client side 運行，甚至同一個頁面可以同時支持server/client render

1：所謂的提升性能的概念混亂，提升性能是需要再瀏覽器端的性能提升還是服務端的性能提升，是兩個概念，服務端渲染會給服務端造成一定的壓力，減輕客戶端的壓力；好處：在整個頁面級別的應用會使得瀏覽器在解析dom完成之後馬上有東西可以渲染。再者就是對seo比較友好一些；

2：渲染流程：你要理解html代碼是怎麼從服務端出來的，每一門語言都會有自己的生成的機制，並也有相對的落地框架，如http://asp.net framework裡面的webform，node裡面的koa，express等。所謂的服務端渲染就是在服務端根用template+data生成出html來，具體實現過程，你可以參考下express（相信你是個noder）；

3：是否必須要node；目前我沒有發現在別的web應用框架（或者說是語言）中實現過react的服務端渲染技術框架，畢竟這個工作量很大，而且實現出來也非常雞肋；

4：100k相對來說還好，看你的需要優化程度。在實踐優化過程中這個基礎文件一般都會做緩存。

順便提一下，react優勢在於對瀏覽器端的渲染做了最小化處理，這是它的優勢之一，在這它宣導了前端領域進行解耦的思維（大部分前端所欠缺的）。當然，運用任何的技術和框架都是有代價的，根據項目區評估優略勢，再考慮執行層面的事情；

最主要的原因還是為了同構，seo可以用phantom做

只回答樓主的問題之一，即渲染後台一定要是 node.js 嗎？

不是。

其實 JVM 上也有 JavaScript 的渲染引擎，即 Nashorn，然後就可以用來直接在後端運行 React 代碼了。

雖然是可行項，但不一定是優選項。但是對於遺留系統來說，採用 Java + React 就屬於比較不錯的折中方案，一方面可以大大簡化 View 層的寫法，一方面也是進一步將視圖邏輯分離，可以兼顧未來的重構方案。

參考：

GitHub - geowarin/boot-react: A starter application with spring boot and react
GitHub - winterbe/spring-react-example: Isomorphic Spring Boot React.js Example

剛做的服務端渲染開源項目

可以看下這個

GitHub - bodyno/universal-react-starter-kit: 服務端渲染的React手腳架。完美使用 React, Redux, and React-Router！最好用的腳手架

我不覺得有什麼好處，純粹做了玩玩，我也不覺得Node效率有什麼高，就這樣了其實

如果單純說服務端渲染的話，那麼用react的確是沒有任何優勢可言。那為何還要說react服務端渲染呢？是因為選擇了react，或者說是選擇了react生態圈。

關於選擇react的討論，你可以去這裡看：http://www.zhihu.com/question/31613336

關於react native的討論你可以去這裡看：http://www.zhihu.com/question/27852694

好處： seo ；頁面更早呈現

服務端渲染是指的第一次訪問，後續的渲染還是客戶端自己去做的。

目前，前端領域中 React 勢頭正盛，很少能夠深入剖析內部實現機制和原理。我們希望通過剖析 React 源碼，理解其內部的實現原理，知其然更要知其所以然。對於 React，其組件生命周期（Component Lifecycle）是它的核心概念，本文從源碼入手，來剖析 React 生命周期的管理藝術。

React 的主要思想是通過構建可復用組件來構建用戶界面。所謂組件其實就是有限狀態機，通過狀態渲染對應的界面，且每個組件都有自己的生命周期，它規定了組件的狀態和方法需要在哪個階段進行改變和執行。黑板報

在服務端渲染有個P的好處。無知的人才會這麼做。

舉個例子，假設渲染一個界面，需要一個模板串和一個數據，總的渲染時間是 1 s。現在有 100 個客戶進來，你要為每一個客戶渲染，在伺服器的總渲染時間是 100 s。第 100 個客戶啥都不用幹了，等著你渲染 100 s 吧。

放在客戶端渲染，則伺服器總渲染時間是 0 s。每個客戶端渲染時間都是 1 s。