對話 Svelte 未來，Rust 編譯器？構建大型應用?

最近看到了 Rich 發了一篇關於 《未來 Svelte》的推文。

非常激動的點開看了，這個視頻我看了兩遍，感覺質量還是非常高的，從如何構建開源庫  到 如何運營開源庫  再到 開源庫的核心庫規劃  一系列話題。雖然視頻是針對 Svelte 這個框架的，但是我認爲同樣適用於任何一個框架。

接下來我把個人覺得一些重要的點做了一個總結歸納，如果想看完整版內容請看原視頻（https://www.youtube.com/watch?v=uQntFkK8Z54）

整個視頻都是以問答的方式進行的，因此每個標題我都歸納了主持人對 Rich 的提問，如果只想要看 Svelte 未來的規劃，可以直接跳到第四塊內容。每塊內容最下方有筆者自己的個人理解（不認同可以跳過），非對話中的內容。

1. 構建的第一個流行的開源庫是什麼？如何改變在開源道路上的進程？

img

Rich 提到，他做的第一個比較流行的開源庫是 Ractive. 這個庫可能對大家來說有些陌生. 可當時它也是風靡一時的，他可以說是 MVVM 的鼻祖

以下爲 Ractive 的示例:

是不是 Vue 和它很像，因爲在早年，Vue 也是借鑑了 Ractive 的相關用法，從 Vue 的歷史 Issues 中也可以發現這些。

但是 Ractive 推出的同時，React 也被推出了，Rich 心想：完蛋了，自己白費時間了。（畢竟 React 可是有公司作爲背書的），但是 Rich 最終還是推出 Ractive，並且社區反響還不錯，讓 Rich 覺得可以和 React 競爭。

因此 Rich 爲 Ractive 投入了大量的心血，花光了他所有的週末和晚上的空餘時間去開發項目。這也是他第一次爲開源投入了大量的經歷，爲今後的開源事業奠定了很好的基礎。

但是隨着項目的維護任務繁重，對於 Rich 來說以業餘時間去開發項目令他非常精疲力盡，這也是他第一次介紹作爲開源維護者的現實狀況。但是這次經歷教會了他如何獲取用戶，處理如何讓用戶參與貢獻、統一開展項目、如何拒絕 PR 等問題。

隨後 Rich 在開源的道路上一直前行，還推出了另外兩個比較有名的庫 Rollup、Svelte 。

Tip（筆者自己總結，非官方態度）：在初期的時候認定目標應該朝着一個方向去努力，有助於我們的知識積累以及踏入開源的隊列中。

2. 如何創造一個現在市面上不存在且有價值的工具？

Rich 認爲創造工具大部分源於 “個人之癢”（大意可以理解爲個人的技術探索，市面上某些工具不好用就自己造一個）。由於他本身處於新聞編輯部工作，常常有大量的繁重、迭代快的工作，因此利用好開源項目十分重要，正是在這種繁雜的任務中，促使 Rich 想讓開發過程足夠簡單，因此造就了 Svelte.

Tip: 這其實也是一個老生常談的問題，多與實際業務結合，才能創造出一個優秀的開源項目。

3. 加入 Vercel ，對 Svelte 的未來意味着什麼？

1.Rich 也是直言，進入 Vercel 可以與厲害的人打交道，畢竟例如之前 Webpack 作者 Tobias  和 SWC 作者 Donny 都加入了 Vercel。（還有最近 React 靈魂人物 Sebastian 也加入了 Vercel）

2. 還有一個重要的點，Rich 加入 Vercel，意味着自己只要打一份工。（在 Vercel 的工作就是搞開源，這真是令人眼紅啊）

3. 打一份工的好處就是可以擁有更多的時間投入開源事業，Rich 也明確表示，之前的兼職狀態維護 Ractive 就讓他精疲力盡，他不希望同樣的情況發生在 Svelte 身上。

4. 消除人們的擔心，一個沒有資金支持的開源項目，會隨時消失。但是現在有一名全職工程師，並且 Vercel 向 Svelte 投入資源，投入的不僅僅是 Rich 本人，還聘請了 steph Dietz 處理開發者關係團隊的工作。

後面 Lee 還和 Rich 討論如何能讓 Svelte 進入到下一個級別的發展速度。（當你擁有一個快速發展的開源項目後，後面這一點真的非常重要）

Lee 認爲利用工作和招聘對於 Svelte 是非常重要的。拿 React 舉例，也許有一些開源愛好者正在研究 React，如果公司招聘中要求會 React，這對於愛好者將會有一個正向的反饋，這個反饋也會使得 React 社區快速發展，整個是一個積極的循環。

Lee 也表示 Facebook （Meta）也在他們一個的網站使用了 Svelte，即使他們創造了 React，但仍然喜歡嘗試，這是他們一個非常好的品質。

Rich 也表示對 Svelte 非常有信心

