前端迷思與React.js

前端迷思與React.js

    前端技術這幾年蓬勃發展, 這是當時某幾個項目需要做前端技術選型時, 相關資料整理, 部分評論引用自社區。

開始吧:

• 目前， Web 開發技術框架選型為兩種的占 80% 。這種戲劇性的變化持續了近 6 年。
• 自 2013 年 5 月推出以來，ReactJS 在過去三年中已成為了 Web 開發領域的中堅力量。
  

任何組件與框架都有它的適用場景, 我們應該冷靜分析與權衡, 先來看React.js

1 從功能開發角度說，React的思路很好。
2 從頁面設計角度說，傳統的HTML+CSS以及同樣思路的模板更好。

     大家開發前端的思路早已不是當年的 Web page，而是Application。大多數公司不是Facebook，沒有那麼多全棧高手。團隊中擅長寫業務的，未必擅長頁面佈局；擅長頁面佈局的，未必擅長寫業務。這樣在團隊中必定會有分工，其中會有些人著重實現炫酷的頁面效果，而React顯然對這種分工不友好。

為什麼需要 React,Why？

    我們需要技術棧提供好用的模塊化方式，可以是Web Component，可以是非Web Component的某種機制，不管什麼庫或者框架，我們需要技術賦予我們完成一個抽象，一次構建，多處復用的能力，並且這個過程不能太麻煩，不能做個很日常的抽象翻半天文檔。
    我們需要數據綁定，在各種粒度上真正實現事件驅動，因為這樣我們就不用自己重覆手寫本質上並不依賴場景的從視圖到數據從數據到視圖的自動更新，否則我們就得自己操作DOM，優化DOM操作，還要自己維護狀態，一自己維護狀態，就要陷入狀態同步的漩渦，浪費大量時間和精力。
    我們需要技術棧隱藏掉平臺的微妙差異，寫一段代碼可以真正實現跨平臺，而不用我們自己糾結於那些本不該應用開發糾結的事，我們需要持續穩定的跨平臺支持，最好的移植就是不用移植，這在商業上有很大的價值。
我們需要庫或者框架好學，好用，從第一天起就能快速開發，而不是不得不經歷幾個月的學習曲線那種，因為大多數團隊的程式員水平都存在梯度，我們不希望因為一個技術棧把初學水平的人擋在門外很久，理想的狀態是技術本身能對招聘工作完全透明，同樣的工期，同樣的項目，隨時找人都可以，招人的時候不用寫得過於具體，只要會JavaScript就能快速上手，我們需要概念負擔儘量少的技術棧，真正理解了Simplicity的技術。
    我們希望技術棧有非常好的性能，性能的水平和垂直擴展性都很好，這樣我們就不用項目寫到一半回頭去糾結應用開發團隊很難解決的性能問題，我們需要在快速開發和基礎性能之間平衡得很好的工具，而不是因為要強調某一方面而對另一方面關註太少的那些工具。
    我們需要使用的工具有專業的團隊或者社區持續地跟進，最好這些團隊和社區自己就把自己的東西投入生產使用的技術，這樣至少對我們來說風險就有起碼的控制。我們不需要那些心血來潮，永遠不成熟因為永遠沒有專門投入的技術。
    我們需要那些普通人喜歡用，也用得好的技術。
    React滿足上面的一些方面，不滿足另一些方面，和其他工具一樣。你需要React，是因為兩點
    第一，你充分評估了你的項目，理解你要解決的問題是什麼，是快速開發，性能，團隊的人類工程學，多數情況下要解決的問題是多個要素的平衡
    第二，你充分評估了React這個棧，理解它是解決你的具體問題的最佳工具，你真的理解了自己的場景中非用React不可的那些事情
    如果你覺得React快所以需要，事實是React並沒有那麼快，尤其是大型應用，小型應用里快是不重要的，所有的框架都足夠快。
    如果你覺得React開發快所以需要，事實是React並一定是最好用的，尤其是當你考慮了團隊的構成。

    如果你覺得React是Facebook開發的所以需要，我的揣測是經歷過一個社區adoption的高峰以後，Facebook未必能解決剩下的那1%的問題。
    如果你覺得React Native很火所以需要，這或許是一個理由，但RN也不是唯一選擇，從各方面評估，NativeScript這樣的棧並不比RN壞多少，也許還稍微好一點。如果是大預算的商業開發，RN甚至不應該成為首選。

    大部分人在用 React 的時候，用到的是兩個特性：

    1. 虛擬 DOM

    2. 組件化

   至於其他的偽特性，我認為是有些同學「一瓶子不滿，半瓶子咣當」，意淫出來的。這些偽特性包括：

    1. 跨平臺。雖然 ReactNative 可以在多個平臺上使用，但是 ReactNative 並沒有封裝不同系統的 API。從這方面來說，這貨甚至連 weex 都不如。
    2. 更易於組織邏輯。這明顯是 flux/redux 做的事情。而且 redux 已經明確說明瞭，不僅僅適用於 React，其他框架也可以用 redux。

