0.
引号内为 Evan 原话的总结和概述，引号外为我的一些想法。 总结和概述可能难以完整传达 Evan 原意，一切以播客原始内容为准
1. 关于开源项目和开源贡献
“这是两个不一样的问题。
对于开源项目来说需要解决用户的核心痛点，而不仅仅是自嗨。
比如 volar 就真实解决了痛点，几乎所有 vue 用户都在用。不只是你觉得用更牛逼的方式实现了一个东西，就一定会有人用，需求是第一位的。
例如做一个框架去挑战 react/vue，如果想要有用户，必须要有一些本质上跟现在方案完全不一样的东西来吸引用户，才能平衡掉在生态和成熟度的劣势。
开源贡献分成被动和主动两个方面
被动是仓库对贡献者的友好程度，比如 readme 中对项目的介绍，项目的定位、开发原因、解决的问题；对于贡献方式，依赖选型的原因、代码和文件结构、各个部件之间的以来关系、对贡献和 pr 要求。 这些写的越详细越能帮助新贡献者开始。
优秀的贡献者也会从你的角度去思考，会在 pr 中把你应该知道的信息全部写下来，方便你 review 和 merge。
其次，你需要去观察一个贡献者的代码是否符合你的直觉，是否跟你的实现方式类似。有些人的脑波会跟你比较合拍，一个 pr 中解决的方式、取舍的方式跟你的思考模式都是一样的。这种就是宝藏贡献者就需要你主动出击，主动让他贡献一些功能，他也会觉得自己感到重视，让他的贡献体验变得更好。
就我的观察，维护过开源项目的人的 pr 往往质量会更好，更知道一个优秀的 pr 应该包含什么”
自己的一点想法：
思考需求而不是技术。 开源/公司/独立开发项目都是这样的，思考这个 产品/feature 能够为用户解决什么问题，而不是背后的技术多么巧妙，或者自己觉得用户会喜欢 xx 功能。
这 说/理解 很容易，但因为我们是技术出身，在思考的时候总是会被技术拉回去，因为我们很难拒绝那种优雅流畅的技术实现带来的爽快感，但要时刻提醒自己这不是用户所需要的，也不是用户所关心的。
2.如何看待 TurboPack、Rspack、Rolldown 这几个锈（rust）化工具链的工具，以及锈化会不会扩散到工具链之外
“工具链这部分长期来看锈化是避免不了的，但不会扩展到工具链之外。
TurboPack 最近文案改了，改成更专注于支持 nextjs 的编译需求，而不是一个通用的 bundle 工具。之前他们既需要做一个通用的工具，又要支持 nextjs 不断变化的需求，就难度大很多，才会导致这么久没做出一个能用的东西。
Rolldown 是因为 vite 需要一个又快又灵活的 bundler，esbuild 和 rollup 各有各的问题，所以我们需要自己写一个。没有使用 rspack 核心原因是，我们需要一个无缝接近 vite 需求的，而 rspack 主要是接近 webpack”
🐶 看来不急着学 rust，慢慢等工具链绣化带来的收益就好了。
我不用急着买 m3 max 了
3. 如何看待 deno、bun， 以及 winter CG 这种想要统一 js 运行时的标准？
“bun 这种大一统的框架是建立在 node 多年发展的生态上，node 最开始能干的事很少，所以需要足够专注，而现在 bun 可以整合成熟的生态成为一个框架。node 多年生态里所有人各自去探讨和研发，各种方案竞争最终活下来形成事实标准，然后 bun 照着这些 API 去做一版，然后才做成现在这个样子。
bun 的摊子太大了，他涵盖的范围和人手不成比例，他把很多功能都做了，但有没全做，比如他的 bundler 只支持 ESM output，不支持 IIFE。另一个角度来说 bun 也是一个野心非常大的项目，但把所有宣称的事情都做到 production ready 的状态是需要比较长时间的。
他之所以搞这么大的摊子，是因为他融了钱，他需要做一个回应给他那么多钱的一个商业模式，也就是跟 cloud flare 、amazon lambda 去竞争的商业模式。
deno 也是一样，跟 node 的差异点就是内置的功能，比如支持 ts ，但跟用 esbuild 转译一下再用 node 跑的差异也不大。deno 聪明的是把一些第三方服务比如 kv 等整合在一起，但这能否劝说开发者抛弃庞大的 node 生态是不好说的。”
bun 和 deno 作为偏商业化的项目和开源项目的思考行事逻辑是不一样的，需要为投资人和商业故事思考。比开源项目更多的宣发能力也可能带偏了整体氛围。 我记得无论是 deno 还是 bun 出来的时候都是刷屏级的讨论度。
当然不是拒绝商业化，还是放到实际使用中去做对比，谈体验。
4. 怎么看待前端框架的未来发展？
“在前端开发体验上还是有一定折腾空间，但其实你可以感受到各大主流框架有一个趋同的趋势，除了 react 外都趋向于 signals 响应式这种开发范式。 在上层框架，更多是针对一些优势场景做优化。比如 Astro 是针对静态场景，qwik 针对电商场景 极致的首屏速度加载 等等
我大致的感受就是，在一些地方大家明显的越来越趋同化，在场景特化这部分做的越来越广。
而 next 是比较万金油的方向，希望通过 rsc 搞一个天翻地覆的范式成为银弹，但我觉得他不是 ”
5. 如何看待 Nextjs 中的 React Server Component（RSC）？
“rsc 是前端框架的一个延伸，是对你服务端运行时、前端后通信进行延伸和要求。组件化是大趋势，也是主流框架提供的核心价值就是组件化。
rsc 希望解决的是 你的结构、样式、逻辑和数据作为一个单元，原来是没有数据，其他三个纯前端的作为一个单元，现在数据也加进来作为单元的一部分。 这也就意味着，react 必须对你后端如何获取数据都需要干涉，才能把数据加入到这个组件中。
然后我觉得 rsc 的另一个核心问题，它默认了你每次请求都需要跑 server rendering，所以你有很多 server component 是跑在 server 端的，每次交互都需要在 server 跑东西，也就是 server compute 的增加，这是 vercel 从来不提的，因为他们从中盈利。
因为 vercel 是一个融了很多钱的公司，他也有很多盈利的压力，他自己说自己做的技术决策跟盈利无关他自己都不会信的。如果我为自己公司去挑一个技术栈，用 rsc 要在 vercel 上多付很多钱，这也是一个需要考虑的点。
而且 rsc 也不会带来本质上的提升，只在电商这种要求首屏速度、数据多样化和要求数据的 freshness，且每个用户看到的数据是不一样的场景，不是所有人都在做这样的应用。所以我觉得他不是一个银弹。
考虑到她想要解决的问题，就是流畅的把数据作为代码切分的一个单元，同时在离数据更近的地方获取数据也就是在服务端做这个事，这个事合理的。但首先不是所有场景都值得这么做，其次目前的开发体验还没能把这个问题解决透，很多用 page router 的人切到 app router 用起来就是不爽，最后就 use client 一把梭了”
“我觉得更像是 next 挟持了 react 的感觉，next 想要强推一个东西，就需要 react 进行比较大的改动去支持。他们现在耦合度太高了，比如 remix 一直想上 rsc 但考虑到 next 和 rsc 的 耦合太深了，对他们就很有风险”
6. 一些零碎的信息
“不搞基建没必要学 rust，rust 跟 js/ts 侧重点不一样，适合你要解决的问题比较的明确和固定，你需要用最高的效率去解决这个问题”
“llm 目前日常我也在用，但我日常写代码基本靠不上他，只在写一个非常具体的函数的时候会使用”
“llm 对独创性没那么高的任务还可以，但对需要创造性、或者需要高层次的设计和精炼的任务上还是一个很粗糙的阶段”
“Evan 也有掉头发的烦恼，等多赚点钱就去植发” 写了 vue 还是植不起发 🐶
“维护 vue 快十年，我也会有 burn out 的状态。我可能就会休假或者天天玩游戏， 长期做一件事都会进入这种状态，没有好的调整方式，有时候你越调整越难进入状态。
没法保持一直保持 100%热情很正常，人是起起伏伏的。可能你调整过一段时间之后，会突然觉得这个东西好像可以这么写一写，然后写着写着又开始不知不觉又写到凌晨。
”
给技术新人一些经验和指导
“我觉得这个是一个很兴趣驱动的东西，我一直认为兴趣是一种天赋。因为很多时候你在一个领域的提升，取决于你花了多少时间去钻研。
但是对于有些人来说，强迫自己去钻研很累很痛苦。但是对于有些人来说，钻研一个东西就是乐趣。他觉得说我就是给我一天 12 个小时都不够，我就天天可以搞这个东西，这其实就是一种天赋。你如果能够进入那种说钻研的一个东西，一天，我觉得说时间不够用，我还要继续搞，那这就是说明你就是生来就是干这行的。”
