(分享)為什麼說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