我們真的需要上述的兩個特性嗎？

虛擬 DOM

虛擬 DOM 解決了頻繁操作 DOM
產生的性能問題。那麼下麵幾項事實必定會導致這一特性「沒有前途」：

1. 設備的硬體性能會越來越好，性能在將來不再是問題。
2. 假如說我們要解決性能問題，相比虛擬 DOM，
下麵幾個解決方案會更好：
1. 瀏覽器實現虛擬 DOM。而且這也是虛擬 DOM 被應用的正確場景和姿勢。
2. 再操作數據的地方做 diff，而不是在虛擬 DOM 的基礎上做 diff。這是才是 cache/diff 的正確用法。

組件化

組件化有一個很重要的目的是為了提高開發效率。再來看一下使用 React 開發效率高嗎？

民間：想加班就用 React

為了說明 React 的開發效率，不妨點開兩個鏈接看一下代碼行數。下麵兩個鏈接都實現了一個聊天應用，完全一樣的功能：

· React 版本：187 行

· Riot 版本：53 行

React的不足之處

純凈、不可變性和解決問題的意識形態

    不要誤解，我其實很感激React所帶給我們的純凈的函數編碼方式和簡潔的渲染手法，在實際應用中，這些都算得上好東西。我想說的是其它方面的東西。

    如果你的公司里有千人開發團隊，而剛好你決定要為PHP里的靜態類型開發自己的語法，又或者你正從Haskell轉向JS，那麼一定程度的嚴格和純凈是非常有用的。不過大部分公司不會有那麼大規模的開發團隊，也不會有Facebook那樣的巨集大目標。下麵我會更詳細地解釋這一點。

JSX糟糕透了

    我知道，它“不過是具有特殊語法的javascript罷了”。我們的前端設計人員為了做出漂亮的表單，把表單元素放置在div裡面，他們根本不關心什麼純凈或ES6。設計React組件仍然需要耗費大量的時間，因為JSX的可讀性太差。還有一個不好的地方，就是你無法在HTML代碼里使用普通的IF語句。React的忠實用戶會告訴你說，有了三元運算，就不需要再使用條件判斷了。不過我向你們保證，當你再次閱讀或編輯這些代碼時，你會發現它們仍然是HTML和JS的混合體，儘管它們可以被編譯成純粹的JS。

<ul>

       {items.map(item =>

         <li key={item.id}>{item.name}</li>

       )}

</ul>

    很多開發者認為這種嚴格的限制可以幫助我們寫出更加模塊化的代碼，因為我們必須把代碼塊放到工具函數里，併在render()方法里調用，就像這個人建議的那樣：
http://stackoverflow.com/a/38231866/1132016。

    JSX甚至讓我們不得不把15行的HTML代碼分成3個組件，每個組件里包含5行代碼。

    不要認為這種做法會讓你成為更好的開發人員，你只是不得不這麼做而已。

