Categories
程式開發

React過譽了嗎?


React過譽了嗎?拋開和Facebook的關係,它確實有“兩把刷子“嗎?

今年年初,我抱著誠懇的態度嘗試了一下React。我自己以前是Angular用戶,所以在嘗試的過程中對這個庫所展示的理念一直抱有開放的態度。

剛開始用React的感覺很奇怪——這個世界裡的所有事物都要以一種特殊的方式來構造,其中需要用自動化處理程序來處理數據流。涉及到數據時,React總有自己的一套強制單向數據流機制。

但這些並不是我放棄React的原因——是社區中那些玻璃心的狂熱信徒讓我受不了的。也許是因為我的Angular用戶背景,我會仔細觀察,在兩者間做出許多對比,結果引來了這幫人(他們大部分只會用React),氣勢洶洶地要找我較量。有那麼幾個月他們贏了,我撤退到了自己安全的Angular世界裡。但是最近,我有機會在工作中用上了React Native,所以想寫一寫自己對這個話題的誠實看法。

這是一個庫

React是一個庫——而庫必須與其他庫搭配使用才能解決特定問題。 React的問題解決能力主要體現在渲染前端界面和管理經常變化的數據上。

React的優勢在於單向數據流,在面對突變和意外繼承時可以確保高度穩定性和可預測性。 React非常討人喜歡的另一個因素是它處理關注點分離的方式。它顛覆了傳統的筒倉(silo)方法,也就是將CSS、JavaScript和HTML分離成單獨的文檔文件,並將它們放在同一個空間中以備處理。

React過譽了嗎? 1

以Angular為例,傳統的處理關注點分離的方式。

React過譽了嗎? 2

需要新事物時的處理方式。這種結構不是Angular特有的。

React過譽了嗎? 3

React中基於關係的關注點分離方式。

從理論上講,在Angular中也可以實現基於關係的關注點分離,但不會像React中那樣是默認方法,也沒那麼直觀。

React之所以能實現這一目標,是因為其原則是代碼組件都要維持在足夠小的體積上,從而使這些組件的域和邊界都易於檢測和理解。但這不是硬性規定,組件的最終大小是由開發者確定的。

回歸本源

React的流行主要是因為市面上缺少像樣的起步架構,人們很需要這種架構來上手。 React與Angular是不一樣的,在Angular中需要用CLI來為框架生成必要的設置,而React需要的準備工作非常少。

但很多人在對比它們的時候都會犯一個錯誤。 React是一個庫,這意味著它體積很小,功能專一,且有針對性。但Angular是一個框架,這意味著它是符合同一套規則的一系列庫的集合。因此,說Angular臃腫是不公平的,因為它倆並不是同一類事物。

框架決定了開發代碼的方式,並充當所有關聯庫的協調者。它根據一組原則或規則確保所有部分均按預期工作。這是必要的,因為當你有多個庫需要搭配使用時,為了讓程序平穩運行,你需要有某種共同的基礎。

React不是乾這個的。

它從來都不是為這個目標設計的——因為它的唯一目的就是將事物渲染到屏幕上,並讓你的數據以乾淨的方式連接到DOM。這就是為什麼要將狀態管理委派給Redux的原因。如果你想做的事情不只是處理數據和DOM,就需要找第三方應用程序來解決問題。

這也沒錯。這就是React的機制,這就是React的用途所在。

不能因為它易用,就說它更好

Angular與React的爭論似乎持續了很長時間。但這本質上不是誰更好的問題,而是誰更適合你開發需求的問題。

我看到很多人最後都會拿出來的論點,就是說React是由Facebook創造的。但並不是所有事情上Facebook的出身都有那麼大的意義。是的,它是由Facebook創造的,但React也不是他們唯一使用的技術。在他們的後端,也許還有前端,還有其他很多東西。

如果我們要談出身,那麼Angular與Google有關,Java來自Oracle,.Net還是Microsoft的心血呢。

需要承認,React比Angular更容易上手——特別是對於開發新手來說,他們對前端代碼並沒有清晰的認識。他們可能是自學成才的,或者可能是其他領域經驗豐富的工程師轉型過來的。不管用戶是什麼水平,React都像是JavaScript剛誕生時的樣子——上手很簡單,但是用法幾乎沒什麼限制。

React作為一個庫所面臨的問題是沒有結構上的約束——只有語法的約束。這可能導致應用結構鬆散,缺乏命名約定,文件夾結構(如果有這種東西)隨意混亂,生產部署中還可能打包進去很多冗余文件。

從理論上講,如果你不遵守那些最佳的編程方式,那麼做出來的任何事物都可能落得這樣的下場。可是這些最佳方法並沒有在代碼中通過約束固定下來。

