為什么說React是UI的未來

我們曾經認為太陽圍繞地球運行，把瘟疫看作神對人類的懲罰，而現在我們堅信MVC架構和雙向數據綁定就是構建Web UI程序的最佳方式。

過去，人們沒有更好的方式來探尋這個世界，由于認知的局限，人們對這些“誤解”深信不疑。

最終，天文學家證明了日心說，醫生發現疾病是由細菌引起的。類似的，React引入了單向數據流的概念。

這些發現都沒有立刻得到大眾認可。伽利略的理論被認定為異端邪說。Semmelweis 博士發現疾病源于細菌，然而同事不接受他的這一研究成果，最后遺憾的在一庇護所中含恨而終。而如今，我們仍然誤認為所有的UI架構都是平等的。

我堅信React，或者類似的東西，將是用戶界面開發的未來。此刻，希望你不要立刻跳到文章末尾表達贊同或者反對意見，請先耐心看完文章正文，我會告訴你我這么認為的理由。

React的視野更為廣闊

React是一個由聰明人創造的聰明想法的集合。當React首次公布時，主要的賣點在于它的渲染方式：如果將應用程序結構與底層渲染DOM分開，我們可以實現聲明式的視圖渲染語法，同時仍然能夠應用最優的DOM突變。

它的思想別具一格，比如，它認為通過將代碼分離為HTML、JavaScript和CSS來跨越技術邊界的方法并沒有實質性的效果。React認為，為了創建具有高內聚和低耦合的程序，我們最好將UI的呈現、行為和狀態放在一個JavaScript文件里。這種方法為開發人員帶來了阻礙，那就是在普通的JavaScript中難以創建UI。鑒于此，React附帶了一個名為JSX的擴展語法。

很多開發者非常討厭JSX擴展語法。如果你不是Web前端開發人員，也許很難理解開發者為什么會對擴展語法充滿排斥情緒。

? ?

React發布時激起了熱烈的討論

沒有人愿意看到自己深信不疑的東西被否定，這是人的天性。因此，在高速發展的前端領域，React的核心價值經常被忽略。

React是一個組件平臺

React的核心在于它的組件。虛擬DOM是一項很酷的技術，但它只是一個實現細節，如果React不需要它也可創建，那它也就沒有存在的必要。JSX是一項不錯的技術，但它只是語法糖。

如今，組件已經是一個非常成熟的概念了，它在React之前就已經存在。當React發布時，Web組件規范早已標準化。就像伽利略并非第一個發現日心說的人一樣，組件也不是React發明的，React只是重新定義了它。

React組件的優點主要在于它的可組合性和封裝性。其次是它的函數組件和多用途。下面我將對其進行詳細說明：

• 可組合性 使我們能夠使用多個小的程序來組件一個大的程序，這些小程序使用的模板并不依賴其他組件，代碼可以獨立于系統中的其他代碼進行自由修改、刪除和替換，甚至可以在未來的代碼存在之前編寫。
• 封裝 包含組件的整個表現、行為和狀態。這意味著外部代碼不能影響其行為，除非包裝成了一個組件。
• 函數式 風格的編程接收Props進行渲染，這使得React組件更加健壯，它們的行為易于記錄和理解，從而使得開發人員能夠使用其他人開發的組件，而無需了解其工作原理。
• 多用途 意為組件既可以是負責數據和行為的容器組件（控制器），也可以是呈現組件的視圖。這種分離的方式一直是MV *體系結構的關鍵，而優雅的React組件API可以在保留可組合性和封裝性的同時，實現真正的分離。

這種小巧且集中的組件抽象方式提供了開發者需要的所有特性，比如：易于學習和記憶，更好的用戶使用體驗，并且能夠生成便于維護和協作的程序。

還有一個我沒提到的組件，事實上，這是最重要的組件。

組件是創新原語

雖然我是React的忠實支持者，但我不得不承認React并不完美；React核心團隊正在積極對其進行優化，一些新的想法在不斷討論、實施和丟棄。雖然目前React的生態系統很強大，包含了大量的庫、模式和多種實踐，但它依然有提升空間。我們甚至不能確定是否需要高階組件、渲染Props、函數式Props、或者 組件的組件 ！

雖然豐富的選項有時會令人疲倦，但這正是React組件模型的真正優勢所在。有了通用的、小型的、可組合的、靈活可靠的構建模塊，我們就可以在不丟棄現有工作的情況下討論、測試和接受新的想法。

遍布世界各地的個人開發者構建了像 Redux 、 Apollo 或 樣式化組件 這樣革命性的庫，應用開發者可以將這些新工具與現有工具一起使用，而無需修改現有的代碼，并且可以不影響其他模塊的情況下單獨替換某些特定的模塊，這都令我難以置信。

這些庫各自都在React領域之外實現了復雜的功能，但他們卻沒有相互限制，因為這些工具都可以利用組件組合模型。 因此，React組件模型不僅僅是一個UI原語，它是一個創新原語。