而事實其實是這樣的：

    如果你正在開發一個相對複雜的組件，而你並不打算明天就把它發佈到GitHub上，那麼上述的方式只會拖你的後腿，特別是在你要解決真實的業務問題時。不過不要誤會，我並不是說拆分成小組件就一定不好。

    你當然清楚通過拆分可以提升代碼的可管理性和可重用性。但前提是，只有當業務邏輯實體可以被放到一個單獨的組件里時才要這麼做，而不是每寫一個三元操作代碼就要進行拆分！每次在創建新組件時都會讓你和你的意識流付出一定的代價，因為你需要從業務思維（在你記住當前組件狀態時，需要增加一些HTML代碼讓它運行起來）轉換到“管理思維”——你需要為這個組件創建單獨的文件，考慮如何給新組件添加屬性，並把它們跟組件狀態映射起來，還要考慮如何把回調函數傳遞進去，等等。

    你被迫使用這種過度且不成熟的組件模塊化方式來編寫代碼，從而降低了編碼速度，而從中得到的模塊化可能並非你所需要的。在我看來，不成熟的模塊化跟不成熟的優化沒有什麼兩樣。

    對於我來說，代碼的可讀性是非常重要的，不過是否能夠從編碼中獲得樂趣也很重要。為了實現一個簡單的計算器控制項而去創建六個組件，這樣的事情一點也不有趣。大多數情況下，這樣做也不利於維護、修改或控制項檢修，因為你要在很多文件和函數間跳來跳去，逐個檢查每一個HTML小代碼塊。再次強調，我並不是在建議使用單體，我只是建議在日常開發當中使用組件來替代微組件。這是常識性問題。

在React里使用表單和Redux會讓你忙得停不下來

    還記得嗎，React的設計在於它的純凈以及乾凈的單向數據流。這就是為什麼LinkedStateMixin不受待見，你需要為10個輸入創建10個函數，而80%這樣的函數只包含了一行this.setState()代碼，或者一次redux調用（或許你還需要為每個輸入創建一個常量）。如果只要在腦子裡想想就能自動生成這些代碼的話，或許還是可以接受的，但現在還沒有哪個IDE可以提供這樣的功能。

    為什麼要敲這麼多的代碼呢？因為雙向綁定被認為是不安全的，特別是在大型應用里。我可以肯定地說，雙向數據流的代碼可讀性確實不是很好，而Angular 1的雙向綁定更是糟糕透頂。不過，這些還算不上大問題。

    Redux看起來更像是啰嗦的代名詞。開發人員抱怨Mobx把React變成了Angular，就因為它使用了雙向綁定——可以參見之前講到的第一點。似乎很多聰明人只是讓他們的代碼看起來更純凈，但是並沒有完成更多的事情（不過如果你沒有截止期限或許問題不大）。

過度的工具綁定

    React有點亂糟糟的。如果離開了一大堆npm包和ES5編譯器，要做出React應用簡直是寸步難行。基於React官方基礎包開發的一個簡單應用在node_modules目錄下包含了大約75MB的JS代碼。

這不算什麼大問題，它更像是JS世界的事情，不過使用React仍然只會增加我們的挫折感。

當前狀態

    v15.5.4 April 11, 2017

    Facebook正在以流行的JavaScript框架React為基礎開發一個全新的架構。這個名為React Fiber的全新設計改變了檢測變更的方法和時機，藉此可改進瀏覽器端和其他渲染設備的響應速度。這一全新架構最初已於2016年7月公開發佈，其中蘊含著過去多年來Facebook不斷改進的工作成果。該架構可向後相容，徹底重寫了React的協調（Reconciliation）演算法。該過程可用於確定出現變更的具體時間，並將變更傳遞給渲染器。

