【Swyx Wang】React」發行版」與前端「元框架」——前端框架進入「部署時代」

轉載自 Swyx Wang. React Distros and The Deployment Age of JavaScript Frameworks. Feb 19 2020

爲何咱們再也不有前端框架之爭，以及對React元框架（meta framework）今昔情況的思考#React——題記

James K Nelson最近提出了一個有趣的觀點。

Abramov 先生一直告訴咱們 #reactjs 是一個UI運行時。
在我看來，這聽起來像是React是一個內核。Webpack/Create React App是引導加載器。Next.js和Gatsby是咱們最接近發行版的東西。
那我認爲咱們須要更多的發行版。

若是你和我同樣，不肯定什麼是bootloader，谷歌說 "bootloader是在任何操做系統運行以前運行的一段代碼。Bootloader是用來引導其餘操做系統的，一般每一個操做系統都有一套特定的bootloader"。我想Webpack的運行時就是這樣，但它也是一種編譯機制，嗯，從/src到/dist。

總之，這個比喻是對的。我想對這個問題作一些解釋。

目次

• 卡洛塔-佩雷斯框架 (The Carlota Perez Framework)
• JavaScript框架的「部署時代」
• React「發行版」（Distros）
• 還有哪些React發行版應該存在？
• 給造輪子的人的React發行版

卡洛塔-佩雷斯框架 The Carlota Perez Framework

風投界如今特別迷戀Carlota Perez框架。Fred Wilson和Marc Andreesen都很喜歡它，Ben Thompson、Benedict Evans和Tuur Demeester最近也把這個概念延伸到了大科技、智能手機和加密貨幣領域。

人們喜歡diss技術大佬，認爲他們每隔10年就會從新發明一些東西，這是一個無休止的、沒有意義的循環。但實際上，真正的大趨勢每每會呈現出不一樣的形態。

X軸是20-50年的時間，Y軸是人口滲透率的百分比。在過去的一個世紀裏，這種狀況反覆出現，隨着咱們在發行方面的改進，新技術被接納的速度也在加快。

基本模式是：先經歷一個初創階段，而後是一個大規模增加的、技術競爭的 "狂熱"階段，以後一個轉折點到來，技術達到協同和成熟（常常被比做埃弗雷特-羅傑斯的 "遲到的大多數 "和 "落伍者 "羣體）。

「安裝時代（Istallation Age）」的關注點是增加和創新，每每致使創造性的破壞（讀做：大規模的用戶流失）。「部署時代（Deployment Age）」的關注點是穩定和解決後來者，而這每每是更大的市場羣體的需求。在前者，愛好者和投機者主導一切，事情每每比較簡單。在後一種狀況下，西裝革履的商人佔據了主導地位，不少時間都會花在瑣碎的細節上。

JavaScript框架的部署時代

我認爲JS框架的轉折點是從一兩年前開始的。咱們再也不每月都有一個新的前端框架。React已經在Hacker News Job Board上佔據了31個月的榜首。但不只僅是React，Vue和Angular都在規模較大的公司中找到了很是穩定的應用，而這些公司在短時間內不會輕易遷移技術棧。

部署時代帶來了 「元框架」 --圍繞框架創建的框架的興起，元框架的出現意在解決原來框架沒有設計好的部署問題。React有Next.js和Gatsby，Vue有Nuxt.js和Gridsome，Svelte有Sapper，Angular最近甚至有了Scully。在大多數狀況下，這些框架都是爲了控制單個DOM元素並管理其中的動態元素樹而設計的，他們的元框架將其擴展到覆蓋整個網站/應用，包括路由和靜態/服務器端渲染。

我是個漫威死忠粉，因此我喜歡把元框架比做包裹在鋼鐵俠套裝上的反浩克裝甲——它們更重、但更強大。

React「發行版」

如今咱們來談談React「發行版」。

很顯然，這個比喻是很恰當的。打個比方，React是Linux，Vue是MacOS，Angular是Windows。只是前端框架的世界裏Linux的數量最多。有幾十個Linux發行版爲不一樣類型的用戶打造，都共享相同的底層技術。就React在瀏覽器之上執行操做系統的許多功能而言，這簡直是貼切的真實比喻。

這就是我在去年觀察到的：

React拒絕在樣式和路由等方面發表意見，是用戶最大的挫敗感來源，卻也是其成功的最大緣由。 沒有一個叫React的框架，而是一千多個匠心製做的框架。React能獲得全部這些框架帶來的好處。

這既是React最好的特色，也是其最糟的特色--它的體積小，並且對不少基本的東西都沒有指導意見。這意味着你不只能夠選擇與它搭配的東西，你還必須作出選擇。

我不一樣意James的觀點，CRA是一個bootloader--我認爲它也是一個React發行版，對於單頁應用來講是一個不錯的發行版，但還不能說是一個完美的發行版。

這裏是一個不完整的React發行版列表。

