今年年初，我抱著誠懇的態度嘗試了一下 React。我自己以前是 Angular 用戶，所以在嘗試的過程中對這個庫所展示的理念一直抱有開放的態度。
剛開始用 React 的感覺很奇怪——這個世界里的所有事物都要以一種特殊的方式來構造，其中需要用自動化處理程序來處理數據流。涉及到數據時，React 總有自己的一套強制單向數據流機制。
但這些并不是我放棄 React 的原因——是社區中那些玻璃心的狂熱信徒讓我受不了的。也許是因為我的 Angular 用戶背景，我會仔細觀察，在兩者間做出許多對比，結果引來了這幫人（他們大部分只會用 React），氣勢洶洶地要找我較量。有那么幾個月他們贏了，我撤退到了自己安全的 Angular 世界里。但是最近，我有機會在工作中用上了 React Native，所以想寫一寫自己對這個話題的誠實看法。
React 是一個庫——而庫必須與其他庫搭配使用才能解決特定問題。React 的問題解決能力主要體現在渲染前端界面和管理經常變化的數據上。
React 的優勢在于單向數據流，在面對突變和意外繼承時可以確保高度穩定性和可預測性。React 非常討人喜歡的另一個因素是它處理關注點分離的方式。它顛覆了傳統的筒倉（silo）方法，也就是將 CSS、JavaScript 和 HTML 分離成單獨的文檔文件，并將它們放在同一個空間中以備處理。
從理論上講，在 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 作為一個庫所面臨的問題是沒有結構上的約束——只有語法的約束。這可能導致應用結構松散，缺乏命名約定，文件夾結構（如果有這種東西）隨意混亂，生產部署中還可能打包進去很多冗余文件。
從理論上講，如果你不遵守那些最佳的編程方式，那么做出來的任何事物都可能落得這樣的下場。可是這些最佳方法并沒有在代碼中通過約束固定下來。
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 作為一個庫，意味著具有高度可移植性。你隨便把它放在哪里都能正常工作——就像 jQuery 和 Ajax 那樣。有時我們需要做微前端，抑或是處理一些和舊式系統有著密切聯系的過渡型應用，這時 React 的可移植優勢就非常有用了。
它與 React Native 的關系也是一個優點，它們改變了漸進式 Web 應用的制作方式。與其他基于 JavaScript 的框架（例如 Ionic）不同的是，Ionic 基本上就是打包你的 Angular、Vue 或 React 代碼以生成能發布到商店的應用，而 React Native 則更進一步，會將代碼轉換為蘋果和谷歌要求的原生語言。
因此，React Native 不會把網站偽裝成應用程序，而是將其轉變為實際的應用程序——從而提供更好的整體性能，以及更好的途徑來訪問設備上的原生功能（如地圖、指南針、圖像和相機等）。代碼本身還是以 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