最新動態

    2017年5月4日，Facebook開源團隊技術作者Joel Marcey在Hacker News社區發佈一則《Prepack幫助提高JavaScript代碼的效率》，引起了社區的廣泛討論。

    官方宣稱Prepack是一個優化JavaScript源代碼的工具，實際上它是一個JavaScript的部分求值器（Partial Evaluator），可在編譯時執行原本在運行時的計算過程，並通過重寫JavaScript代碼來提高其執行效率。Prepack用簡單的賦值序列來等效替換JavaScript代碼包中的全局代碼，從而消除了中間計算過程以及對象分配的操作。對於重初始化的代碼，Prepack可以有效緩存JavaScript解析的結果，優化效果最佳。

    React 16（正在開發中）是一次革新，但也使用了相同的公開API。對於Facebook所使用的超過30,000個（！）組件，其中只有少量需要改動，並且這少數組件主要被一些已經不再支持或沒有正式記錄在案的行為所使用。因此可以說完全可以保證99.9%的相容性。這也讓我們確信React 16基本上也可以直接適用於你的代碼。

AngularJS

    在富應用開發中，跟Angular完全沒得比，在同等熟練條件下，Angular開發效率＝五倍React＝三倍backbone＝十倍jquery，然而虛擬dom並沒有什麼亂用，二十一世紀，效率為王，Angular萬歲，它代表了前端最先進的生產力，代表了前端先進文化的前進方向，代表了最廣大前端的根本利益，然而一切抄襲angular造輪子的技術都將被歷史的車輪碾壓，粉身碎骨。

Angular很清晰的劣勢

- Angular的Dependency Injection很醜，為了minify還要用array寫兩遍變數名

- Angular的module和es6 module相容性很不好

- Scope chain只能讓人越用越糊塗。Controller as也沒改善太多

- Provider, Factory, Service其實是一樣的東西

- 目前的最佳實踐是頁面上所有東西都用Directive,強制組件化(那為啥不直接用React?)

- 侵入性太強，需要學很多Angular特有的語法，track by, transclude, $開頭的所有變數，scope, promise. http 都必須使用它提供的

動態

    Angular 團隊宣佈發佈 4.0.0 版本，該版本能夠向後相容絕大部分 2.x.x 應用。在 4.0.0 中，帶來的主要改變包括應用更小並且速度更快、更新了視圖引擎，減少了將近 60% 的生成代碼、並且引入了動畫庫作為預置的核心庫的一部分等。更多參考:
https://angular.cn/blog/angular-400-now-available.html
https://hackernoon.com/top-8-resources-to-explore-angular-4-ff2c1b42020a?gi=151b442f3045#.3fgnc8ibr

Angular 2搭配React Native

    Angular 2可以通過Angular Electron運行在桌面上，或者在微軟的UWP上在移動設備端，Angular 2提供了一些選擇項比如Ionic 2，NativeScript或者React Native。對於最後一個，有個庫使得用React Native渲染Angular 2應用變得有可能。開發者可以調用所有React Native提供的API和polyfill來使用iOS和Android的原生功能，然後回調可以按需在Angular Zone中執行

    React和Angular 2有很多共同點，他們在處理應用框架和數據上使用了相似的原理。另一方面，每個功能的實現都使用了不同的方式（組件調用的生命周期還是完全一致的）。這些不同點並不意味著應用開發時的難度，每種方案都提供了足夠完善的工具來開發一個大型、嚴謹、靈活的應用核心。

    當然React更小並且只涵蓋view/component的操作–這是我這裡要對比的。缺少向html的擴展機制無疑是React唯一不足的地方。

    Angular2則更加穩定、可擴展和更加完善。但是它仍然在beta階段–並且相對對手具有優勢因為無論相比angular1還是React的經歷來看它具有更加優秀的合併思想。

Vue.js

     Vue.js是2016年發展最快的JS框架之一，而且我認為它的崛起並不是因為粉絲的過度追捧，也不是因為某個大公司的權威推動。

