React 紀錄片心得 2 — 社群驅動創新

2023年2月11日

💎 加入 E+ 成長計畫 與超過 500+ 位軟體工程師一同在社群中成長,並且獲得更多的軟體工程學習資源

《React 紀錄片心得 1 — 重新思考最佳實踐》 一文中談到,React 在剛發表時,不論在 Facebook 內部,或是在 JavaScript 的開源社群,都曾受到反彈。然而十年過去的今天,React 是如何從過街老鼠轉身華麗成為前端社群中最多人用的開源套件之一? 本篇我們將會繼續 《React.js: The Documentary》的第二部分摘要與心得。

早期採用者出現

雖然在 JSConf 發表後,幾乎整個 JavaScript 社群都在唾棄 React,當時仍是有一小部分的人,對於 React 提出的新的思考方式感到有興趣。那時在 Khan Academy 工作的 Sophie Alpert,因為 Khan Academy 的網站遇到了開發上的瓶頸,而 React 這種以元件出發的思考方式,正好可以解決那些問題,於是她著手嘗試用 React 改寫程式碼。

用 React 重寫後,程式碼變得更易讀也更好維護,她也將該程式碼部署到生產環境中,這成為第一個 Facebook 之外把 React 程式碼部署到生產環境的企業案例。在那之後,Sophie 也開始貢獻到 React 的開源之中,包含幫忙修 React 的 bug、幫忙寫文檔,以及回答社群中其他人的提問。

因為有 Facebook 以外的人把 React 程式碼部署到生產環境,讓本來失去希望的 React 團隊重新開始有了信心,開始相信不是 React 不好,而是沒有足夠好的溝通,讓社群中的人理解 React 的好。這層理解讓 React 團隊開始專注在對外的溝通與文檔的撰寫。

到了 2013 年底,JavaScript 社群中有另一場盛會 — JSConf EU。有了前一次在 JSConf 的慘痛經驗,當時 React 團隊中沒有人想再去 JSConf 分享,但因為 Facebook 有贊助 JSConf,所以需要有人上去分享,在沒人想當講者的狀況下,Pete Hunt 自願當分享的講者。當時的那個演講,是後來很有名的《React: Rethinking best practices》。

在這個短講中,Pete Hunt 強調 React 的不同之處,強調為什麼 React 是個有趣的專案,這引起了一些人的興趣,社群中的回應也開始有了反轉。舉例來說,在函式編程社群中小有名氣的 Brandon Bloom,看到 React 以函式編程的思考模式重新看 UI 的開發,讓他在 Twitter 上自主為 React 做宣傳。

而在這些社群聲援中,David Nolen 寫的 《The Future of JavaScript MVCs》 一文受到了廣大迴響,大家開始體認到 React 帶來的好處,讓社群中多數人的想法從「我這輩子絕對不會用 React」轉變成「也許我該試試看 React」。

科技巨頭採用 React

時間推移到 2014 年,那時開始有更多公司使用 React,甚至像 Netflix 這般的科技巨頭也開始使用 React。對於科技巨頭來說,做錯技術決策的成本會被放大好幾倍,所以會更謹慎考慮是否採用一項新技術,因此 Netflix 使用 React,可以說是 React 的一個新里程碑。

Netflix 採用 React 的一個重要原因在於,因為現代網頁應用程式的迭代速度變快,特別是 Netflix 開始有越來越多競爭對手,因此需要有一個方法讓新的功能與改版更快推出到消費者面前。剛好在這個時間點,React 在社群中累積出一些動能,這讓 Netflix 的開發團隊思考採用 React 的可能性。

於是他們做了一個內部測試,在 Netflix 首頁的改版中,讓兩組人分別去打造新首頁的原型 (prototype),一組人用當時熱門的 Backbone.js,另一組則是用 React。結果是用 React 的那組人,明顯在開發速度、程式碼可維護程度、程式碼可測試度上都做得更好,這讓他們決定採用 React。到了 2015 年,Netflix 甚至在自家的技術部落格發表 《Netflix Likes React》 一文,也因為有科技巨頭的公開支持,React 從大家願意嘗試,變成越來越多人擁護,甚至開始有人在社群中提議說要辦 React 專屬的會議。

擁抱社群的力量

2015 年 React 在社群的評價已經截然不同, React 開辦了第一場 React Conf,門票在短時間內被秒殺搶光。社群中也越來越多人貢獻,其中包含現在廣為人知的 Redux 創作者 Dan Abramov 與 Andrew Clark。

React 的迷人之處在於它沒有給一個標準答案,而是讓社群去發展出不同的解決方案。以狀態管理來說,當時 Facebook 提出了 Flux 的設計模式後,在同一時間有好幾個不同的社群套件都依照 Flux 模式發展出狀態管理工具,而最終 Redux 在這些工具中脫穎而出。

這不是由 Facebook 的團隊去推動,而是由社群的力量去發展出的。當時 React 社群發展出一種獨特且迷人的氛圍,在社群中的人覺得這東西太酷了,我想要參與在其中、我想要貢獻到其中。React 核心團隊的 Sebastian Markbåge 提到 React 沒有把很多東西放到 React 當中是有意為之的,因為想讓這個生態系去貢獻並驅動創新。

紀錄片心得總結 — 感謝前人的努力

紀錄片停在此刻。回頭看 React 的創作者 Jordan Walke 以及許多早期參與 React 的開發者都已不在核心團隊,但過去的那些努力,都是讓 React 得以成為今天的 React 所不可或缺的。

我自己是 2019 年接觸 React 的,那時 React 已經是最熱門的 UI 套件之一,而且已經從 Class Component 遷移到 React Hooks 的新典範。因此我對於這些發生在早年的 React 故事相當陌生,很感謝能有這支紀錄片帶著我回顧這一切,也很感謝 React 團隊與社群的努力,特別是在那些不被看好的時候,仍然願意堅持著,讓身為 React 開發者的我能夠享有這些豐盛的果實。

我自己看完這個紀錄片後最有感觸的三個點,第一個是創新真的不容易,即使好的東西,不是一推出就可能受到大家喜愛,很可能會收到許多批評與質疑。但假如你真的堅信這是好的,持續努力、持續優化、持續溝通,當好的點能夠被大家理解時,就可能像 React 一樣翻轉大家對它的態度。

第二個是做技術決策一定要有長遠的思考。不論是當時 Facebook 的 CTO 支持長遠決策所以讓 React 得以被繼續推動;或是 Netflix 團隊決定採用 React,他們在思考時都是以長期的角度出發。即使這樣做有短期的成本,但如果在長期有更大的好處,短期的成本也是值得的。

第三個是在設計上刻意保留讓他人發揮的空間。React 在設計上刻意沒有規範說某些東西應該怎麼做,這反而讓社群能夠發展出很多官方甚至沒有想到的成果。在技術的世界,本來就不會只有一種最佳解,能夠做到百花齊放就需要在最開始設計出讓百花能夠齊放的空間。

以上兩篇是今天看完 《React.js: The Documentary》 的心得,最後再次強烈推薦大家有空可以看一下,真的是精彩又讓人有許多學習與反思 🙂

🧵 如果你想收到最即時的內容更新,可以在 FacebookInstagram 上追蹤我們