最近看到了 Rich 发了一篇关于 《未来Svelte》的推文。
非常激动的点开看了,这个视频我看了两遍,感觉质量还是非常高的,从如何构建开源库 到 如何运营开源库 再到 开源库的核心库规划 一系列话题。虽然视频是针对 Svelte 这个框架的,但是我认为同样适用于任何一个框架。
接下来我把个人觉得一些重要的点做了一个总结归纳,如果想看完整版内容请看原视频(https://www.youtube.com/watch...)
整个视频都是以问答的方式进行的,因此每个标题我都归纳了主持人对 Rich的提问,如果只想要看 Svelte 未来的规划,可以直接跳到第四块内容。每块内容最下方有笔者自己的个人理解(不认同可以跳过),非对话中的内容。
1.构建的第一个流行的开源库是什么?如何改变在开源道路上的进程?
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 ,适合任何开源项目的流程,从如何构建一个市面上没有且有价值的项目 ,再到设计开源项目的时候如何划分核心库(项目定位) 再到如何推广开源项目(招聘/工作是一个非常重要的方向) 然后到关于开源赞助我们应该如何一起塑造这个项目 ,最后项目的未来规划最好有一个文档的沉淀
结语
❤️关注+点赞+收藏+评论+转发❤️ ,原创不易,鼓励笔者创作更好的文章
关注公众号秋风的笔记
,一个专注于前端面试、工程化、开源的前端公众号
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。