Vue.js的優勢

    Vue.js在可讀性、可維護性和趣味性之間做到了很好的平衡。Vue.js處在React和Angular 1之間，而且如果你有仔細看Vue的指南，就會發現Vue.js從其它框架借鑒了很多設計理念。Vue.js從React那裡借鑒了組件化、prop、單向數據流、性能、虛擬渲染，並意識到狀態管理的重要性。Vue.js從Angular那裡借鑒了模板，並賦予了更好的語法，以及雙向數據綁定（在單個組件里）。從我們團隊使用Vue.js的情況來看，Vue.js使用起來很簡單。它不強制使用某種編譯器，所以你完全可以在遺留代碼里使用Vue，並對之前亂糟糟的jQuery代碼進行改造。

    Vue.js可以很好地與HTML和JS一起協作。你可以開發出非常複雜的模板，而不會影響你對業務的專註，而且這些模板一般都具有很好的可讀性。當模板膨脹到很大的時候，說明你在業務實現方面已經取得進展，這個時候你或許想把模板拆分成更小的組件。相比項目啟動之初，此時你對應用的整體“映像”會有更好的把握。

    這個跟在React里不太一樣：Vue.js幫我節省了很多時間。在React里，在一開始就要把組件拆分成微組件和微函數，否則你會很容易迷失在亂糟糟的代碼里。在React里，你需要花很多時間在一次又一次的整理prop和重構微組件（這些組件可能永遠都不會被重用）上面，因為如果不這麼做，在修改應用邏輯時就看不清方向。

    在Vue裡面使用表單是件輕而易舉的事情。這個時候雙向綁定就會派上用場。就算是在複雜的場景里也不會出現問題，不過watcher乍一看會讓人想起Angular 1。在你拆分組件的時候，會經常用到單向數據流和回調傳遞。

    如果你需要用到編譯器的一些特性、lint、PostCSS和ES6，你會如願以償。在Vue.js 2里，Vue的擴展特性將會成為開發公共組件的預設方式。順便提一下，開箱即用的組件CSS看起來是個好東西，它們可以減少對CSS層級命名和BEM的依賴。

    Vue.js的核心具有簡單有效的狀態和prop管理機制，它的data()和props()方法在實際當中可以有效地工作。通過Vuex可以實現更好的關註點分離（它跟React里的Mobx有點類似，都包含了部分可變狀態）。

    大部分Vue.js場景都不需要Vuex提供的狀態管理，不過多一個選擇總不是壞事。

Vue.js的不足

1. 最大的一個問題：模板的運行時錯誤描述不夠直觀，這個跟Angular 1有點類似。Vue.js為JS代碼提供了很多有用的警告信息，例如當你試圖改變prop或不恰當地使用data()方法時，它會給出警告。這也是從React借鑒過來的比較好的方面。但對模板的運行時錯誤處理仍然是Vue的一個弱項，它的異常堆棧信息總是指向Vue.js的內部方法，不夠直觀。

2. 這個框架還很年輕，還沒有穩定的社區組件。大部分組件是為Vue.js 1創建的，對於新手來說有時候難以區分它們的版本。不過你可以在不使用其它第三方庫的前提下在Vue裡面完成很多事情，你可能需要一些ajax庫（如果你不關心同構應用，可以考慮vue-resource）或者vue-router，這在一定程度上平衡了Vue在組件方面存在的不足。

3. 社區軟體包里的代碼有很多中文註釋，這一點也不奇怪，因為Vue.js在中國很流行（它的作者就是個中國人）。

4. Vue.js是由一個人維護的項目，這個也算不上大問題，不過還是要考慮其它一些因素。尤雨溪是Vue的作者，他曾經在Google和Meteor工作，在那之後他創建了Vue。Laravel也曾經是一個單人項目，不過後來也很成功，但誰知道呢……

比較

5 BEST JAVASCRIPT FRAMEWORKS IN 2017

https://www.dunebook.com/5-best-javascript-frameworks-to-learn-in-2017/
https://da-14.com/blog/5-best-javascript-frameworks-2017

React vs Angular 2: Comparison Guide for Beginners

https://www.codementor.io/codementorteam/react-vs-angular-2-comparison-beginners-guide-lvz5710ha

Vue.js官方與其它框架的比較

http://cn.vuejs.org/v2/guide/comparison.html