• React Native - 一個爲iOS和Android應用構建的發行版。少有的幾個React發行版之一，實際上包含了很好的默認組件（由於目標生態系統有）。
• React Boilerplate--多是最先的React發行版，只是一個能夠克隆的boilerplate。
• Electron React Boilerplate--適用於桌面應用。
• React 360 - React for VR嗎，固然。
• React Ink - React for CLI's嗎，爲何不。
• Next.js - 混合服務器、無服務器和靜態渲染。插件的故事出奇的萌。頁面拉數據。
• Gatsby.js - Static Rendering with GraphQL data layer。插件豐富。你能夠將數據推送和拉入/拉出頁面。
• React Static - 帶有簡單數據層的靜態渲染。您能夠將數據推送到頁面。
• Create React App - 沒有數據層的單頁App啓動器。
• Ionic React - 100多個優秀的React組件，具備跨平臺的目標和React Router內置在引擎蓋下。
• Docusaurus - 以文檔爲中心的靜態渲染。從markdown到預設模板的鎖定式工做流程。
• Storybook - Component Library遊樂場，能夠作文檔和顯示非React組件。
• Meteor.js - 一個全棧框架，後來採用了React。
• Redwood - Tom Preston-Werner即將推出的全棧框架，包括一個後端GraphQL層。
• Blitz.js--Brandon Bayer的新Rails+React元框架。

甚至還有元框架之上的元框架。

• Navi和CURA是James的項目，在CRA的基礎上增長了一些路由和SSR的功能。
• Docz - 在Gatsby的基礎上，使用默認的TypeScript和MDX設置對文檔進行靜態渲染。
• Expo--一個注重開發者體驗的優秀React Native發行版。
• React Native Web--一個網絡的RN發行版。請看我關於RN奇點的文章
• React XP - 微軟的RN發行版，包括向Windows本地應用程序構建。

而Parcel和可能的Rome遵循Collapsing Layers論文，將元框架摺疊到構建工具中（而不是讓元框架包圍構建工具）。固然，React Native有Metro這個專門的捆綁器，Hermes有專門的JS引擎。

還應該有哪些 React發行版

不過我贊成James的觀點，認爲應該有更多的React Distros，尤爲是當咱們開始解決社區內明肯定義的用例時。他寫道:

但不管如何，這是我理想中的React發行版。
開箱即用的SSR
簡單的CSS-in-JS，只要你想要。
Sane默認的路由和數據獲取/緩存，以及...
不須要GraphQL也能工做 像CRA同樣構建，但...
容許Webpack配置
和到基於fs的路由

除了我喜歡基於fs的路由外，大部分我都贊成😂。

我以爲有一堆的toggles，你能夠一邊體驗一下他們，一邊想一想本身的需求、推出本身的React發行版，或者使用現成的發行版。咱們在/r/Reactjs 現狀調查中涉及到了其中一些內容。

• build target（doc 靜態頁面 SPA 等）
• 狀態管理
• 數據層
• styling
• 支持TypeScript
• 測試

請注意，因爲React Router的事實主導地位，因此缺乏了Routing，固然Gatsby、Next.js、React-Static和Navi因爲須要整合數據層，也包含了本身的路由器。React Native曾經在路由方面有更多的爭奪，但如今React Navigation彷佛是事實上的。

我剛好認爲STAR應用是一套維護良好的應用的意見。我也特別喜歡尾風和React模型的classNames的搭配，這也是爲何我作了Rincewind做爲一個基本的概念驗證。

在編寫格式方面，我也認爲咱們還有一段路要走。JSX文件幾乎確定不是事情的最終狀態。我在Vue的啓發下對React SFC提案進行了初步嘗試，但我認爲Storybook實際上用Component Story Format作對了，我認爲React SFC看起來會更接近標準化的ESM文件格式，而不是自定義模板（The Formats over Functions論文）。固然，MDX也是做爲React短碼的內容格式而存在的，但我認爲它有潛力做爲一個成熟的單文件組件格式--來自Svelte生態系統的MDSvex正在向這個方向發展。

React創做格式將須要一個專門的編譯器，在宏觀層面上，當你設計它來解決像Facebook那樣的樣式解決方案和支持Suspense的渲染即獲取解決方案時，這就變得特別有趣。但即便是在微觀層面，咱們也常常談論一個足夠高級的編譯器，用於React的低級鉤子讓咱們作的全部模板優化。我確實認爲咱們能夠設計更多的語法來讓這一切更加符合人體工程學。固然，若是咱們要作一個編譯器，咱們也能夠作一個優化的編譯器! 若是咱們不真正依賴React的細微行爲和事件系統，那麼就利用Preact？我打賭這聽起來比實際狀況要簡單得多）。

正如Tom Dale在2017年觀察到的那樣，編譯器是新的框架。但React會走Svelte、Vue和Angular的路，並打破本身的運行時嗎？不會，它還有其餘的顧慮。

給造輪子的人的 React發行版

爲何只有App開發者纔能有React Distros？（造輪子的人就不配擁有姓名React Distros嗎）

我在探索 creat-react-library 的過程當中第一次和Travis Fischer 結交。我還幫助維護TSDX，這是一個用於構建React + TypeScript庫的工具鏈，好比Formik。當咱們有把握說部署階段的各類基礎已經趨於穩定時，咱們就能夠開始造輪子來幫助咱們造輪子了。