Tip（筆者自己總結，非官方態度）:  開源維護者真的需要衡量好本職工作和副業，也許未來會有新的解決方案，能夠幫助開源工作者擁有好的時間分配方案以及資金收入。（不然就會像最近的 Log4j 一樣... ）

4. 關於 Svelte 的未來總體規劃，明年或者未來幾年對如何推進框架的看法？

從時間線來看 Rich 表示確實即將會推出一個新的主要版本。

現在距離 Svelte3 發佈已經過去兩年半之久了。

Rich 對 Svelte4 有非常多的想法，但是他現在有點猶豫要不要提前來挖坑，哈哈哈哈。（還有點可愛，知道自己老是挖坑，但是不埋坑）

但是他還是談論了一些目前正在着手做的事情，利用 Rust 重寫很多工具鏈，來提高編譯速度。

還提到重要的一點，很多人批評 / 擔心 Svelte 是因爲 Svelte 編異輸出代碼的時候，Svelte 的體積隨着組件數量增長曲線會比其他框架更加陡峭。

這張圖反應的問題，一直是 Svelte 所被詬病的...

詳細的 Issues 可以看 https://github.com/sveltejs/svelte/issues/2546

雖然 Rich 認爲這個在現實中並不是問題，因爲 Code Splitting 和拐點足夠遠一般不會發生這樣的情況，但是這依然是一個隱患。

因此 Rich 說已經有了一種新的編譯方案，能夠使得編譯後的代碼小於輸入代碼，真實令人期待~

還談論到目前正在考慮類似 Error boundaries、Suspense、React Server Component 一些新玩意。

Tip: 個人通過 Lee 的對話中感受到的，最好有一個地方記錄項目的整體規劃，有助於大家對這個項目充滿信心。關於這一點我覺得 Vue 做的還很好的，每次有什麼相關大的改動就會先提出一個 RFC 進行討論，以及 最近大夥的 Notion 開源替代品 AppFlowy

5. 是如何規劃核心庫中的內容，例如 React 核心庫是得自己選擇狀態管理庫、路由等等？如何劃定核心庫和生態庫的界限？

Rich 認爲 React 的定義核心庫的形式可擴展性很強，但是你也被迫需要去創造一些周邊生態庫（路由管理、狀態管理以及如何去管理你的 CSS）

這確實造就了關於 React 中非常多的 CSS 以及 JS 庫的創新，但是同時帶來的問題就是選擇困難症，就像  Rich 提到的關於 如何將 CSS 添加到 React 中 這件簡單的事情，都沒有一個答案。

關於核心庫的劃分，Rich 給出了一個答案，他認爲 React 是一個 JS 框架，但是 Svelte 是一個 Web 框架，因此他儘可能地提供給人們方便，例如快速寫動畫啊、快速寫過渡等等。

Tip: 核心庫的劃分確實很重要，個人確實還是比較喜歡官方統一生態比較好，這樣減少用戶的選擇成本，當然官網也可以提供接口來擁抱其他競品。

6. 如何解決開源資助問題的看法？認爲像 vercel 有風險投資的公司可以做什麼？

Rich 表示這對他而言很難，這件事也是他正在學習的事情。

Lee 也跟隨着 Rich 的回答，認爲也許爲開源項目投入數百萬的資金，並一定能夠解決問題。

有時候開源項目可能希望贊助商能夠提供類似 PM 一樣的角色，能夠幫助開源項目更好的管理時間，從而能夠釋放核心開發者的處理雜事的時間。

Rich 認爲很多項目可以從 PM 中受益，也許有一種模型能夠讓某個人充當各種項目的 PM，認爲 OpenJS 基金會有一些方案。

他認爲一些開源項目有一個最大問題，就是需要對 Issues 和 PR 進行分類，如果有一個不負責寫代碼的人說可以幫助這些，他認爲可能會帶來很很多幫助，當然不是絕對的，也許有些開源項目只允許讓核心開發者來進行管理。

Lee 認爲許多很成功的開源項目，在有公司支持支持之前，創始人和主要維護者像一個初創公司一樣運作，需要做很多工作，產品、營銷、工程、技術領導、PM，並不斷擴展自己身的技能，將不同的部分委派給核心團隊或者開源社區。

Tip: 在項目初期的時候個人確實需要花費非常多的時間，這管理難度比公司難多了，非常看重領導人的個人能力，尤其是核心團隊的選擇。

總結

採訪雖然是以 Svelte 貫穿整個過程，但是我覺得本次討論不僅限於 Svelte ，適合任何開源項目的流程，從如何構建一個市面上沒有且有價值的項目 ，再到設計開源項目的時候如何劃分核心庫（項目定位） 再到如何推廣開源項目（招聘 / 工作是一個非常重要的方向） 然後到關於開源贊助我們應該如何一起塑造這個項目 ，最後項目的未來規劃最好有一個文檔的沉澱

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/vYO9lwNMUiAuHtasyUKkxw