· React： React與Angular & Ember的不同之處在於其有限的應用範圍和空間占用。Angular & Ember的定位是框架，而React主要是作為應用程式“視圖”。React不包含依賴註入或“服務”支持，不需要“jq-lite”，也不依賴於jQuery。開發人員可以直接使用JSX編寫標記，而無需Ember Handlebars。React會維護一個“虛擬DOM”，並通過它更新真正的DOM，避免了不必要的重排與重繪。總之，他非常喜歡React這種用途相對專一的特性。而且，React讓他可以將複雜的應用程式切分成更小的組件。

· Falcor：這是一個由Netflix開源的、非常新的庫。不同於傳統REST API，它只提供唯一的一個端點。有了它，開發者不再需要向不同的伺服器端點請求不同的數據，而是向同一個端點請求不同的模型數據。伺服器端可以識別請求參數，並由Falcor Router調用恰當的router函數。也就是說，Falcor提供了一個更加直觀的API，就是開發者的數據模型。這可以確保伺服器永遠不會返回不必要的模型數據，節省了帶寬。Falcor客戶端還可以使用緩存數據為連續的請求提供服務，減少伺服器響應時間。要瞭解更多關於Falcor的信息，可以查看Jafar Husain的視頻。

· Webpack：作為一個模塊綁定器，webpack可以為React組件模塊化提供進一步的支持。它使開發者可以輕鬆壓縮和連接CSS及JavaScript，並通過生成source map大大地簡化調試工作。配置完成後，webpack會監控代碼，每次代碼發生變化，它就會生成新的bundles。客戶端無需再導入大量的CSS或JS文件，而只需要導入bundles，減少了頁面載入時的HTTP請求數。此外，webpack還提供了大量的插件，例如，使用jsx-loader可以將JSX轉換成JavaScript，使用babel-loader可以將ES6代碼轉換成相容ES5的代碼。

· ES6： ECMAScript 2016，是JavaScript的最新規範，定義了若幹重要的新特性，比如胖箭頭函數、類、字元串插值、塊作用域等。更多信息，請查看Mozilla Developer Network上的ECMAScript 6參考指南。

WEB開發不應該這麼複雜

系統的設計團隊受其生產系統的約束，而生產系統又是根據設計團隊的溝通結構決定的。

----康威定律

康威定律說，軟體產品的結構就是其創造團隊的組織結構的鏡像。

    我們正在使用的客戶端渲染框架，來自於 Google 和 Facebook ，這兩家公司有數千開發者，這些開發者隸屬於數十個團隊，組織結構就像這樣 :

    你的團隊面臨的問題，很可能跟 Google 和 Facebook 所面臨的不一樣。使用那些客戶端框架時，我們是為了追逐性能，我們做的每個決定都是對的，但是放在一起看看結果，我們獲得了微小的性能提升，卻在工程方面花費了慘重的代價。如果繼續深入這條路，這條路就會變得越窄。

開發WebSite

    要說現在用React做網站設置繁瑣嗎？當然繁瑣，要設置eslint，babel，webpack，用boilerplate最終還是要瞭解各個不同的東西是幹嘛的，不過把這些歸罪React也不是太恰當，畢竟是整個前端生態圈都進化了。用Angular 2或者Ember你還是得用到這些。React的繁瑣基本都在redux上，得creatStore還得加入middleware還得用connect()連接到store，而帶來的高階組建的概念不好懂也不容易用。
     React有它自己的缺點，畢竟我們上哪找完美的東西呢？Boilerplate過多，setState是非同步的，context api很坑爹，server side render各種坑(設置hmr，哪些call在伺服器做，哪些只能在瀏覽器運行等等)，animation到現在都沒什麼太好的方案。

    不過React值得用嗎？當然值得，它給你組件化頁面，入門函數式，清晰的單向數據流(dispatch(action)->reducer->render)，深入了還有高階組件的compensability，能發現selector和reducer其實也是compostable的，順帶著各個工具的使用(eslint, babel, webpack)，不小心還能入Elm和Clojurescript的坑。
還有一個經常被提起的好處是React redux做的網站，重構非常方便，在需求永遠不固定的世界里也是一大優勢。