你要了解JavaScript,還有其他知識

React是JSX,它是JavaScript的一種變體,這意味著你仍然需要了解JavaScript的實際機制。 React可能比Angular更接近JavaScript,Angular在結構上更像是通過TypeScript實現類型轉換和控件的傳統編程語言。

這就是為什麼你需要對JavaScript的機制有深入的了解,才能成為一名高水平、高效率的React開發人員。你需要深入研究的還有其他一些事物,其中包括狀態和數據流的概念——因為這是React所打交道,並且優勢很大的兩大主題。

一旦你從菜鳥階段成長起來,架構模式和結構就變得越來越重要。做電商應用時,你不能把整個銷售系統,包括單品推薦、交叉推薦和歷史購買推薦的代碼都塞進根文件夾裡面。

React的入門教程並不會教這些內容。實際上,大多數在線編程教程並沒有認真去講架構,也不會教你如何實現與框架或庫相關的元事物。

https://medium.com/better-programming/a-comprehensive-guide-on-the-meta-knowledge-you-need-to-accelerate-your-code-creation-process-d0f5f3b67473

雖然代碼編譯後就沒人能看到這些東西了,但是你的開發同事或接手你代碼的人是會看到的——如果你的代碼一團糟,改起來要人命,他們會發瘋的。

React的優點

React作為一個庫,意味著具有高度可移植性。你隨便把它放在哪裡都能正常工作——就像jQuery和Ajax那樣。有時我們需要做微前端,抑或是處理一些和舊式系統有著密切聯繫的過渡型應用,這時React的可移植優勢就非常有用了。

它與React Native的關係也是一個優點,它們改變了漸進式Web應用的製作方式。與其他基於JavaScript的框架(例如Ionic)不同的是,Ionic基本上就是打包你的Angular、Vue或React代碼以生成能發佈到商店的應用,而React Native則更進一步,會將代碼轉換為蘋果和谷歌要求的原生語言。

因此,React Native不會把網站偽裝成應用程序,而是將其轉變為實際的應用程序——從而提供更好的整體性能,以及更好的途徑來訪問設備上的原生功能(如地圖、指南針、圖像和相機等)。代碼本身還是以React為主,但是變成了適應各種移動設備的React版本。

React煩人的部分

作為從Angular住民踏入React世界的用戶,我最煩React的事情之一,就是它缺乏很多常用功能,例如自動數據綁定等。而且為了給它開路,你得找來幾乎所有基於JavaScript的庫才行。作為對比,Angular這邊你只要選一個已經打包進Angular的可用庫即可。你只要記得導入它,然後就萬事大吉!一切都很順利,很正常。但React很大程度上要依賴第三方庫,這些庫可能彼此之間看不對眼,或者不能很好地與React搭配工作。

在React社區中,關於組件設計和組件組織的討論也很少——或者只是我沒找對地方?隨著項目的發展,你經常會發現自己毫無必要地把狀態推到樹上面去了,結果在全局空間造成了意外的污染。一般會用Redux來解決這個問題——但是Redux並不是React,前者是一個完全獨立的實體。

結 語

先聲明一下,這些都只是我個人的看法,都是基於我對這個庫已有的經驗。總的來說,React的社區非常棒,但我在其中遇到的一些敵意在Angular世界中並不那麼常見。

那麼React被過譽了嗎?

這實際上取決於你要與哪些圈子的粉絲打交道,而且什麼事物都有自己的怪癖。 React並不是前端解決方案的終極聖杯,但它已經做得夠好了,所以非常有用。

當我也成長為老一代開發者,看過了那麼多項目花開花謝,我再學習新技術時就不會把它們當成已有事物的終極解決方案了,而只會把它們看作是升級更新,並加入到我自己的知識庫裡。

React本身也不是全新的東西。它只是將JavaScript、HTML和CSS打包在一起的另一種途徑。 Angular剛出來的時候用的也是這種方法,之前的jQuery也一樣。

業界永遠都在追捧下一個熱點,但最佳方法就是學習如何正確地編寫代碼,然後把這件事做好即可——因為不管現在的熱點是什麼框架、庫、支架之類花哨的東西,都是無關緊要的。作為開發人員,你的水平取決於你能以多快的速度,憑藉良好的編程基礎來適應當前的需求和環境。

感謝你的閱讀。

原文鏈接:
https://medium.com/better-programming/is-react-overrated-c7f8efb75e3e

相關文章:

React vs Angular vs Vue.js——2019 該選誰? (更新版)
React 的未來:與 Suspense 共舞
Angular 重大版本升級: 8.0 正式發布! 支持更多 Web 標準
Angular 9 即將發布:改進 Ivy 編譯和渲染管道