React是UI的未來嗎?
作者 | Jani Ev?kallio
譯者 | 安翔
我們曾經認為太陽圍繞地球運行,把瘟疫看作神對人類的懲罰,而現在我們堅信 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


※每看完這一本書,就有一個「碼農」消失
※面對快速迭代的技術變化,開發者要如何才能跟上?
TAG:InfoQ |