關於React的問題，有幾點要說：
1、React確實存在組件嵌套的性能問題，但是可以通過Redux去解耦以達到目的
2、對於引入immutable / reselect 對於大部分並不是必需品，組件粒度越細，state使用得越少，需要引入shouldComponentUpdate的情況越少，其實在項目中真正有用到它們的有多少呢？
3、React的中大型項目上的應用並不是太大的問題，國內有Ant.design已經在大量的螞蟻金融平臺和或各類內部平臺上使用，儘管Vue也有，但只是實驗版本，也並沒有再去升級。 在國外：faceBook算大型應用嗎？它本身已經就應用了React 16 Alpha 版本，以身試坑，這樣算得上 React 在大型應用上有問題嗎？
4、React是有門檻的，確實沒有Mv**那麼快讓人容易接受，需要有一定的JS基礎和開發經驗。

前後端分離

我們不適合 前後端分離, 為什麼？因為

1. 又增加了一個中間層（當然程式員通過增加中間層來解決問題），好處是有，職責明確；但是也有壞處：人為地拉長了戰線。對比圖一和圖三你就會發現，結構變複雜了，一個人能做的事情變成需要兩個人做了。

2. 並沒有實質變化。以前的後端結構也是存在調用 Service 邏輯的，現在只不過換成讓前端用 Node.js 做。除了把本來就吃緊的前端人力耗費在他不擅長的領域，我沒看到什麼提升。這裡唯一的好處就是前端是勢力範圍擴大了。

    認同的是「全棧工程師」。一個業務的前後為什麼要分給兩個人寫？以表單提交為例，後端要對數據做校驗，前端也要做。為什麼要讓兩個人都寫一次？前端說可以讓後端也寫 Node.js ，這樣就可以服用代碼了呀。後端寫了三年的 Java 你現在告訴他要全部重來？後端肯定不願意啊。矛盾就出在，分『後端』和『前端』兩個職位上。大公司細分後端和前端，也是可以理解的。

    說前後端分離的缺點：

1. 大部分站點，不應該分前後端。除非你的前端，非常非常非常複雜。但是大部分站點的前端，根本沒有那麼複雜！
2. 分了前後端很容易出現各自為政的情況。推諉、邀功、互相鄙視，不一一列舉了。
3. 有人問一個人怎麼又學後端又學前端？我的建議是把前端做薄，如果沒有必要，不要搞什麼 Angular 、 React 。用原生 JS 或者 jQuery 能滿足大部分網站。同時後端向 Rails 學習。局部交互複雜的地方，採用動態載入來做交互。
4. 有人說你是前端的叛徒，你這麼做前端還有什麼前途。

其實真正主題是：前後端分離是前端不得志的必然結局。

難道前後端分離沒有好處嗎？
只有一個好處：好招聘。畢竟你要招一個優秀的全棧工程師是極其困難的。

思路

1. 保持前端簡單，複雜了就用原生的方式封裝，具體來說就是用自定義標簽來封裝複雜組件。這樣一來，後端同事還是可以開發頁面，因為只是多了一個自定義標簽而已，本質還是 HTML
2. 儘量不要在開髮狀態加 watcher ，目的也是讓後端可以直接上手，不需要瞭解那麼多工具。轉譯放到 Web 框架的開發者模式裡面做，看到 less 請求加轉義成 CSS 不是什麼難事也不複雜。
3. 前端只是輔助（這裡說的是大多是網站，不包括重型 Web 應用），前端要做好服務化：健全的文檔、友好的介面。
4. 前端也要學後端知識，別在那自嗨。
5. 小公司別搞前後端分離，徒增複雜度！

單元測試

前後端分離後,意味著更多的業務邏輯將融入到前端程式中, 對應的我們需要前端工程師需要完成對應業務邏輯的單元測試, 以確保前端質量不會逐漸淪陷.

