- 原文地址：Which Projects Need React? All Of Them!
- 原文作者：SACHA GREIF
- 譯文出自：掘金翻譯計劃
- 譯者：sunui
- 校對者：LeviDing、Shangbin Yang
專案什麼時候需要 React 框架呢？這是 Chris Coyier 在最近一篇博文中提出的問題。我是 Chris 部落格的粉絲，所以我好奇他要說什麼。
簡而言之，Chris 提出了一系列使用 React（或其他類似的當代 JavaScript 庫）的優勢和劣勢。雖然我並不反對他的觀點，但我依然發現自己得出了不同的結論。
所以今天我想說的是，對於“專案什麼時候需要 React 框架”的答案不是“要看情況”，而是“任何時候”。
React vs Vue vs Angular vs…
首先，說點題外話：在他的文章中，Chris 選擇 React 作為一般意義上“前端庫”的代表，那麼我也一樣。況且 React 是我維護的倉庫 VulcanJS（一個 React 和 GraphQL 框架）中最熟悉的東西。
話雖如此，我的觀點也適用於任何提供 React 相同特性的其他庫。
錘子的力量
如果你手裡只有一把錘子， 所有東西看上去都像釘子。
這則諺語長久以來都被用於譴責一刀切看問題的人。
但我們假設有一段時間，你的確生活在佈滿釘子的世界（聽起來有點起雞皮疙瘩），那麼你信任的錘子能夠解決你遇到的任何問題。
想想每次重複使用相同工具的好處：
- 無需花時間決定使用哪一個工具。
- 花更少的時間學習新工具。
- 擁有更多的時間來更好地揮舞你選擇的工具。
所以 React 會是這種工具嗎？我覺得它可能是的！
複雜度譜
首先，我們來看看最常見的反對“一切皆 React”的觀點。我直接引用 Chris 原話：
舉個例子，一個部落格也許沒什麼複雜的邏輯，一點也不符合應該使用 React 框架的情況。既然在這種情況下 React 框架不是很合適，那麼在這用 React 框架就不是好的選擇。因為這麼做引入了複雜的技術，依賴了很多根本沒用到的東西。
說的很在理。一個簡單的部落格不需要 React。畢竟即使你需要一點 Javascript 處理登錄檔單，你也可以僅僅使用 jQuery。
什麼？你需要在不同頁面的多個地方使用那個表單？還要只在某些條件下才顯示？也要加上動畫？等等，打住…
我用這個小情景想表達的主旨就是複雜性並不是一個或是或非的問題，現代網站生活在一個連續的頻譜上，從靜態頁面一直到豐富的單頁應用。
所以可能現在你的專案正舒服地生活在“簡單”的這一頭，但這一路下去六個月後呢？與其陷入鴿子洞式的糟糕實踐，選擇一種留有成長空間的技術豈不更好？
React 的優勢
過早優化是萬惡之源。
這是程式設計師中流行的另一則言語。畢竟，當膠帶就能做的很好的時候，誰會需要錘子和釘子呢！
但這裡做了一個假設就是“過早優化”是一個長期的少有成效的艱難過程。並且我覺得這個不適於 React。
雖然 React 需要一些時間來習慣，但一旦瞭解了其基本概念，您就能像使用傳統的前端工具一樣快速上手。
事實上，也許更多的是因為 React 使用了非常強大的元件概念。就像 CSS 鼓勵你考慮可重用的類和樣式一樣，React 帶來了一個靈活的模組化前端架構，從簡單的靜態主頁到互動式後端儀表板，為每一個用例帶來好處。
JavaScript， 隨處都是 JavaScript
我們生存在 JavaScript 的世界。就像 Chris 所說：
你通過 Node.js 構建服務端，也有很多專案可以通過 JavaScript 處理 CSS。現在通過 React 框架，你還可以在 JavaScript 裡寫 HTML。
萬物歸於 JavaScript！JavaScript 萬歲！
Chris 不是很相信，但我相信。JavaScript 本身並不一定完美，但能夠訪問整個現代 NPM 生態系統太棒了。
過去安裝一個 jQuery 外掛要找到它的官網，下載下來，拷貝到你的專案目錄，加一個 <script> 標籤，然後期望記得每過幾個月檢查一下新版本。現在，安裝和 React 包同樣的外掛只是 npm install 命令的問題。
使用像 styled-components 這樣的新庫，甚至 CSS 現在也被連帶著尖叫著進入未來。
相信我，一旦你習慣了那種全世界都在說的語言，那就很難再回歸到以前的方式了。
不會有人想到使用者！
我知道你在想什麼：目前為止我一直在推銷 React 給開發者帶來的好處，卻小心翼翼的提及終端使用者的體驗。
並且這仍然是反對使用當代庫的關鍵論點：緩慢臃腫的 JavaScript 站點卻只是為了顯示單個“奇蹟淫巧”的廣告。
此外還有一個小祕密：你可以完全不引用 JavaScript 而獲得 React 的所有優勢！
我想說的是在服務端渲染 React。事實上， 像 Gatsby（還有 Next.js 等等）這樣的工具可以把你的 React 組建編譯進靜態 HTML 檔案中，這樣你可以託管在 GitHub pages 上面。
舉個例子，我自己的個人站點 就是一個 Gatsby-generated React 應用，沒有載入任何的 JavaScript（除了一個 Google Analytics 片段）。 我在開發中發揮了 React 的所有優勢（全 JavaScript，擁抱 NPM 生態，styled-components 等），而最終得到了純 HTML 和 CSS 的最終產品。
總結
概括一下，這是我認為 React 是任何專案的可行選擇的四個原因：
- 即使是最簡單的網站，也很難保證你永遠不會需要互動功能，如標籤、表單等。
- React 基於元件的方式即使相比於基於內容的靜態站，也有巨大的優勢。
- 擁抱現代 JavaScript 生態系統是又一個巨大的優勢。
- 現代服務端渲染工具可以消除終端使用者使用 React 的劣勢。
所以 Chris，您覺得呢？我的觀點否足夠令人信服？還是您依然保持懷疑？
那麼你呢，親愛的讀者？你覺得像 Chris 所說每一個工具都有它的用處，還是同意我的觀點“錘子時間”就在眼前？評論起來讓我知道你們的觀點吧！
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃。