為什麼我從 AngularJS 切換到 React
已發表: 2022-03-112011 年，當我的代碼開始混雜 jQuery 選擇器和回調時，AngularJS 成為了救命稻草，它有助於更好地管理、快速開發和更多開箱即用的功能。 AngularJS 的雙向綁定和“模型作為單一事實來源”的理念讓我大吃一驚，並減少了整個應用程序中的數據冗餘。
然而，隨著時間的推移，我發現 AngularJS 也有它自己的一些痛點。 最終，這些讓我感到非常沮喪，以至於我開始四處尋找替代解決方案。
AngularJS 1.x 中的痛點
用於執行的 DOM
Angular 的執行流程嚴重依賴 DOM。 在應用程序的默認引導中，它會掃描 DOM 並使用指令優先級對其進行編譯，這使得調試和測試執行順序變得困難。
它自己的依賴注入
JavaScript 沒有自己的包管理器和依賴解析器。 但最近，AMD、UMD 和 CommonJS 等實現已經很好地解決了這個問題。 遺憾的是，AngularJS 並沒有派上用場。 相反，它引入了自己的依賴注入 (DI)。 儘管有使用 RequireJS 的非官方 AngularJS DI 實現。
雙向綁定是一把雙刃劍
使用雙向綁定很誘人，但是隨著組件複雜性的增加，它可能會導致性能災難。
雙向綁定如何影響性能？ 好吧，JavaScript ES5 沒有任何實現來通知其變量或對象的任何更改，因此 Angular 使用稱為“臟檢查”的東西來跟踪數據更改並將其與 UI 同步。 在 Angular 的範圍（$digest 循環）內執行任何操作之後執行臟檢查，這會隨著綁定數量的增加而導致性能下降。
雙向綁定的另一個問題是頁面上的許多不同組件都能夠更改數據，從而導致數據輸入的多個來源。 如果處理不好，可能會導致模棱兩可的情況。 但公平地說，這純粹是一個實施問題。
Angular 有自己的世界
Angular 中的每個操作都必須經過其摘要周期，否則您的組件將無法與您的數據模型同步。 因此，如果您使用任何第三方現有的 JavaScript 庫，如果它涉及數據更改，則需要使用 Angular 的 $apply 函數包裝它，或者如果它是實用程序庫，則需要將其轉換為服務。 這就像為 Angular 重新發明每個可用的 JavaScript 模塊。
太多的概念和陡峭的學習曲線
學習 Angular 需要學習大量的概念，包括模塊、控制器、指令、範圍、模板、鏈接函數、過濾器和依賴注入。
認識反應
React 是來自 Facebook 和 Instagram 的新開源 JS 庫，是編寫 JavaScript 應用程序的另一種方式。 當它在 2013 年 5 月的 JSConf EU 上推出時，觀眾對其“單向數據流”和“虛擬 DOM”等一些設計原則感到震驚。
React 官方網站說，“React 是一個用於構建用戶界面的 JavaScript 庫”，是的，只有界面，沒有別的。 它不是像 AngularJS 這樣的框架。 但是您可以編寫或多或少與 Angular 指令相比較的自包含組件。 快速概覽
React 重新思考了 Web 開發中的最佳實踐。 Reach 鼓勵單向數據流，並相信組件是由數據驅動的狀態機的理念。 儘管大多數其他框架都喜歡使用 DOM 並直接操作它，但 React 討厭 DOM 並努力保護開發人員免受它的影響。 React 僅提供定義任何 UI 組件所需的基本 API，沒有其他任何東西。 達遵循 UNIX 理念：小而美。 做一件事並做到最好。
這是Pete Hunt（來自Instagram團隊）對兩者進行的非常好的比較
它只是一個圖書館。 我們需要一個帶有 React 的框架嗎？
簡短的回答：您的選擇。
使用 React，您可以構建用戶界面，但我們仍然需要管理依賴項、進行 AJAX 調用、應用數據過濾器。 如果我們確實需要一個框架，為什麼要拋棄 AngularJS？
框架是一組包和一組規則。 如果我不需要一些包，或者想換另一個包怎麼辦。 我該怎麼做？ 我們需要一個包管理器。 我們如何在 AngularJS 中管理包？ 這是你的選擇，但 Angular 有它自己的世界。 您需要將每個外部包包裝到 Angular 的世界中，然後使用它。 但是 React 只是 JavaScript，任何用 JavaScript 編寫的包都不需要在 React 中進行任何包裝。
所以，如果我們從像 npm 這樣的包存儲庫中選擇我們自己的包並按照我們喜歡的方式組織它們會更好。 好消息是 React 鼓勵使用 npm，它有很多現成的包。 要開始使用 React，您可能希望使用這些全棧入門工具包之一
反應的優點
那麼為什麼我真的切換到 React 呢？
反應速度很快！
React 採用與其他框架不同的方法。 它不允許您直接使用 DOM。 相反，它在 JavaScript 邏輯和實際 DOM 之間引入了一層虛擬 DOM。 這有助於大大提高速度。 在連續渲染時，React 對虛擬 DOM 執行差異化，並僅更新需要更新的真實 DOM 部分。
Virtual DOM 還有助於解決跨瀏覽器問題，因為它提供了一個統一的跨瀏覽器 API，甚至可以在 Internet Explorer 8 中使用。（呸！）
一切都是組件（UI 小部件）
編寫自包含的 UI 組件可將您的應用程序模塊化並分離每個關注點。 每個組件都可以單獨開發和測試，然後使用其他組件來提高可維護性。
單向數據流為贏！
Flux 是一種用於在 JavaScript 應用程序中創建單向數據層的架構。 它是在 Facebook 與 React 視圖庫一起設計的。 它使開發更簡單，更容易追踪和修復錯誤。 Flux 更多的是一個概念，而不是一個實現。 它也可以在其他框架中實現。 Alex Rattray 在 React 中使用 Backbone Collection 和 Model 實現了一個非常好的 Flux。
JavaScript，僅此而已
現代 Web 應用程序的工作方式與傳統 Web 不同。 視圖層需要在不影響服務器的情況下通過用戶交互進行更新。 因此 View 和 Controller 需要相互依賴。 許多其他框架使用 Handlebars 和 Mustache 等模板引擎作為其視圖層，但 React 認為這兩個部分是如此相互依賴，以至於它們必須駐留在一個地方，而不使用任何第三方模板引擎，並且不離開JavaScript。
同構 JavaScript
單頁 JavaScript Web 應用程序的最大缺點是它在被搜索引擎抓取時有限制。 React 有一個解決方案。 React 可以在將應用程序發送到瀏覽器之前在服務器上預渲染應用程序，它還可以從服務器預渲染的靜態內容將相同的狀態恢復到實時應用程序中。 由於搜索引擎爬蟲嚴重依賴服務器響應而不是 JavaScript 執行，因此預渲染此類應用程序有助於搜索引擎優化。
React 與 RequireJS、Browserify 和 Webpack 配合得很好
在構建大型應用程序時，非常需要加載器和捆綁器。 不幸的是，當前版本的 JavaScript 沒有提供模塊捆綁器或加載器，儘管它在即將發布的 EcmaScript 6 (System.import) 版本中提出。 幸運的是，我們有一些替代品，例如 RequireJS 和 Webpack，它們非常不錯。
React 是使用 Browserify 構建的，但如果您希望注入圖像資源並編譯 LESS 或 CoffeeScript，那麼 Webpack 可能是更好的選擇。
我有些痛苦地切換到了 React。
由於 AngularJS 是一個框架，它附帶了很多好東西，其中包括 $http 服務中的 AJAX 包裝器、作為承諾服務的 $q、ng-show、ng-hide、ng-class 和 ng-if 作為控制語句為模板。
React 不是一個框架，而是一個用於構建 UI 的庫，因此您需要自己考慮所有其他部分。 我正在開發一個可以與 React 一起使用以簡化開發的開源項目，並且社區也在積極貢獻類似的可重用組件。
React-components.com 是一個非官方的目錄網站，您可以在其中找到此類開源組件。
React 的理念不鼓勵您使用雙向綁定，這在處理表單元素和可編輯數據網格時會帶來很多痛苦。 但是，當您開始了解 Flux 數據流和 Store 時，事情會變得更加清晰、簡單和容易。
React 是新的，因此社區需要一些時間來發展。
Angular 近來非常受歡迎，並且有大量可用的擴展，如 AngularUI 和 Restangular。 React 的開源社區是新的，但它正在快速增長，並帶有 React Bootstrap 之類的擴展。 我們擁有更多可用組件只是時間問題，並且 React 可以輕鬆用於快速 Web 應用程序開發。
結論
如果你以前用過 AngularJS，那麼你一開始可能會討厭 React，主要是因為它是單向的數據流，並且缺乏你需要自己處理許多其他事情的“框架”。 但是一旦你熟悉了 Flux 設計模式和 React 的哲學，你就會意識到它的美妙之處。
Facebook 和 Instagram 都使用 React。 Github 的新 Atom 編輯器是使用 React 構建的。 即將推出的 Yahoo Mail 正在 React 中重新構建。 您還需要哪些示例？ 今天就試試 React。