前端迷思與React.js

時間 2019-11-10

標籤前端迷思 react.js react 欄目 React 简体版

原文原文鏈接

前端迷思與React.jsjavascript

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

開始吧:html

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

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

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

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

爲何須要 React,Why？

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

若是你以爲React是Facebook開發的因此須要，個人揣測是經歷過一個社區adoption的高峯之後，Facebook未必能解決剩下的那1%的問題。
若是你以爲React Native很火因此須要，這或許是一個理由，但RN也不是惟一選擇，從各方面評估，NativeScript這樣的棧並不比RN壞多少，也許還稍微好一點。若是是大預算的商業開發，RN甚至不該該成爲首選。react

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

1. 虛擬 DOMwebpack

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）算法。該過程可用於肯定出現變動的具體時間，並將變動傳遞給渲染器。

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的問題，有幾點要說：
一、React確實存在組件嵌套的性能問題，可是能夠經過Redux去解耦以達到目的
二、對於引入immutable / reselect 對於大部分並非必需品，組件粒度越細，state使用得越少，須要引入shouldComponentUpdate的狀況越少，其實在項目中真正有用到它們的有多少呢？
三、React的中大型項目上的應用並非太大的問題，國內有Ant.design已經在大量的螞蟻金融平臺和或各種內部平臺上使用，儘管Vue也有，但只是實驗版本，也並無再去升級。在國外：faceBook算大型應用嗎？它自己已經就應用了React 16 Alpha 版本，以身試坑，這樣算得上 React 在大型應用上有問題嗎？
四、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適合長期, 用戶體驗高的交互多的項目或信息系統產品。

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

原文做者：Petter Liu

原文出處：http://www.cnblogs.com/wintersun/