[譯] 哪些項目需要 React？都需要！

<b>本文講的是[譯] 哪些項目需要 React？都需要！，</b>

簡而言之，Chris 提出了一系列使用 React（或其他類似的當代 JavaScript 庫）的優勢和劣勢。雖然我并不反對他的觀點，但我依然發現自己得出了不同的結論。

是以今天我想說的是，對于“項目什麼時候需要 React 架構”的答案不是“要看情況”，而是“任何時候”。

話雖如此，我的觀點也适用于任何提供 React 相同特性的其他庫。

如果你手裡隻有一把錘子， 所有東西看上去都像釘子。

這則諺語長久以來都被用于譴責一刀切看問題的人。

但我們假設有一段時間，你的确生活在布滿釘子的世界（聽起來有點起雞皮疙瘩），那麼你信任的錘子能夠解決你遇到的任何問題。

想想每次重複使用相同工具的好處：

無需花時間決定使用哪一個工具。

花更少的時間學習新工具。

擁有更多的時間來更好地揮舞你選擇的工具。

是以 React 會是這種工具嗎？我覺得它可能是的！

首先，我們來看看最常見的反對“一切皆 React”的觀點。我直接引用 Chris 原話：

舉個例子，一個部落格也許沒什麼複雜的邏輯，一點也不符合應該使用 React 架構的情況。既然在這種情況下 React 架構不是很合适，那麼在這用 React 架構就不是好的選擇。因為這麼做引入了複雜的技術，依賴了很多根本沒用到的東西。

說的很在理。一個簡單的部落格不需要 React。畢竟即使你需要一點 Javascript 處理系統資料庫單，你也可以僅僅使用 jQuery。

什麼？你需要在不同頁面的多個地方使用那個表單？還要隻在某些條件下才顯示？也要加上動畫？等等，打住…

我用這個小情景想表達的主旨就是複雜性并不是一個或是或非的問題，現代網站生活在一個連續的頻譜上，從靜态頁面一直到豐富的單頁應用。

是以可能現在你的項目正舒服地生活在“簡單”的這一頭，但這一路下去六個月後呢？與其陷入鴿子洞式的糟糕實踐，選擇一種留有成長空間的技術豈不更好？

過早優化是萬惡之源。

這是程式員中流行的另一則言語。畢竟，當膠帶就能做的很好的時候，誰會需要錘子和釘子呢！

但這裡做了一個假設就是“過早優化”是一個長期的少有成效的艱難過程。并且我覺得這個不适于 React。

事實上，也許更多的是因為 React 使用了非常強大的元件概念。就像 CSS 鼓勵你考慮可重用的類和樣式一樣，React 帶來了一個靈活的子產品化前端架構，從簡單的靜态首頁到互動式後端儀表闆，為每一個用例帶來好處。

我們生存在 JavaScript 的世界。就像 Chris 所說：

你通過 Node.js 建構服務端，也有很多項目可以通過 JavaScript 處理 CSS。現在通過 React 架構，你還可以在 JavaScript 裡寫 HTML。 萬物歸于 JavaScript！JavaScript 萬歲！

Chris 不是很相信，但我相信。JavaScript 本身并不一定完美，但能夠通路整個現代 NPM 生态系統太棒了。

過去安裝一個 jQuery 插件要找到它的官網，下載下傳下來，拷貝到你的項目目錄，加一個<code>&lt;script&gt;</code> 标簽，然後期望記得每過幾個月檢查一下新版本。現在，安裝和 React 包同樣的插件隻是 npm install 指令的問題。

相信我，一旦你習慣了那種全世界都在說的語言，那就很難再回歸到以前的方式了。

我知道你在想什麼：目前為止我一直在推銷 React 給開發者帶來的好處，卻小心翼翼的提及終端使用者的體驗。

并且這仍然是反對使用當代庫的關鍵論點：緩慢臃腫的 JavaScript 站點卻隻是為了顯示單個“奇迹淫巧”的廣告。

此外還有一個小秘密：你可以完全不引用 JavaScript 而獲得 React 的所有優勢！

概括一下，這是我認為 React 是任何項目的可行選擇的四個原因：

即使是最簡單的網站，也很難保證你永遠不會需要互動功能，如标簽、表單等。

React 基于元件的方式即使相比于基于内容的靜态站，也有巨大的優勢。

擁抱現代 JavaScript 生态系統是又一個巨大的優勢。

現代服務端渲染工具可以消除終端使用者使用 React 的劣勢。

是以 Chris，您覺得呢？我的觀點否足夠令人信服？還是您依然保持懷疑？

那麼你呢，親愛的讀者？你覺得像 Chris 所說每一個工具都有它的用處，還是同意我的觀點“錘子時間”就在眼前？評論起來讓我知道你們的觀點吧！

<b></b>

<b>原文釋出時間為：2017年5月10日</b>

<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>