• 基於 JavaScript 的單元測試被證明是一種高效的測試方法，其中 71％ 的組織執行了 JavaScript 單元測試，而 84％ 的組織則相信它是有益的！
• Jasmine 和 Mocha 是最流行的 JavaScript 單元測試框架，Jasmine 主要配合 AngularJS 進行單元測試，而 Mocha 則與 ReactJS 配合使用。

目前前端自動化單元測試社區情況:

Jasmine & Protractor (72.4%),

Jasmine & Karma (67.7%),

Jasmine & Jest (58.3%),

Karma & Protractor (58.6%).

服務端

組件化是我們基礎設施之一, 服務端(.net, java)也想做更多通用組件.但往往項目或產品研發周期緊, 在一些組織沒有足夠時間研發通用組件.

權衡

我們更多的時候，更應該思考的是平衡和最優組合：

什麼情況下應該後臺渲染，什麼情況下應該前臺渲染。
什麼情況下應該用html+css控制頁面，什麼情況下應該用js控制頁面。

    React.js里所謂的“頁面組件”，並不是指一個checkbox，或一個input這樣細粒度的組件，可以理解為對一個“功能單一的一個頁面區域”的封裝，粒度更大。雖然checkbox等也需要封裝住成組件，但那是粒度更細Controls，和React.js的組件概念不是一個級別。 單純使用react而不搭配其他類庫是作死 真的還不如用jquery。

    工程化的需求也比前些年提高的無數倍，去年我用grunt，後來用gulp，然後browserify來了，2016年用webpack，babel，工具的更換意味著開發體驗也是越來越好。另外JSX不是HTML，JSX不是HTML，JSX不是HTML。

    React滿足上面的一些方面，不滿足另一些方面，和其他工具一樣。你需要React，是因為兩點

    第一， 你充分評估了你的項目，理解你要解決的問題是什麼，是快速開發，性能，團隊的ergonomics，多數情況下要解決的問題是多個要素的平衡

    第二， 你充分評估了React這個棧，理解它是解決你的具體問題的最佳工具，你真的理解了自己的場景中非用React不可的那些事情
   只是一個營銷類的推廣頁面，僅僅只有輪播、幾個文本框的表單的極淺交互，我還是推薦大伙使用原生 / zepto / jQuery之流。假如您很在意體積，計較網路環境（2G/3G）等，可以使用伺服器端渲染或者無阻塞UI（即添加占位符），使用帶有GZIP的CDN，React各類庫絕對能夠在100K以內，假如超過，建議您使用按需載入。我相信您的伺服器應該會添加有304/ETAG之類的緩存。

    對於中大型項目，React確實是優良之選，當然也可以嘗試Vue去迭代中小型項目。flux/reflux/redux 不僅僅只能用在React，也能用在Vue/Angular等等框架，僅僅只是一個數據流思想，您選擇性地使用。

    對於大型項目，推薦 Webpack 來構建業務代碼， Rollup 來打包你的小輪子。使用Rx優化你的數據流。Typescript強健你的代碼，提升你的開發效率（頭一周可能會有些痛苦）。但在此之後的收益是非常高的。 對於中小型項目，推薦React/Redux/React-Router來構建你的代碼

總結

   因為沒有完美的框架，只有適合的應用場景，選擇我們自己更適合的。
      框架都只是為了開發效率和良好地組織項目代碼，並不完全是為性能而生。 註意IT時代在變, 任何技術都會演進, 凡是存在的, 都是合理的。
       服務端研發工程師也少有全棧工程師。React.js適合長期, 用戶體驗高的交互多的項目或信息系統產品。

--------------------------------------------------------------------------------------------------------------------------------------------

今天先到這兒, 希望對您在團隊管理, 項目管理, 產品管理, 系統架構 有參考作用 , 您可能感興趣的文章:
前端工程師技能整理
精益IT組織與分享式領導
企業信息化與軟體工程的迷思
企業項目化管理介紹
軟體項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共用
高效能的團隊建設
項目管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
互聯網資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變

如有想瞭解更多軟體設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關註我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
該文章也同時發佈在我的獨立博客中-Petter Liu Blog。