與漸進式JavaScript的不同之處在于，React采用新工具時不必重構大量的代碼。與Ember或者Angular這樣的整體型框架不同，React具有足夠的靈活性來應對不可避免的變化。

變化不可避免

平臺應當能夠適應變化，這一點非常重要，因為 變革總是不可避免并且代價高昂。

聰明人不會突然停止對問題的觀察，并為其提出解決方案。人們不會停止對存在的限制感到沮喪，并且不會停止對自由的追求。作為開發者，發現更好的工具時，我們也不會強忍著不去使用。無論你多想保持現狀，歷史的車輪總是滾滾向前。

當改變發生時，一個系統最理想的狀態是它能夠適應變化，如果完全替換代價將非常巨大。

在過去十年的框架戰之后，我們現在生活在前所未有的繁榮與和平時期。React等工具使我們能夠構建和維護杰出的產品。

如果我們的工具阻礙了進步，我們必須保持前進而不得不放棄它們。革命的代價是毀滅現有：我們將不得不更換所有的庫，重新認識新方法，重新培訓我們的團隊，重復我們的錯誤，改寫或重構大量的代碼，而不是專注于我們正在創造的產品。

革命無法抗拒

創新的階段分為兩部分：

- 快速改革的爆發期

- 緩慢增長的長尾期

? ?

革命期增長迅速，細化階段增速平緩。

React是一場革命。它推翻了當前的最佳實踐，幾乎在一夜之間對開發人員體驗方面進行了重大改進。目前我們正在快速進行迭代，我們對這種快速的創新已經習以為常，但是不久之后，創新的速度將會趨于平緩。

但曲線并不會真正決定創新的速率。只要我們保持創造活力和創新精神，同時開發者積極做決策，我們的生態系統依然能夠快速變化。

讓我們編寫軟件積極應對變化

無論我們是在React生態系統內部使用其他框架，構建無框架的漸進式Web應用程序，還是根本不構建與Web平臺相關的軟件，我們都可以從React及其生態系統中學習這些經驗教訓，能夠靈活應對變化而不需要顛覆現有的代碼。

• 用小模塊來構建大系統： 使用多個小巧的特定功能單元來構建軟件，盡量避免使用整體性的架構。設計API和接口時要仔細考慮，方便他人使用。
• 讓代碼易于復制和刪除，而不容易更改 ： 相比于繼承和混入最好使用組合。把行為進行封裝。把一件事做好。
• 優先為人而不是機器編寫代碼： 讓代碼變得更好理解。編寫代碼時盡量意圖簡單明了，不要過于學術。做到命名準確，書寫必要的文檔，保證代碼規范，方便他人使用。
• 密切使用編程語言： React能夠利用新的JavaScript語言功能和生態系統工具，因為它只使用JavaScript而已，雖然它有一套JSX語法。避免使用基于字符串的DSL和非慣用接口，因為這會降低兼容性。
• 除非逼不得已，否則不要打破現有狀態?： 穩定性本身就是一種價值，因為改變會導致額外的工作和浪費產生，或者在最糟糕的情況下，甚至會發生諸如廢棄AngularJS這樣的結局。要么最初就更換技術方案，否則最好不要在中途進行替換，使用 代碼模塊 或類似的工具來適應變化。在你自己的代碼中，不要僅僅為了它而采用新的庫，請充分衡量成本與收益。
• 保持開放的態度： 如果遵循了前面的規則，那么最后這一條也是必然的。有時候，新的想法也許讓人恐懼，變化可能會帶來不便，但革命總是偶爾會發生。不要太過一成不變，保持開放的態度，聽取人們的意見。

React是開發者的福音

UI領域技術更迭非常之快，簡直變幻莫測，我相信React會是UI的終極選擇。

雖然我個人并未重視虛擬DOM，但它已被證明是React最具前景的功能之一。由于虛擬表現層和UI實現層的分離，React非常適合服務器端渲染和通用Web應用程序。原生移動平臺是用戶界面開發中難以忽略的一部分； React Native 正好可以在該領域為我們提供大力幫助， recoil 讓React在Kotlin和Swift中都大有可為。 ReasonML 和 ReasonReact 可以幫助我們將React范例擴展到JavaScript之外的平臺。隨著未來增強和虛擬現實技術的蓬勃發展，我希望 React VR 和其他類似的實驗可以幫助我們預測風暴。

最終，React將被其他東西取代。我們還不知道強制函數會是什么，也許是WebAssembly，我們不知道接下來會發生什么。不管怎樣，我都會懷以激動的心情期待它。

就目前而言，由于React的強大存在，我相信短時間內UI領域會保持專一、穩定并欣欣向榮。

原文鏈接： https://medium.com/@jevakallio/the-present-future-of-user-interface-development-ebd371255175

感謝覃云對本文的審校。

 

來自：http://www.infoq.com/cn/articles/the-present-future-of-user-interface-development