No.41 和 Vue.js & Vite 作者尤雨溪聊项目进展、开源社区协作和前端思考
01:53:03 Share

整场讨论围绕 ViuJS 和 Wit 我们围绕这两个作品从技术的一些演进一些思考展开了一些讨论也围绕这两个作品背后的一些开源协作的生态展开了一些讨论后面也围绕艾文最近的一些生活状态和一些对前端的一些发展一些思考展开了一些讨论

好 我们开始吧嗨 大家好新一期的 Webhook 播客又来了 Webhook 播客是几个前端程序员闲聊的音频播客节目节目将围绕程序员领域来闲聊聊职场 聊资讯 聊技术选项等只要是和 Web 开发有关的都可以聊因为主播目前都是前端程序员所以会以前端为视角来切入如果你感兴趣可以加 Auto 的微信新新包包 965 新包 965 进粉丝群

这次是我们技术播客节活动感兴趣的朋友我们在收录里会放对应的介绍 OK 我是本场的主持人而欢迎比较牛逼的新毛头这次我们邀请到了一些新的嘉宾来加入我们讨论首先是我们这边的主播小白菜嗨大家好我是成功追星能和艾文一起闲聊的小白菜开演

我是 VOE 没怎么学但是可以跟亿万吹吹水的 react 选手开议大家好我是 smart 从入门前段就开始 VODe smart 然后我们邀请到了播客的两位历史老嘉宾也是 Evan 的朋友智子大家好我是来串串场的 Gavin 智子串哥大家好我是

想做游大头号粉丝的小川 OK 然后艾文大家好 我是游雨溪 OK 也请艾文做个简单的自我介绍吧然后之前做过啥 目前在做啥在网络上哪些地方可以找到你我是当然是 Viu 和 VIT 的作者然后现在也主要是忙着两个项目

已经做独立城市人独立开源已经差不多七年多了吧七年多了对快八年了对然后现在在新加坡还要说啥

在网络上哪一地方可以找到对嗯我有微博和知乎但是都已经基本上不太用了对我现在主要还是在推特上面就是就是这个叉上面对然后我叉上面有一个英文的大号和一个中文的小号然后呃英文大号的 id 是有语系的拼音中文小号的 id 是与 ceo 的拼音嗯

对平常关注前端一些动态的时候也会关注这两个信息源问问智子川哥之前线下也见过 Evan 吗我是之前有在阿姆斯特丹就那次 View Conference 和新加坡也跟 Evan 有过对我们见过好几次了感觉怎么样平常线下去看

呃感觉线下 Evan 是一个更就是随和然后就是没什么架子然后很很容易相处的所以这感觉一定很奇妙呃川哥线下见过吗

我第一次能见到真人其实是在 2019 年 U-Counts,在上海交大那一次上一次我主动要求前端 SSR 机卡的时候也是感觉非常亲和吧其实我是抱着最新的心情去吃饭的,很 nice 两个人线下见面提到的评价都差不多

我们最近都提到了一些在线下活动见到你然后我最近也看到在那些英文的场合其他的场合还包括最近 FE Day 上的场合你提到了一些技术观点比如围绕 Viu 相关我看有 Viu2 升级到 Viu3 你提到了一些历史经验的一些复盘大概在讲啥然后可以快速给快速过一下细节我会放在 show note 里边

反思一下 2 到 3 的时候,本身 2 到 3 是一个比较大的破坏性的更新,所以事实上也确实造成了生态的割裂,有相当一部分用户还是卡在 2 上,国内可能 2 的比例还会更高一些。

就是本身可能接受新东西的这个意愿会弱一些然后三的这个浏览器支持可能也是一部分原因吧但是在国外的话

国外的话基本上新项目肯定是全部是三了就是整体上其实趋势还是比较好现在其实昨天我取的数据现在三占到所有下载量的 49.7%所以今年年底应该三的总下载量就过半了然后去年的话过去一年里面三的下载量差不多增加了 70% 80%

然后也就是说新增的量里面绝大部分全部是三的量然后等于说是在慢慢的二到三的这个迁移还是可见的就是比例在增加所以在这个趋势在国外我感觉是比较明显的国内其实我个人的直观感受可能是稍微滞后一些但是我也现在也不太确定说实话然后主要就是分析了一些就是说造成现在这个现状的一些

可能当时回过头来看可以做的更好的地方一个是对于破坏性更新的这种处理低估了它对低估了这些小的破坏性更新组合起来的这个复杂度另一个是低估了一些内部的改动对于生态里面一些重要依赖的这种影响

比如说我们一些内部的 API 或者是 sale 行为的改动可能会导致像 NUX 和 Vutify 这样的依赖升级会比较困难所以基本上 NUX3 和 Vutify3 基本上都等于是重写了所以这个其实还是挺伤的现在看来肯定是某种角度来说重写有重写的好处因为你等于说是一个新的开始大家其实可以抓住这个机会去做很多比较底层的一些这种

重新设计就是说长线来说这种从底层彻底重构肯定是会带来一定的好处的但是从短期来说对于生态的这种破坏性以及对于这种旧用户升级的这种难度肯定是有很大的影响

所以主要是反思这一块的东西然后另一块就是说在当时的发布的这个周期发布策略上面因为我们是确实也是花了比较久的时间吧因为中间还花了时间跑去做 beat 所以就导致三发布的时候呢会比较晚然后我就当时想先把 core 发布了然后让生态里的这些库先给我适配起来但没想到呢发布之后呢反而是很多的

用户就开始想要直接用 3 去做完整的应用但是那个时候配套了很多设施甚至是包括文档然后包括工具链包括这些收编库的支持其实都还没有完成还没有像 Core 一样完全的可以说是稳定所以对于早期的那些用户来说初始的印象就不太好

所以就也导致了一些就是就算刚出来的时候会有一些人就觉得说这个体验不行但是呢所以实际上一直是差不多到 3.2 的时候我们才把所有的东西全做完了

但是后来后面就分析一些就是说中间当然也是不仅仅是有一些回过头来做不好也做了一些我觉得比较正确的一些决定一个是彻底用 ts 重写对吧就是这个决定其实是 19 年做出来的就是 19 年的时候可能大家对于 ts 的这个整体的判断还跟现在肯定是不一样现在对吧你做个大项目不上 ts 那可以说是不负责任嗯

那个时候的话其实我用 tf 重写有些社区里的人还是持反对意见的就是觉得说这个靠不靠谱啊就是这种然后嗯另一块就是坚持这个组合式 API 这个也是就是说组合式 API 最早提出的时候也是有很比较大的争议吧呃直到今天其实有一些比较死忠的一些老用户就是这种

可能用 view 的场景比较狭窄的一些老用户至今对组合式 API 还是不喜欢因为他们的场景确实也可能用不着因为本质上 options API 和组合式 API 他们有可以交叉覆盖的一部分的用力然后有一部分更复杂的用力肯定是组合式 API 更好然后有一部分比较简单的用力两边都可以但是 options API 可能会更直观一些所以

从这个角度上来讲其实是因为 view 的用户群体从早期的比较简单的用力 options API 覆盖的比较好的状况慢慢的变到就是说越来越多的 view 的用户也开始做一些比较复杂的应用然后有些用户也开始做比较大的企业级的应用这种情况下从我们的角度来说我们不太可能说 view 就是只能做小应用的所以我们不会再去改 API 了但是我们也不会说

一开始其实是想说让组合式 API 直接成为新的 API 但是这个当时这个想法只是简单的提了一下就社区的这个反抗就非常的强烈所以我们最终还是选择了两个 API 并存的形式但是就是说还是坚持把组合式 API 一路的做下来然后把

这个开发体验其实配套的也都提升上来了尤其是 3.2 script setup 引入之后我觉得其实开发体验还是相当不错的而且很比较讽刺的就是到当推出的时候很多人都说这个长得像 react hooks 我为啥不用 react 呢到现在结果很多人都开始吐槽 hooks 这边是坑那边是坑然后都说 signal 好 signal 大法好

结果 Signal 不就是组合式 API 吗其实就是一回事所以所以现在看来就是反而是你看 Signal 这个概念被炒热了之后现在 Solid Angular Preact 甚至是 Svelte 也开始搞 Signal 所以实际上就是除了 React 之外大家都已经全部统一 converge 到 Signal 这个范式上面去了所以从这个角度讲来的话反而说组合式 API 其实是先行者

所以大致上就是这么几个点了就是回顾了一下当时做的比较好的决定做不好的决定都有对刚才提到的有提到这些话题然后我们这相当于快速回顾了一下然后之前刚才提到这些信息我看最近前段时间 F1D 预播搞的大会上我看也作为特殊嘉宾对我忘记怎么称呼了对对对

然后这部分到时候贴出来之后咱们把那个想关注刚才提到一些数字部分的细节包括中式的一些原始信息的相关处理包括一些 PPT 到时候我们会把链接贴在上面 OK

这是回顾了咱们之前那个相当于在那个 ViuConf 上本来可能预期原计划是在今年年中有机会能够在 China 上那个 ViuChina 能够看到最近前段时间在那个 ViuConf 上也对 Vit 这一块的工作有一个展望和一个对未来的一个期待能够快速给回顾一下吗

对,FIT 的话,现在我们其实前两天刚发了 VT5,然后现在其实 VT 的大版本相对来说,更有点像是 Vue 的这种 minor release,因为 VT 的大版本其实破坏性更新就不是这种大的 API 的这种变化,而是一般是

去掉一些旧的这个 node 版本的支持然后可能会升级一些重要的依赖就是依赖有大版本的升级比如说 vita4 的时候是升了 rollup3 这次 vita5 的时候升了 rollup4 然后 rollup4 里面这次比较大的一个特性就是他们现在把 parse 的部分用 swc 给剔掉了等于说是部分绣化

这样的话对于 Rollup 的这个生产构建性能也就是 Vita 5 的生产构建性能也有一定的提升然后其他的话其实 5 里面比较大的其实没有什么特别大的改动就是 Vita 的这种所谓的 major version 现在其实是非常稳定的 major version 就是很多插件甚至是据我所知有些插件可能从 Vita 2 到现在就没有改过

就一直都是可以 word 所以所以 Vit 这边呢其实它的核心我们现在是一个是稳定是一个非常重要的点更多的一些 feature 层面的东西不是对于终端用户可能感知并没有那么强烈其实我们很多的底层的一些新添加的选项新添加的一些 API 的调整都是更多的去服务上层的一些框架开发者就比如说像 Remix 他们最近也切到 Vit 了

然后因为现在等于说可以说除了 next 之外所有的框架现在全部是在用 bit 所以在这一点上我们等于说这个肩上的担子也比较重一些吧所以很多的精力都是在

去满足一些这种框架开发者的一些比较稀奇古怪的需求然后去确保就是说我们如果在 vita 里面添加一个功能不是说去特定为一个框架提供而是说我们确定提供的这个功能是对大部分框架都是 make sense 的是合理的然后对大家都是有价值的去做这样的一种判断然后还有就是

确保每一个改动都要跟所有的这些下游的这些生态里的这些项目都要兼容所以我们有一套比较完善的这个 ecosystems 也还像一套机制就是每次发版前其实大部分的时间都是花在了这种下游的这种兼容性的这些调整上面呃

对,所以从未来来讲,对,未来来讲的话,重点就是说我们也是分析了一下 Vit 现有的一些缺陷,就是可能被人说的比较多的,就是一个是生产环境构建还是不如比如说像 ESBuild 这种来得快,对吧?但 ESBuild 的缺点就是它对于产物的控制能力非常的弱,就是它基本上不给你任何选项去控制说你要怎么分 chunk,

你的代码切分怎么分然后加载的这些微调的东西几乎是没有的但 Rollup 在这一块上比 ESBuild 好很多 成熟很多但是呢很慢 一个是慢 一个是 Rollup 本身其实也有一些还可以改进的地方所以我们想了想 然后另一点就是说现在 ESBuild 跟 Rollup 各有所长

在 Vita 里面开发的时候用 ESBuild 去做依赖于打包生产的时候用 Rollup 做生产这样的话等于说依赖的部分其实是被两个不同的帮助去处理所以还是会不可避免的有些情况会产生一些微妙的不一致性那这种情况就是说还是已经比较少见因为早期开发的时候把大部分的坑都填掉了但是还是不可避免的会有一些打包的非常奇怪的库然后就会导致一些问题

所以我们最终就是说现在长线的解决方案就是

要写一个新的帮位来解决这个问题这个新的帮位就是 RollupRollup 就是 Rust 版的 Rollup 但是实际上又不是完全是 Rollup 因为我们在 API 的尤其是插件 API 和构建的这些 JavaScript API 上会跟 Rollup 去对齐因为这个是把它无缝接入现在 Vite 的一个前提条件但是 Rollup 这个项目本身它后期的 scope 其实是更大一些

它首先是会包含像 ESBuild 那样的内置的 TS 转换 JSX 转换压缩以及这个新语法的这个转译成旧语法的这样的一个这些东西长期来说我们都打算是做在里面的因为我们是希望能够在一个工具里面复用一个 AST 从头到尾把所有的事情都做掉这个是 ESBuild 快的核心原因

所以如果我们光写一个 Rust 的 Ombler 但是这些很重要的工作依然需要去依赖插件去做那其实还是会产生首先是插件和 Rust 之间的通信成本另一个是插件还要再把这些 JavaScript 再 pass 一遍所以这些成本其实都是需要去把它给通过把这些功能放在一个东西里面去把它去掉然后另一块就是对于

对于生产环境产物的控制,就是 webpack 的 chunk split 的算法还是会比较能够灵活性更高一点,比起 rollup 来说。所以我们希望是能够让 Rodan 能够拥有跟 webpack 同等级的对产物的控制能力。就是对生产环境的产物的优化能力还是需要加强,然后可能会加第一方的 module federation 的支持。

这样的话可以后期跟 RSPAC 那边的 modular federation 可以互操这样的话就是比如说如果公司里团队有一些 legacy 的 webpack 的项目升级到了 RSPAC 然后一些新的项目用的是 vit 然后将来比如说你旧项目可以升到 RSPAC 新项目 vit 里面加进 roadown 之后两边甚至可以用 modular federation 进行一个运行时的这种互相调用

所以呃,长线来讲的愿景是这样的对对然后刚才提到这些细节我们呃还还还会把这些那个对应的 PPT 和对应的一些原始信息放在那个 shownote 里边刚才提到了一些有趣的点比如刚才我们呃

目前之前在关注就是为的下一个版本和为他的下一个版当初呃在为的康复的时候那时候还在 rc 现在我看已经 release 这一部分 v5 的一些内容和一些改变的核心刚才爱文也提到了那呃接下来还会有一些关于提到的那个我们对对对

对外提到说为他要绣化那具体是怎么回事然后他接下来要有哪些路线图那近期短期和长期怎么来做然后刚才也大致提到了进步的细节咱可以去看那个收纳里面对那信息 OK

刚才提到了一个大版本之前也有在谈说那 Vue 会有下一个版本无论是 3.4 或者那个 Vue4 之前也提到一些特定的功能特性比如 Viper mode 之类的这个有进步的信息了吗对这个现在也是一样的就是说其实我发现我们现在在 Vue 和 Vite 两边的策略都是差不多的就是我们短期内的这些版本发布是专注于

大前提是稳定稳定的前提下做这种细致的改进就比如说 Lit 这边是去更好的支持上层框架

然后能改进性能就改进性能,View 其实也是一样,就是 View 这边其实我们把很多的这种创新性质的东西可以放到生态里面去做,然后核心强调的是稳定和潜移默化的改进这些基础性能,让用户可以在不需要做任何改动的情况下受益,所以比如说像 3.4 里面我们现在一个比较大的一个是小英式系统的一个,

这个 refactor,响应式系统重构,这个是 Johnson 他做了有好久,然后也是一个比较大的改动,因为它涉及很多这种,就是会有潜在很多的这种坑,就是行为,因为核心,就响应式系统是 build 的最核心的一个部分,所以它任何细微的行为改动都可能有一些难以,就是在普通的这种测试中难以抓到的一些,

所以我们也是在 Ecosystems CI 里面等 Ecosystems CI 完善,并且确保它对下游的这些项目的影响都是在可控范围之内,所以才敢去做这样一个改动。现在 3.4 Alpha 里面这个改动已经 merge,然后大家也可以去尝试一下,主要是做了

这个重构的意义在于一个是本身的一些性能指标的提升在 benchmark 里面另一个就是它对于比如说计算属性的重计算的精度提高了就是说之前我们的计算属性主要有多个依赖任何一个依赖只要变了这个计算属性的计算过程一定会重跑一遍不管这个依赖本身的值有没有变

现在就是说如果这个依赖虽然变了但是它的值其实没有变那么可以跳过计算属性的这个重新计算过程所以效率整体的这个等于说整体的效率会更高然后另一块就是 3.4 里面其实还会有大量的类型方面的一些类型方面的一些改动这个也不是改动更多的是把一些比较

坑的类型的 edge case 去填掉因为这个类型系统其实现在也是一个等于说是完全是一块拓展出来的一块维护的范围所以我们团队里面有一个英国的团队成员叫 Carlos 他现在在做很多这种

类型的这种优化一个是类型的优化一个是一些工具类型的提供就比如说更方便的去抽取组件的这个 props 类型抽取它的 emits 类型或者说是把内部一些写的现在比较复杂比较难以维护的类型去把它简化一下等等做这方面的工作然后我最近这两天在做的一个就是把我们的 parser 也重构了一下

然后他所以现在性能基本上可以提升一倍然后对上层的使用也不会有任何的影响就是完全兼容的把性能给提一倍那这个在实际构建中可能实际的影响可能也就把提升个百分之几因为考虑到实际上大部分的时间是花在了 Java script 的 parsesource map 以及 manification 这些东西上面但是这个 parse 本身其实也是一个就是说

也也会影响于其他方面就比如说啊因为比如说我们 ide 支持 forlar 里面它其实也用到我们的 parser 就我们的 parser 快一点 forlar 的响应就会更快所以对于 ide 体验也会有帮助嗯

所以 3.4 其实就 3.4 3.5 接下来主要就是这几块 3.5 里面还会有一些有一些这个 SSR 的这个 hydration 的一些优化这一块呢我们现在也是就是说 SSR 这一块的东西我们只有一些不得不在 core 里面做的事情才会在 core 里面做然后一些语法堂层面的东西我们就交给 NUX 去做

这样的话两边的节奏,NUX 现在其实节奏会比较快一些,因为他们是在做上层的一些开发体验,语法堂这些东西。那 Viewcore 这边就做一些节奏稍微慢一些,但是是这种比较的不影响最终用户,但是会让整体所有的上层的东西都会变得更有效率,更快的这些工作。

那听起来感觉 VU 和 NAS 的关系很像 react 和 next 就是 react 会走的越来越底层然后把一些上层东西都给 next 去做你会觉得这两个之间关系你会有什么想法吗是这么说吧但是说实话我现在觉得呢就是 react 那边更像是 next 挟持了 react core 的感觉

就是我们这边就是一个就是说我们觉得就是说不同的层次的 concern 有不同的人来来来来关注就好就是不会有说就是 NUX 强行去推一个东西然后需要 view core 去做很大的改动去支持也不会说 view core 想要做一个很巨大的改动导致 NUX 不得不彻底重新思考他要怎么支持这样的情况我觉得 react 一个就这个 coupling 其实虽然我们在

很多地方肯定是有协作但是 NUX 和 Vue 的这个偶合度其实并没有那么强反而我现在觉得 NUX 跟 react core 的问题就是他们现在偶合度太高了所以说你其他用 react 的人你要么用 NUX 要么你用 PLAYIN 的这种 client-side react 然后你看 remix 他们那边

想一直想进 RSE 但是他们就是不敢进因为他们觉得 RSE 现在还是跟 next 偶合的太深了对他们来说就很有风险就是嗯

对这是刚才整体回顾了一下整体回顾和展望了一下接下来 Viu 的一些主要版次要版就是未来一些迭代的一些规划点到了一些功能改进也浅浅的提到了背后的一些技术的一些无论是思考还是一些技术的一些条优相信在后面的时候我们会感受到这些对应的功能然后也可能社区和咱用户会有更进一步的直观的感受去体验这些新功能

我看最近之前也在谈 vapor mode 然后这一部分有新的进展吗 vapor mode 这一块的话我们现在其实就是之前是我把 runtime 已经写差不多了然后其实我写 runtime 的时候也是想着 compiler 要怎么写去写的但是后来就开始忙一些 Vit 那边的事情

结果然后再加上 View 本身的积压的一些琐碎的工作比较多所以 VaporMode 后来就一直放着没怎么弄现在我跟智子重新把 Compiler 这一块开始重新搞起来了所以就先看看智子这几个月能搞成什么样智子说一说最近我是在负责 VaporMode Compiler

是有呃是在打算把先把一个最基础的 demo 比如说一个 counter++简简这种操作操作的这种或者说是一个 todo list 这种 app 给跑起来如果这个目标达成了其实是就是一个嗯

就是一个挺定能有有这种动力的小目标然后再把后面的这种比较复杂的 H case 也好然后一步一步给做完吧压力大不大压力说实话还是蛮大的这几天写的写的有点有点有点太那什么了然后说说说怎么了怎么了就是呃

我我需要去看的东西很多比如说之前的这些 compiler 的一些呃逻辑代码是怎么 work 的然后还需要去想想这个东西要以后要怎么设计会比较好但是一开始是想的比较深一点觉得可能需要一步到位说一开始就写一个比较呃无论在性能也好在呃 minify 之后也好需要有一个比较好的

这个效果的但现在我是觉得先把一个追击和 demo 写出来然后后面应该会有大量的时间在做优化这个步骤所以是说先看到一个最初的版本

往未来展望的话会有大概的节点吗比如季度半年度或年度之类的这个其实不太好说就是我我做我至今所有做的东西我都不会给一个具体的时间节点因为我的经验就是我给我自己做的 assessment 永远是错的

每次在大会上说的预计什么时候发布没有一次对这个事实大家公司里的项目有几个是最后 deadline 准点发布的对我是想我们因为是开源社区可能对这种 deadline 没有那么严格的说一定要发不发挥怎么样我们可能还追求的是一个质量多一点对给大家一个 estimate 的话

真的就是个 estimate,很多时候你给自己也添加一些很无谓的压力,核心还是说你得把你想做的东西最好的质量做出来才是最重要的。我其实觉得开源社区的这些东西之所以能够作为很多现在大公司里面的那种软件服务的基石,其实我觉得很大程度上有一种感觉是,

他们成功的关键就是他们有在花更多的时间细心的去打磨这些技术产品背后的各项细节但是反而你看比如说我们在做平时一个可能一些简单的真的面向用户的产品的时候他们总是搞得很操快猛然后

反而可能搞的质量可能不会太高对这个东西就是说呃在大公司里面所有投进基建的钱从老板的角度来说都会考虑说对吧你一个季度做不出来要我多花一个季度的钱他就觉得会开始考虑说哎这东西值不值啊就是对吧就是说呃反过来做开源的话嗯当然了前提也是得你

至少你能得 sustainable,就是你得有足够的钱能活下去。但是因为本身在你有足够的这个时间去做这些事情的前提下,你反而就是说你有足够的空间去专心的做这种基础层面的东西。就很有些东西你在公司的这种环境下,商业化有 deadline 或者说有

技校啊这种什么各种压力之下你会觉得说哎呀这些东西能互弄就互弄一下能说就是在这个地方花这么多力气可能不值得但是在做开源的时候有些地方你可能就是一些啊比较傻呵呵的你去优化一个东西可以优化很久但是这个东西就是说你有这个空间去做这样的事情这也是一个优势对

刚才我们也是很自然从一些具体的那个具体的技术作品我们尝试去也谈到了那开源协作这一块开源协作这一块就魏友和魏特这两边的社区目前的社区开源协作情况怎么样然后比如说 A 说 PR 这种合并包括日常的发版节奏目前就衔接的好吗然后就是精力分配的好吗精力分配的话说实话

也不说能也说不上是好或者不好我觉得 vita 那边现在就是说 vita 在团队化管理或者说团队化推进这一块肯定是我觉得会做好一点因为我在做 vita 非常早的时候我就有意识的去

尽量的引导一些呃外部的贡献者成为团队成员然后呃当然也可能是运气好吧遇到了一些确实是相当有自驱力的这些贡献者然后就是说 VT 现在那边有 Mathias 他等于说是就是那个 Patak 那个猫头像的那哥们他等于说是呃他其实也年纪比较大他都 40 多了然后嗯

我们一开始他作为贡献者进来之后我就发现他特别的特别有耐心而且特别的善于去善于去沟通然后善于去引导别人做一些这种事情然后所以他这种人就非常的适合做听力然后我就很很早就开始鼓励他去让他去协调引导其他的一些开发者

去做一些更具体的工作然后他当然他自己也也会写很多 PR 但是就是说他在这种凝聚社区管理人呃就是说凝聚人这一块真的是非常非常的好然后我就

我发现他这样的才能之后,我就非常刻意的引导他往这个位置上去引导他。然后后来他也靠这个,然后就找到了一份工作,等于说现在是全职在做 VET。对他来说,自己也是一个非常享受的一个工作状态。我觉得就是说,去找到这样的这种机会,

还是还是对于一些项目的存续啊或者发展都是很关键的然后现在 VT 那边还有几个比较非常活跃的贡献者一个是还挺有意思的一个是马来西亚人一个是日本人然后啊就大家都是分散在世界各地但是嗯就可以协作的非常的比较比较的顺畅吧可以说是然后 Viu 这边的话呢

很长以来其实我觉得 Vue 的这种协作结构跟 Vite 那边的一个区别就是说 Vite 到目前为止其实核心还是就是 Vite 一个项目然后可能有几个插件但插件的维护成本其实很低的 Vue 这边摊子就相对要大很多

因为考虑到 view 其实作为框架而言我们有文档我们有工具链然后我们有这个 ide 这边的东西有路由有状态管理有 dev tools 还有什么

总之就是第一方的东西其实特别多然后我一个人是肯定做不出来这些事情所以在 view 这边更多的就是以这种以子项目为单位去区分职责所以我专业其他的一些东西其实现在都有对应的团队成员在做我就不需要去一个一个的每一个都去盯过来就 test your tools 也有专门的人会去看嗯

这样的话就是说我的在 view 这边我主要还是关注在 viewcore 这一块但是 viewcore 这边摊子其实慢慢的也越来越大因为日常进来的页数量确实很大然后进来的 PR 量也很大我们有一些朋友们这个发 PR 的这个热情特别高

有的时候一下子发十几个 PR 我看都看不过来这个时候确实也需要一些更多的人在 view call 里面来帮我一起来搞所以我前段时间也是尽可能的让像 Soda 智子去动员他们来让团队一起能够至少把很多的 issue 和 PR 的初期的一些所谓的 triage 就是初期的一些

呃,说下去中文怎么说呢?分流也不是分流,就是类似于是没有适应的中文吧?我感觉对感觉就找一个合适的中文就先等于说先简单的说一个类

像预诊就是像这个医生的这个预诊一样就是先大概看一下这个东西是归个类然后说如果能知道这个问题的症结是什么对吧就是等于说能分析多少信息是多少信息然后最重要的一点是把它区分优先级就是说这个东西到底有多重要多紧急对吧然后根据这个优先级的高低之后我再去优先关注这种比较重要的东西

目前是这样的一个分流的状态,但是确实还是核心工作量还是比较大的,所以我也是最近在努力还债吧,就是每次我去花段时间搞 Zit 那边的东西,View 这边就会积压一堆事情,然后我再回来还一段时间债,然后再去搞 Zit 那边的事情。

我觉得可能我这个也是自己状态一直在调整就是我可能最理想的肯定还是就是说你可以一边稳定的去处理 view 这边的事情一边稳定的 vita 那边也可以有进展但是我这个人呢就不太喜欢这种呃每天都去 contact switch 对吧这个成就 contact switch 也是有成本的

所以我比较个人自然而言我比较喜欢的这种工作模式是我一段时间就只看一个东西然后专注的把这个东西做的比较深入一点然后再回来去做另一个事情但是呢就这个周期有的时候我会不小心拉的有点长就比如说在 Vita 那边一下子花了好几个月然后回来看 Viu 这边积压了 100 多就是 100 多个新的 PR 这个就比较坑爹一点所以

就是从逻辑上来讲比较好的还是两边同同时进行但是呢从我的个人的工作习惯上来讲呢我还是比较喜欢就是说做一个时间只做一个事情所以这是一个比较矛盾的点也是我在考虑到底怎么解决吧这个也是我觉得

我觉得现在到好一点因为写了一些贡献的手册和本档所以我觉得是可以把更多的职能交给社区的还有像我和 Soda 也可以去分给从外部吸取更多人参与进来这一点其实我觉得你也可以就是说鼓励就是说你认识的一些其他有感兴趣的开发者

去一起来参与然后你作为过来人你可以去引导他们就是跟他们分享一下我是怎么去参与 view 的这些 pr 的贡献啊什么之类的对所以我其实也是有在努力像 vapor 这边也是有在说吸纳更多外部的人进来是

所以我可能会在比如说过几天进行一个 vapor 上面的直播可能可以通过一些就是这种类似这种活动嗯把更多有兴趣的人吸引过来嗯嗯川哥听下来感受如何我我就是感觉到有了更多

给 view 做贡献的机会和动力其实我自己也有一些自己想问的问题比如说我看到尤大之前提说 view 目前越来越注重可能不再会做那么多破坏性的更新然后可能会更关注就是说 view 的核心的稳定性然后更 focus 在 view 自己想做的这一块的事情上但是其实从

Viewmacros 这个项目上面其实我就觉得可以看得出来可能有部分的一些功能或者说是对 View 的一些新的想法和实践其实可能不一定非要在 core 当中去实现然后对未来可能存在的这种 View 的功能可能以某种插件或者是某种第三方的形式去提供有什么期待和展望

我觉得确实就是说什么东西应该进阔什么东西不应该进阔呢所以它是没有一个绝对的答案的很多时候就是说你要去作为框架作者你有的时候会需要去思考就是说因为框架本身也不是说你功能越多就越好就你有它是有一个有我觉得这就是这么多年其实纯前端框架这一块大家卷也差不多卷到头了就是说你该

该有的大家其实七八八每个框架该有的也都有然后能做出来的事情最终做出来的事情也差不多就是说现在不存在什么事情是说就是说你一定要有某个功能你才能一定做出来这个最终的一个结果对吧所以

或者说就是说从以现在的主流框架的这个形态上而言我觉得目前的这个形态是一个非常大家都是一个相对比较成熟的形态了所以你这个时候再去单纯的堆功能其实并不一定是一个非常

收益就编辑收益是在递减的这样的一个事情反而是就是说嗯尤其是对于就这种历史比较相对比较久用户群体很大的这种框架而言呢就你每做一个改动的影响的面都会很大所以就是你把东西加进流阔的这个潜在的要考量的东西也更多潜在的影响也更大所以反而是把一些更

就是说或者说我们现在每加一个功能其他写 ifc 然后要跟大家讨论然后每一次 ifc 本来一个你我可能觉得说很理所应当的东西还是会有很多人提出很多可能你没想到的这种角度或者说是 s case 等等对吧那这种就是说加一个功能的成本其实很高的所以反过来就是说很多事情在像 view macros 这样的这个东西里面没有那么多的

这种制肘的这种地方就可以你觉得一个可以试一试的东西你做出来先先做出来再说对吧然后我们也发现比如说之前有些东西像 reactivityreactivitytransform 啊这种东西我们做成 experimentalfeature 放在 call 里面发不出去了

然后很多人就觉得说我就可以用用完了然后我说这是 experimental 我现在我要把它拿掉了他还不高兴他说你凭什么你这个东西都已经放在扣里你现在要拿掉它对吧所以我这个 experimental 这个是白写的嘛就是对吧所以就是你跟他解释了他还是会不高兴所以我就发现这些事情干脆就你就别放进课就放在 viewmacros 里挺好的

先让大家能用的先用起来然后用的好的大家一致的觉得好评的我们把它吸收进 core 那反而是等于说有一个这种其实本质上是一样的就是一些 experimental 的 featureopt in 的东西然后你用的好我们再把它 stabilize 但是从感官上来说对大家来说可能更容易接受一些因为他在用 view macros 的时候他不会有一种说万一哪天这个没进 core 他会有损失的这样一种感觉

大家从心理上能够接受说一个东西他没有最终没有加进去但他不能接受说一个东西你给我了再拿回去这种感觉感觉有了一个缓冲区对刚才咱也是从从 Evan 的那个精力分配也谈到了两个目前经历的两个经历的这两个项目有哪些相同和一同在开源社区参与和那个组织规划上那么

我们也延伸去谈了一些呃就关于提到关注的一些功能那比如就具体到那 vivo core 和和那个 vivo micro 然后这也提到了两个呃不同的这个趋势这里呃这做做决定总是很难的但是这个呃抉择的过程里有很多细节可以去反复去呃说回听刚才讨论的这部分呃我看呃其他人也有也有从一些从新手角度去去问或去看而且因为我的很多听友中都是比较年轻的呃

嗯,

为了在推特上也提了一些他的一个困惑就是代码组织的清晰但是确认人为户我看大家也给了不同的从不同的角度给了一些建议我觉得使用和参与是完全两个不一样的问题比如说 Zoller 的话其实对吧现在 Vue 的用户都在用就说

要更多的人使用核心的核心还是说你要解决一个用户的痛点才会有人用就是说如果你只是单纯做了一个满足自己的这种技术爽点的东西但是没有满足用户的痛点那是毫无意义的就是不会有就是说你再怎么推也不会有人来用的所以其实我们也看到很多这种

确实有一些可能每一个有点野心的前端开发者都会想要自己搞一个自己的迷你框架我因为这么多年见过太多了每个人都会觉得有一些年轻的开发者他做了一个东西觉得说我自己这个东西太牛逼了全达 reactor 叫 TDU 大家都该来用对吧但可能更多的是只是满足了他自己的一个

自己让自己觉得自己做了一个很牛逼的东西这样一个爽点他真正他没有去思考说首先就是说他可能只是做了一个 react 就都已经解决了问题那对于这些更成熟的东西有更成熟更更强生态的这些选项在那边用户为什么要来选择东西呢所以说一个新的前端框架如果想要有用户你必须得有一些本质上跟现在的方案是完全不一样的东西你才可以去

even out 这些你在生态和成熟度上的劣势就是不是说你自己觉得说我用一个更牛逼的我自认为更牛逼的方式去重现了一个东西就一定会有人用这是其一啊所以就是需求是第一位的然后在参与贡献这一点上呃更多的是两方面一方面是

你的呃就是分被动和主动两个方面被动的方面就是说你的仓库里面本身对于想要来贡献的人有多友好就一个想要贡献的人他在看你的仓库的时候他第一眼看到 readme 里面写了啥 readme 里面有没有清晰的告诉说你想参与的话你来点这边点进去了之后你有没有跟跟他解释说啊我这个项目定位是什么开发的原因是什么我做这些

我用的这些依赖的选型原因是什么,然后我的这个代码的这个文件的文件的结构是这样这样的,这个时候这一块负责啥,这一块负责啥,最好有一个这种一个流程图,一个 graph,解释一下各个部件之间的依赖关系,以及整体的一个架构图,

然后如果你想要来贡献你可以从这里开始然后比如说如果你自己对于发布 PR 的流程有什么自己期待的要求写得越详细越好对吧那这样的话就是很多时候因为你在开源贡献的时候双方大部分一开始都是一种一步的纯文字的交流这种一步的纯文字交流的核心就在于说你要能够一次性给对方提供的 context 越多越好

这样才能降低双方交流的成本就是然后你会发现优秀的贡献者也存在这样的特点就优秀的贡献者他也会考虑到你在接受他的信息时候的这种他能设身处地的为你想然后他会在他 PR 里面把他觉得你应该知道的东西全写下来

然后呢第三个就是你去观察说一个贡献者他写的代码是否符合你的这种直觉上会跟你很相似因为我发现就是很多时候有些 TR 他发进来你会觉得说解决的问题是应该是需要被解决的但是这个方式你完全不能接受

有时候会有这样的情况对吧但是有一些开发者你会发现他的脑波跟你比较合拍就每一个问题他解决的方式你会觉得说就是说他所做的取舍很多小地方的取舍可能跟你会做的取舍是一样的这种就是很合拍的开发者这种就是你需要去这个时候就涉及到一个主动的部分就你要去主动的去让他的贡献的当你发现这样的宝藏贡献者的时候你就要去主动的让他的贡献体验变得更好让他觉得说他是受重视的

然后你要给他更多的这种给他丰富的反馈然后去让他觉得说他的 PR 被你很重视然后被 merge 让他觉得很开心然后你要然后你可以去引导他让他觉得自己可以更有信心去解决一些更有挑战性的问题等等等等就是这个时候就需要你去主动的跟他沟通

那比如说像质子就是我就就把它忽悠过来了就是差不多就是这样对吧因为我其实我这边就是我要夸一夸的就是说

质子的很多 PR 我在看的时候我会觉得说如果是我来写我可能很多思路跟他想解决问题的思路是会很相似然后质子他本身对于代码的细节其实我觉得也是比较会比较在意的所以他基本上质子的 PR 我不需要去在很多小细节方面去做太多的纠结就有些人的 PR 我会经常要在经常说你这边这个

给我分个行好吧你这边这个对吧这个变量名好歹英文的拼写用对吧或者是就各种很让人不爽的小地方就是对吧这个实际实际上是很细节的东西但是说你能感受到有些人的 PR 对你来说就

比如说连续 Merge 的三个 PR 都是不需要做什么改动的你就知道了 OK 遇到宝藏贡献者了赶紧把它给忽悠过来就是这种感觉因为我也有看项目我之前处理 PR 的时候血压特别高的就是他们没有删的那个 Console.log 所以我就想说替 PR 之前先把这个删一删可不可以对

对就是我有的时候在看 PR 的时候也会发现有些提 PR 的人他实际上只是说把这个代码给你然后甚至有些连一点信息都不会给所以你需要去猜他到底想干什么那到后来我就有点就是觉得吧就是他到底花了多少时间在这个 PR 上那我可能也是会以相同的这个时间和模式对他

对而且我会发现就是说自己维护过项目的人开出的 PR 一般质量都会很高为什么因为你经历过那种低质量 PR 的痛所以你知道你自己的 PR 想被别人接受你知道给得做些什么对对对他有点像面试的时候站在面试官的角度你到底想听什么而不是站在自己想表达的一个角度我其实会好奇一点就是 Viu 和 Vit 都是非常

非常广大的用户量和特别是 weight 吧我觉得很多即使非 view 的框架也在使用而且很多公司也在做这个迁移在维护这两个项目的时候你会觉得有这个责任上的压力吗因为很可能你的一个小失误可能会影响范围会非常大或者你的一个比较好的决定会给这个世界带来一个很大的一个好处你会有这方面的压力或者一些想法吗

压力嘛压力其实还好吧我觉得因为某种角度上来说这些用 view 用 v 这个公司也不是我的顾客他没有花钱给我买服务所以我也不欠他们什么对吧就说呃从这一点上来讲就是说本身我的东西都是 mit license 你爱用不用对吧所以说呃我们也就是说从那个角度上来说因为咱们也不是做这种

什么服务端的这种核心部件什么就不可能我们搞出什么把阿里云搞挂了这种事情是吧所以所以压力确实没那么大就是如果我搞的是什么核心的数据库啊什么那可能压力要大很多我的话还是在维护 view 的时候还是比较有压力的因为感觉手掌有有这么多用户在用还是会影响到他们很多东西的可能我因为我的这个

就是我 view 的用户量是确实是从当年从零开始慢慢做到今天的嘛所以我可能我这个适应的过程就温水煮青蛙慢慢的就一直在习惯我觉得 E1 可能是度就慢慢的度过了那个心理的阶段但是日子可能一开始就面对这么大的用户量就大家都会紧张的

对一想到还有 NASA 可能都在用我的代码就还是再再想想那个 spacex 不说也在用吗你说很抱歉这次发射可能有我的一部分过据说 view 的代码是跑在了那个 NASA 弄去火星的那个东西上面

就是管那个火星探测车的那个系统好像他们的界面里面有一些用 view 写的嗯我其实有个比较叫什么可能比较傻的问题就没有用在一些很很大的项目或者这种像这种火箭发射项目你你现在还会感到非常的骄傲和开心吗还是已经度过了那个阶段了这种小开心嗯现在的话确实现在怎么说就是用的地方确实比较多了吧

现在可能缺的比较少的就是这种什么就是什么超级大公司突然高调的时候我们全都用你的东西这样的会会还是会激动一下就嗯其他一些可能就比较有代表性的公司你发现他在用你的东西还是挺挺好险比如说欧邦 AI 他们官网用那些

就是当时我发现的时候还是挺惊讶的但不过他们那个天级 pc 的建议又是用 react 的我发现很多大公司他其实什么都用可能是两个外包公司做的对就说白了你 500 强的公司你拉一个随便拉一个出来他可能就 react view angular 都有用基本上都是这样就是

还有 Gquery 可能公司也在用对肯定绝 500 强肯定每一个都有在还在用 Gquery 的项目这绝对的其实刚刚提到 Evan 在说就是他会分一些精力在 weight 上分一些精力在 view 上我想说就这个这两个项目都是一个非常强大的社区了就是你还是没有遇到一个你感觉是可以完全值得信赖来代替你去做很多事情的一个人吗

有 Vit 那边其实猫头哥我叫他 MatthiasMatthias 他其实基本上现在是承担了 Vit 那边的职责日常的维护基本上其实可以交给 Vit 团队去做我更多的是会去我们每两周会有一个例会然后我们在例会上会去讨论一些他们觉得说

可能潜在影响比较大需要我去做一些判断的东西然后我这边更大一部分精力现在是在就是思考 VIT 长线的比较需要大量深度投入的一些东西比如说 Rodent 这些 Rodent 现在我等于说是我拉了一群人在搞这个事情对

这个我好像听有些传言是 Rodan 是跟 RS Pack 的团队会有些比较大的冲击同时 Next.js 也在做 Turbo Pack 你怎么看待这几个比较出名的绣画的一个方式你觉得绣画在前端会集中在哪一部分它会不会继续扩展到编译端之外的地方

我觉得还是在工具链这个层面吧,就是我觉得纯你要跑在浏览器里的东西,你又非要用 RUSH 的行,我觉得是比较的没有意义的事情,就是除非因为说着话,就是你纯前端的逻辑对于内存呢,对于这个对于你内存的正确性其实就没有那么高的要求嘛,

这个你用一个 rest 本身是一个你需要付出一部分的代价去换来正确性的这个东西这种代价在前端的场景下就是跑到流转器端的就 UI 逻辑的场景下我觉得是不值账的另外本身还存在就是说你编译到 web assembly 之后跟 dom 交互的这种 overhead 的问题比如即使即使你逻辑层面可能跑得更快了但是

以及又在 DOM 这个层面全部都吐回去了所以就是性能上其实也没有什么本质的优势所以更多的还是在工具链这一块工具链这一块呢就是我觉得他肯定长期来说工具链的绣化是不可避免然后而且更多的会是从越底层的越稳定的这些层面去开始绣化就比如说 OXCROM 一开始想做这个大一统工具链然后从也是从 Parser 开始做

然后 SWC 其实也是类似这样的大家都是先从 ParserTransformer 这种 Linter 这种东西开始做你看那个 Python 工具链那边 RoughPython 现在有一个很新的 Linter 叫 Rough 然后这个 Rough 这家公司也是融了钱的公司他们的目标是要做 Next Generation Toolchain for Python 然后也是从 Linter 开始做就等于说

因为为什么因为呃一个成熟的像 JavaScript 和 Python 这样成熟的语言它最稳定的东西其实就是它的 syntax

所以从 synetex 开始做你的投入错的概率是最低的所以先做 parser,parser 做完之后你再去做其他的因为另一块就是说你其他的空气链几乎都要依赖 parser 对吧比如说从你做 transform 也好,medification 也好你做这种转移也好然后做 bundling 也好全都要用 parserparser 这一块可以说是一个

所以你也看光 JS 就有三个 Rusty 的 Path 了现在然后再往上 RSPack 跟 Rodent 为什么我们首先 TurboPack 这玩意到现在你都必须只能通过 Next 才能用它对吧然后所以说我觉得它的这个泛用性咱们可以忽略不计就是它就是为 Next 而生的一个东西

其实前段时间我们发现了 TurboPack 甚至在它的文案里面在最刚开完的 nextconf 之前他们把 TurboPack 的文案改了一点就是说他们把重点变成了去支持 next.js 的编译需求而不是做一个 generic boundary

可能他们也意识到了就是说如果想就确实就是说如果他们能够一开始就专注做 next js 的需求可能也不会花这么久时间还没有做成一个能够拿出来用的东西就是嗯但是反而是如果你想要做的越 generic 的同时然后同时还要去支持 next js 很多不停变化的需求这个东西的难度就会大很多那反过来嗯从我们的角度从 vita 的角度来说我们 vita 其实一直都是需要一个

又快又灵活的帮主人但是呢就我之前也解释了 esbrollup 各有各的问题所以我们最终决定自己写一个没有用 rs pack 的核心原因还是因为我们需要优先能够无缝的接近 beat 的需求里面 rs pack 的内部的所有的都是照着 webpack 的那一套逻辑来的那对于我们来说要去把它强塞进 beat 里面可能就会比较痛苦

那不如我们借这个机会就自己写一个完全能够符合 MIT 需求的这个东西出来其实还有一个问题是最近之前有 Dyno 现在有 Burn 都是在去做这种 JS 新的运行时包括有这种 WinterCG 这种联盟是想把这种所有的 JS 运行时有一个统一的这种 API 的标准方便这种前端程序员去做事情你如何看待这种运行时之间的一个竞争和未来的一些发展嗯

从某种角度上来说呢,我觉得首先就是说 Bang 其实是,NoJS 它今天跟 Bang 的对比,就比如说 Bang 这种大一统的这种把什么都做在运行室里面,以及 NoJS 这种什么都让生态去处理的这个态度,其实它是一个,你放在今天这个时间上节点上来看,

你会觉得说这是棒的优势,但实际上 node 他一开始他不是说他想不到这么做,node 一开始是因为他一开始他能做的事情就是很有限的一个很专注的一个状态,然后他一开始就有意识的是要让生态去填补这个大家所需要的这些事情,事实上你看棒他现在提供这些功能,

他为什么能一次性把这些东西做出来是因为他很多都有现成的可以参照的东西而这些现成的他所参照的东西是 node 的十多年的这种生态大家所有的生态里的人一起去大家去各自去探讨研发然后各种方案的竞争最终存活下来的这种成为事实标准的方案然后棒直接照着他的 API 做一版

然后才做成这个现代养生所以说不是说棒突然就识破天荒就一下子发明了这个东西其实棒只是把十多年来 nodejs 的生态的一个积累再用这个重写了一遍是这样的一个状态对所以说没有 nodejs 的积累你也不可能有今天棒能够写出来这样的这些东西所以说就是一个时间点的问题那就是说棒这样做它是否能够足够成为它的一个

他差异化的这个东西呢就是说我觉得还是比较的存疑的就是因为从我角度上来说首先棒他摊子确实是有点大就是

你看 Bound 它涵盖的范围以及它现在的人手或者说你实际用过 Bound 的话你会发现它很多的功能其实都是做了但是没有全做比如说你用它的 Bundler 跑一下你会发现它只支持 ESM output 它不支持 IFE 然后它的 Bundler 其实是用这个把 ESBuilder 给 Port 了一遍

所有的东西直接就是用这个把 ESV 的够源给抄了一遍然后它的原来还做了一个 dev server 然后还要跟 lead 比 module 的速度然后它一发 1.0 之前把 dev server 给砍掉了因为它没时间维护然后它摊子实在是有点大然后你看它的发布 1.0 的时候有 900 多个 open bug

然后他就赶交 1.0 我也是有点服气就是所以从某种角度上来说呢就是说他是一个野心很大的项目但是他的这个最终他能不能把他每一个他宣称要做的事情都做到一个完全稳定 production ready 的状态

这个还是要花很长时间的然后还有就是说 bump 他是一个他之所以现在敢做这么大的摊子是因为他融了钱嘛融了钱那就问题就来了就是说他要如何去做出一个能够回应给他那么多钱的这些离析的一个商业模式然后他的商业模式是要去做一个类似于跑 nojs runtime 的一个东西那也就是说他要去跟 cloudflare 这种 workers

去竞争需要跟 Amazon 的 lambda 去竞争然后他要等于说要自己去做一整套这个 server 的 infrastructure 所以总的来说就是说这是一个真的是很有野心的东西但是他的商业模式是有成立他能活多久以及说光是他所宣称的这些性能优势是否能够让足够多的开发者从 node 切换过去我觉得还是

现阶段来说不太好说吧因为你说他说要说他快他其实比诺的快的部分很多是涉及到原生 IO 比如说 HTP 这一块或者说 File SystemIO 这一块他确实可能是快一点但是诺的也不是不能再改进了然后而且你说从纯引擎的角度来说其实他用的 JavaScript Core

很多纯计算量的东西它其实还没有 node 快比如说我这两天在做 Vue 的 parter refactor 我就发现我的 parter 在 node 里面跑的就是比在 bomb 里面快对吧那就是说从这个角度上来说它的性能其实也不是一个在任何场景下都适用的一个差异点就是

那 Dano 就更不用说了,反过来你会发现 Dano 跟 Bang 其实它想跟 Node 打的一个更大的差异点就是这种内置功能比如说 Dano 它现在 TypeScript work out of the box,Bang 也是对吧但是你其实比如说你直接用 ESBuild 给转译一下然后再跑在 Node.js 里面像这边有这个 Node 这里它有什么 tsx

其实这些需求也都是可以解决的。我觉得,比如像 Deno 那样比较聪明的一些,他把一些第三方的服务给整合到他的平台里面,像 Deno 出了什么 Deno KV,然后这一类的,让你的整个的开发体验搞得非常好。但是,他这个是否好到足够说,

让你放弃非常稳定非常庞大到这些生态整个切过去我觉得还是挺难的挺难的最终他是否能够支撑这些公司活下去我觉得是一个我个人来说我觉得是一个他们一定能活下去的状态就是我也不好判断

但是我觉得它并不是一个说就是很乐观的一个招呼对 当然即使去发 1.0 可能也是为了去给投资人去看他们做已经有一个比较好的效果了 OK 那我们迅速过一下就是一些听友的技术相关的提问吧然后一般如果可以有素问素答或者如果有价值想延伸的话也可以简单延伸一下那第一个问题是 Vue 会出移动端的框架吗类似于 React Native 你怎么去看待移动跨端框架的一个发展

这个问题我英文日文我都回答过了就是首先我们自己团队肯定是不会做这个事情的因为这个东西的这个消耗的这个资源太多了你要养好多人我们自己肯定不会做的但是有公司做这个事情那就是 native scriptnative script 它支持 view3 所以你想用 view3 做原生你就用可以去用 native script 然后如果是你想做套壳那就用 ionic

就很简单就这样 OK 第二个问题你刚刚也提到了就是前端框架卷的差不多了你认为前端框架下一步会怎么发展会不会就是类似于基础框架停滞不前就像 Spring Boot 在 Java 那边已经就是一统天下然后大家开始在卷这种业务的框架我觉得前端现在在开发体验方面还是有一些折腾的空间吧

但是其实你可以明显的感受到各大主流框架的开发范式是在一个趋同的这样的一个趋势上就是说 view 其实是最早的这种响应式 signal 这种响应式范式的代表其实是从 nokout 开始一脉相承然后到 view 然后 view 在 composition API 这一块像 react 所启发的这种

这种组合的这种范式上面去靠了一下然后等于说 react 从函数是那边 certain class 到 hooks 然后 view 这边从 objectoptions api 到 composition api 两者靠了之后然后但是平行还是两个是平行的一个是函数是 remutable 的一个范式一个是 mutable 加 reactivity 的一个范式然后你会发现现在其实

在无论是在在底层框架层面还是在 meta 框架层面都是 react 是自己的一套然后其他所有的大家都在 converge

就是啊,preact 作为一个 react 这种一配版,他他现在也在搞,他现在也推荐了这个 signals,angular 也现在也别搞 signals,不要也搞 signals,solid 更加就是因为 signals 合起来的,所以说在底层框架层面除了 react 之外,大家现在就是 signals,然后在 meta 框架层面,呃,其实是这样的情况,就是 next 自己是一套,next 加 inc 是一套,

然后所有其他的框架在工具层面全部是 lead 然后在上层大家各有各的百花齐放所以我现在发现可能是在底层框架基础框架确实可能就比较那样然后在上层框架层面你会看到大家其实更多的很多是去针对一些它的优势场景去做一些比较特化的这种优化性的框架比如说 astro 它针对静态的场景

切入然后 quick 是更多的是针对电商场景就是极致的手评速度加载然后嗯所以呃像 svelte 的话他其实是一开始打的是这种极致的这种开发体验的简简洁但现在 svelte 5 的方向说实话就有点呃有点想要往这个想要往就是 signal 在像 v 啊这些方面想靠一靠想要去解决他这个

它的简洁语法但是却不能在普通的 JSTS 里面用的问题但是呢就牺牲了它原来的一些简洁性所以这个也是一个趋同的一个点吧就等于说反而把它自己原来最具代表性的特征给弄没了就是这种感觉所以我大致的感受是这样就是说有一些地方大家很明显的是在越来越一致化就是说大家之间的区别越来越小

但是有一些地方就在 Meta 的场景特化的这一块我觉得大家是在越来越广的其实实际上你看就是在 V 的生态里面上层的框架有一些是场景特化然后有一些是万金油比如说 NUX 就是比较万金油的这种方向然后 React 是 React+SC+NUX 的这一个 Stack 它就是想要说搞一个天翻地覆的范式然后成为 Silver Bullet 它想要成为银代但我觉得它不是银代

大概就是这样一个状态非常巧下一个问题也跟刚刚提到的 next js 有关它其实是多个问题第一个是如何看待 next js 最近的一些改动也就是 server actionreact server component 第二个是你觉得 vuee 会不会去出现类似于 rsc 这种设计然后第三个问题就是如何看待 next js 和 vorsaw 对 react 社区的一些影响其实我觉得

X RIC 的本质呢是前端框架范畴的一个延伸就是说嗯换句话说就是比如说你说 view 会不会做这个事情 view 是不会做的因为我本身做 view 的这个初衷或者说我对 view 的一个定义就是说 view 是一个全前端框架就是说我没有兴趣去把 view 延伸成为一个要去嗯

因为是 dictate 就是说对 view core 它不会延伸成为一个要求你对你的服务端用什么运行时你要去怎么前后端怎么去就是说通信这些事情就是 view 是不会过问这个问题的这是一个基本的一个定位问题

这不是说 react 把它的定位延伸出去不是说这个行为是错误的,只是一个从本身的初衷定位上来讲,view 不是设计出来去解决这个问题的。如果我们强行要把 view 去延伸出去解决这个问题,它未必对于现在的 view 用户是一件好事。

对于然后从 react 的角度来说它要解决的一个问题是就是说在前后端结合的时候数据

如何让你能够在组件里面因为本身组件化是一个大趋势就是我们所有现在主流框架的一个核心价值其实就是组件化组件化的大家之前意识到一个问题所谓的 separation concern 就是在现代的框架成为主流之前一些老一派的开发者说我们的这个 separation of concern 就是什么叫做关注点分离还是什么就是 HTMLCNC JavaScript

有些人是很教条的认为就是三个三个语言一定要分开来对吧然后呢后来大家发现哎不是其实不是这样的就 separation concern 不是说你要把语言分开而是说你要把你的一个逻辑单元分开所以 build 单文件组件里面其实是同时有 HTML CSS JavaScript 三个东西一起成为一个组件 react 其实他也是就是你把 CSS

和 markup 和逻辑全写在 javascript 里面了就是对吧对于一些很老派很老派的前一代的人可能现在年轻的开发者都不知道有这些人存在

他们在 reactv 刚出来的时候是很不爽的说你们这些年轻人乱搞对瞎搞什么一个组件把三个东西塞一起你们还要不要关注点分离了所以后来大家发现其实这个东西你关注的是一个逻辑单元而不是关注的是语言的分离其实延伸出去的话如果你把整个的前后端看成是没有区分的一个东西

那就是数据也可以成为这个里面的一部分现在就等于说是你的结构样式逻辑数据就是原来是我们把结构样式逻辑这三个纯前端的东西作为是一个单元现在数据也加进来了数据也可以成为你的一个单元的一部分但是你要做到这一点你就必须就是说你的整个框架对于你前后端用啥

后端怎么获取数据他都要管他必须得管他才能够做到这样的这个把数据也加到你的这个这个关注点分离的这个单元里面去就是那这就是一个你要不要去管的问题就是说从原则上来讲 Viu 是不想去抄帮你操这个心就是 Riat 说 Riat 现在其实等于说有点之前 Riat 一直说我就是一个酷我啥都别的啥都不管

什么东西都是生态去解决然后他突然来了个 180 度大转弯说现在我什么都要管我要管到你的管到你的服务器管到你的数据库就是这种感觉是吧就是所以其实从这个角度上来讲我就是往往前看一点就是当年我在 Meteor 干过 Meteor 当时做这个框架他也是什么都管他一直管到你数据库他强制你必须用 mongodb

然后用了 MangoDB 之后的优点是什么?你在前后端可以用同一套 MangoDB API 去拿数据,你在前端组件里面也可以用 MangoDB API,是同构的。其实就是跟现在 RS 想做的最终的愿景很像的。但是 Meteor 当时为啥没做完?那就是因为没有成功地活下去呢?

就是因为虽然现在理论上还活着其实就是原来公司已经把它卖给别的人去维护了就是最终为什么 Meteor 没成就是因为他当时等于说嗯当时愿意在后端跑 JS 的公司就少然后愿意用 mongodb 的公司就更少然后已经在用别的数据库的公司不可能为了你一个框架去把他们后端整个的架构全换了对这样的一个问题嗯然后这是这起然后

我觉得 server component 的另一个核心的问题是,它把你一个等于说它默认了你做一个应用的这个每一次请求你都要跑 server rendering 嘛,等于说你的很多的 server component 的组件是跑在你的这个服务端,包括你每次交互都要在 server 端跑东西,那你就 server computer 的这个 cost 的提这个这个增加,你会发现就是 Versoce 从来不提这个问题,

因为他们收钱的这个是他们掠钱的点吧但是他们就是不提的对吧这是这是一个 elephant in the room 但是大家从来是不提的就是大家都会说 IC 解决了我们开发范式上的这个这个这个问题 IC 给你的用户体验带来这个这个这个好处但是他不会提说你从一个竞开的 real app 切上 IC 你就要多付本是要好多钱就是这个问题其实我觉得就是

就是如果你很相信 Vercel 你很支持 Vercel 你可以去一厢情愿的相信说啊 Vercel 做 RSC 真的就是为我们好但是站在资本的角度 Vercel 是一个融了那么多钱而且有很强的盈利压力的一个公司他所做的每一个技术决策如果不是跟他的盈利意图相关的话我觉得就是 Vercel 自己都不会信吧就是啊所以所以就是我也是比较就是说嗯

我也不是对他们有敌意吧就是我只是很客观的从我的角度说我是一个比如说我要给我的公司挑一个 stack 然后我会考虑到用 IC 需要在本赛上多付那么多钱这对我来说一个很现实的考量的因素之一可能就是我宁愿就是说

尤其是对我的产品形态而言就是很多产品形态 RSC 也并不会有并不会带来很本质的体验的提升的会取决于它核心场景其实还是电商这种对于手平加载速度极致要求高而且是本身又是一个数据很多样化数据一直要求 freshness 而且每个用户看到东西都不一样的这样一个场景

这不是所有的人都是在做这样的应用所以这也是为什么我之前说它不是银代尤其是考虑到它在再加上就是具体我觉得这个它要解决的这个整体的一个问题就是说在能够让你顺畅的在组件里面把数据的这个需求作为一个你的代码切分的一个单元同时能够在呃

让你的真正 fetch 数据的行为能够离你的数据源更近也在服务端去做这个事情我觉得

这个是 make sense 但是他首先他并不是所有的场景都值得这样做其次是我觉得他们在纯粹的开发体验这一块还没有完全的把这个问题解决透就是因为你也会发现很多用 pages router 的人切到 app router 就觉得不行啊不爽啊用的不爽就是每天都在 mr 感觉在每天每天都在煎熬然后最后说哎呀这个受不了了 use client 一把说吧就

那你还用它干嘛呢对吧然后我觉得就是这个还是一个还要他们去慢慢去琢磨慢慢去打磨的一个东西吧我觉得还在一个比较早期的过程里面就是出于这个资本的这种需求会把它吹得稍微过一点我觉得

对其实至少这个是一个比较好的探索但是本质上 Born 和我 Sell 都是一个商业公司它肯定是为商业服务的否则它是对不起自己股东和投资人的这也跟社区还是不太一样的 OK 最后一个问题我也觉得是非常酷的一个问题就是如何保持如此高的颜值有什么保养的秘诀我都是想能不能让我长回点头发这是一个我很想知道的问题

年纪大了我说实话我老婆经常说我现在下巴比以前圆了很多我更年轻一点的时候下巴还是能够看出棱角的现在已经拍照看不出棱角还有就是经常看到你戴帽子对啊对戴帽子频率变高了大量的问题还是一个很现实的问题可以去植发

等我再多赚点钱再去指发写了 vue 但是直不起发对吧我们前面刚才从开始到聊到这会儿我们从聊了很多话题大体上我们从聊了一些技术产品我们围绕围绕围绕围绕围绕那聊了一些演进一些趋势一些背后的呃迭未来的一些迭代呃

以及背后的一些思考那么后面呢又呃围绕一些两个社区的呃两个作品的一个社区协作开源范围我们也展开聊了很多也谈到两个项目的一些相同和不同那我们也后后面呢围绕一些类似的前端的一些趋势一些呃特定的一些工具呃

生态那也展开了一些那个讨论那也涉及到前端相关的涉及到整个前端往后未来的一些展望这是整体前面的内容那我们进入下半部分就比较轻松大家可以往后躺一点的就是躺到椅子上的一些话题就是个人生活相关的

我看之前你也在 X 上提到过,就是前段时间像 VEW 像 VEW 上大会比较多,现在基本上都是允许线下去参与了,你感受如何?习惯吗?挺好的吧,因为其实是,其实我从 17 18 年开始,我就频繁的就是去每年可能要参加十来个会这种程度。

最多的一年可能有十多个会,然后到了疫情之后突然就啪一下断掉,什么都没有了,直接空白了三年,然后到去年开始总算又开始重新去参加一些会。但是这个中间有意思的就是因为疫情之后有两个娃了现在,

就是有娃的话其实现在我也不太好像以前那样什么一年十几个会这样就是所以我现在会比较挑一点就是呃也要考虑时差呀年纪大了挑时差也挺累的就是要考虑时差考虑飞多久然后考虑这个会有去多少人呢就是以及有些有些时候是比如说像日本现在就比较开心因为日本同一个时区呃或者说时区比较接近然后又比较近一些

而且日本这一次的会又是日本其实也挺挺那个的嘛因为 18 年办了第一届然后后来第二年遇到台风然后接着又是三年新冠然后这边这这个第五年终于办起又办起来了所以怎么说也得去支持一下嘛嗯然后嗯现在回美国会比较累一点回美国我现在要费 20 多个小时嗯就是有些地方我去我们去年那个去新二两

然后去亚特兰大是一趟要飞 20 多个小时所以争取就是回美国就一趟多去几个地方对然后这次国内呢说实话挺可惜的呀本来就是也是想着国内也是好几年没办了但是一些不可抗因素最后还是没成所以所以还是希望明年能有机会吧还是可以还是希望能跟国内的这些社区的朋友再见一见

我之前其实我也是今天早些时候我回了两个月上海在上海也见了不少这个老朋友了我在上海的时候质子和那个川哥也在对我们在不敢被用大家叫我川哥我叫我小川就好了我看大家都这么叫尊称一声川哥

那我们继续问嗯目前这个经历这个就是工作和生活分配怎么样然后经常累不累然后劳逸结合的程度如何我觉得还挺挺平衡的吧我现在就现在忙是确实是挺忙的但是我感觉还是就差不多正好就是工作时间全挤满然后基本上就正常的 work life balance 就是像周末我就

中文会比较基本上都是在陪陪娃就是带娃出去玩带娃出去上课在家跟他们最近教他们打乌龙然后对就基本上就是工作之外就是家庭嘛就这样了嗯

我们之前那个播客嘛然后也邀请到一些 veo 相关的那个维护者基本上也是从 veo.com 上的那个嘉宾那边也抓的也对他们之前他们感受接触起来感受如何像质子像川哥他们是不是挺厉害的刚才质子已经夸过了对吧

然后其实川哥是因为没有直接,就川哥应该没有直接贡献过 viewcore 所以我可能对川跟川哥的直接的这个就合作会比较少一些就是我们其实有一些其他的几个贡献 viewcore 比较频繁的这个也是国内的一些小伙伴有 Edison 然后还有那个白雾这几个是印象比较深刻一点还有那个

还有几个 ID 什么张中和 Alfred skyblue 这些那也是国内的小伙伴我觉得啊对国内这边还是有挺多熟面孔还有对我觉得对年轻人对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对对这 还有 还有 年年年年年年年年年年年年年年年年年年年年年年年年年年年年年年年年年年年年

就其实有一些 PR 其实我也挺那个的因为有我搞 meet 的时候有几有几个像他们提了很多 PR 可能就我就晾在那边晾个几个月之类的就其实也挺不好意思的所以我是希望就是质子可以重新调动一下他们积极性 push 一下质子对吧对我最最后说说敢说的敢说这个反而是之前之前是反向 push

赶紧上班公开在推特上面 PUA 老板别喝酒了继续了最近忙什么最近有什么想学的吗技术类的或者非技术类的

最近啊最近哎就其实我一直一直想在在自己多写点 rust 但是说实在是没时间对 Rust 现在学的怎么样已经我感觉我感觉我就只是能看懂基本代码的这种程度吗就像什么 borrow check 这种我还我觉得还不太行嗯

这个 RUST 也是我们很多人在关注也是提出了对应的问题你觉得前端有必要学 RUST 吗你觉得有哪些场景是需要去学 RUST 的或去使用 RUST 的我觉得你不是搞基建的我觉得学 RUST 其实是没什么大用的因为 RUST 这个语言它的侧重点跟 JS TS 完全不一样大家确实是为了不同的业务场景而生的语言

那是本身是一个系统级语言然后再加上它本身是适合这种你的要解决的问题比较的明确比较固定然后你需要用最高效率的方式去解决它我觉得会比较适合但你在比如说前端做业务的场景根本就不是这样的需求对吧还是看你要解决的问题是什么再去选择

对对但是其实对于就是不单单是前端来说 Rust 我个人觉得还是一门就是需要去个人对个人来说需要去学的一年

就了解了解一下肯定是没坏处的就是嗯我这边朋友推荐也是说开阔一下视野就觉得还能这么玩那种感觉就是感觉我身边一群朋友都会 russ 我有点有点压力然后 russ 的生态里面有一些东西也是很值得学习就比如说 cargo 一下子把所有东西都解决了这种对其实我们也

将来我们也希望可以做一个给 JS 生态提供这样的一个这样的东西但 JS 对我来说就是它会比较分散它是一个太开放的社区对就是 JS 现在其实是有收敛的就是我觉得是到了一个可以适当收敛的一个时间点尤其是对于

一些比较稳定的大厂或者企业级的这种场景的话我觉得适当的收敛一些反而是可以更好一些吧就是说生态的活跃是有价值的但是就是说这种对于很多大厂的基建来说要自己去把持续的把一些很很琐碎的这种生态里的东西去整合成一条东西我觉得还是

就带每个每个厂都要自己做这么一遍其实还是挺有很多浪费的地方其实我觉得从帮到的层面来看 vita 就是一个不错的收敛对 vita 就是一个收敛的秘词嘛对下感觉合适的在合适的抽象抽象层面去收敛

就是我我觉得前端是有这么一个一个循环就是大家从呃一个比较不确定的地方然后比如说分散出几条路线去做不同的尝试然后在一个合适的阶段我们再把这个最佳时间直接拿出来整合成一个更好的东西嗯那既然是闲聊我也问一个比较大家都比较关心又比较俗的问题一晚可以简单答一下就是如何看待大模型

大模型,我觉得日常使用其实确实挺有用的,我自己也是 ChatGPT Pro 的付费用户,但我就发现在实际写代码的时候,跟你写什么代码很有关系,就是写搬砖的代码我觉得大模型,

帮你搬砖很有效率但是那我写的代码大模型基本上帮不上他了就就很多时候我只能是真的是写到一个很具体的工具函数的时候我可以让他帮我写一个但是我真的是在搞这种思路的时候完全没什么用就是对嗯就是他适合去解决一个比较具体的问题对对对但是对于想一个 idea 他是没有办法对就是说嗯

也是受限于现在大模型的这种 prompt prompt base 的交互模式嗯我觉得可能以后还会产生这种 prompt base 模式之外的这种利用 a 利用大模型的方式吧才能帮你解决更高层面的问题就是现在其实你看就是说最近挺火的那个 tldr draw 就是

那个叫什么 make realmode 它本身是一个白板工具然后你在白板上面画一个界面然后在旁边注释说用 tailwind 实现这个然后一拉 make real 啪它就直接给你出来一个就直接用 tailwind 实现的一个界面它底层其实也是用 openai 的大模型

就是他只是把你的输入去把它调成各种各样的 prompt 然后把它吐出来的代码给你渲染出来而已就是本质上还是在调 LbA 的东西我觉得就是说甚至你会发现在界面设计这一块比如说像 Versa 的 V0 我也试过了说实话也就这样吧有点一般甚至对就是有点一般

嗯怎么说呢就是说他作为一个 proof of concept 是挺酷的但是你说我真设计一个网站我会用他来设计吗好像不太行就是这种感觉要跟他说太累了不如直接写代码对就是其实我最近也在重新设计一个页面嘛然后我是跟一个比较靠谱的设计师在合作就这个设计师设计出来的东西

这真的是我觉得你现在任何 AI 基于 AI 的东西你要给我搞出这个来做不到的不可能就是所以就是呃我觉得在每个领域现在就是最我可能觉得觉得就是对 AI 现在最受冲击的还是这种文书这种一个是文书这种东西另一个是这种呃就是一些比较对于对于独创性要求没那么高的图片生成这两块确实是

就是确实是就是说它是一个非常适合的用力而且也确实就是把这个原来做这些活着人的活真的是就抢了但是我觉得在很多有需要创造性或者说需要有高层次的设计的经验的这种东西上来讲大模型目前还是一个很很糙的一个阶段嘛就是

就刚刚一般提到那个点也是就是其实大模型之前就有了只是大家不知道怎么去用怎么去激活它然后 openit 说这种 chat 就是 prop 的 base 的这种激活方式交互方式所以但这是正确的方式吗这是最好的方式吗不好说未来会不会有其他去激活大模型让他让他的智能涌现出来的方式可能也会有

那其实呃新宝我们答一下素问素答一下还有两个听众问题嗯 okok 呃其实这里还有两个听众问题一万可以简单的素素问素答一下一个是 vue js 到今年也快十年了就是一万如何去保持这种对编程的热情这个的话我觉得说实话也没法刻意保持吧就是我实话实说其实这些十年里面也是有相当多次就是某个阶段我会

就觉得很累,然后就不太想写代码,然后我就可能去休假或者是玩游戏啊,就天天玩游戏,也有这样的时候的,我觉得其实真的就是,因为有些这种事情我也你也不会主动在社交媒体上去告诉别人,对吧?但是但是说实话,就任何人做一件事情,你长期的做一件事情,你是

大家都会有一些比如说 burn out 或者说迷茫的时候或者说就是觉得单纯的很累就是想休息一段时间都会有的我也是中间也会就十年中也多次经历过这样的这种状况这样的阶段甚至是 Sam Altman 就 OpenAI 刚被开的 CEO 他自己也说过他说我有段时间就是天天打游戏打到凌晨几点然后睡到下午起来

就是有的事情就不知道自己该干嘛就是我觉得再牛逼的人都会有这样的时候所以我觉得就是没法保持一直保持百分之一百热情很正常就是就是人就是起起伏伏的嘛但是就是可能你调整过了一段时间你最终就是说还是这个东西因为一开始就是你感兴趣了才去做这个事情就是所以你调整了一段时间之后也会慢慢的哪天又突然就是说哎

这个东西好像可以这么写一写然后写着写着然后又开始不知不觉又写到凌晨然后你就发现哎我又进入状态了然后你又开始开始开始写这些东西就是我觉得有的时候你刻意去调整都没用的就有的时候你会越刻意反而越进不了状态但是突然哪一天不知道为什么就就突然又开始又又又能进入状态了这个就是就没有什么太理性的这种这种或者说没有什么太多的

理论化的东西可以分享这个东西要自己调整的对其实对我来说也是差不多我一般是因为我感觉我写代码应该有 10 年然后其中我其实也是碰到像 Evan 说的那种状态但是我还好的一点是因为互联网是信息比较多的比如说今天 ROA 发布了一个 breaking change 或者说发布了一个

我比较感兴趣的 feature 我可能就从一个比较 down 的状态看一看然后就好写一个什么什么这种感觉就兴趣就一下子就又有了因为前端这个生态是比较就甚至是太过于活跃了很容易从某一个事件中就找到自己感兴趣的东西

是的而且咱曾经某位嘉宾说出过很神奇的话如果他做完大大活之后会拿一点小的小的作品会开发奖励奖励自己其实我猜是安森林富对对对嗯哎其实我也是就是现在说实话我现在就有的时候会想就当年还在比如说学校里的时候

就真的是想写啥就写啥的那种感觉还挺好的就没有那么多我现在说实话我现在一个负担就是说我在写一些单纯满足自己兴趣的东西的时候会有一种负罪感就是说哎呀还有一堆 pr 没看哎呀还有一个什么这种更大的问题我还没有去解决我怎么能在这边写这种就是

比如说自己完全满足自己兴趣的一些东西比如说什么搞搞自己套个壳搞搞去 hpt 或者说什么写一个这种好纯纯好玩的工具库这种现在就以前是等于说做这个东西觉得还能放上 github 还可以混骗点心情现在觉得说这个事情好像对我没什么意义了我就

反而就没有这个动机去做这个事情了但是又觉得挺可惜的因为这种东西确实是挺就很就是像一个 hobby 一样就像个就像兴趣一样的东西

开一个小号从头来过对我也想说开小号就是一个是你做 view 和 vit 的一个责任感你感觉要回来去去做推动这个事情一个是感觉叫什么混这么多年了要再发一个 toy project 大家可能会觉得你是不是又要有新方向了会让有一些误会那种感觉

确实也有一方面这种压力因为不停的会几乎每一次这种 Q&A 大家都会问的一个问题就是你接下来想干吗有的时候我想干的事情基本上都已经告诉大家了或者说有些想干的事情我自己也都不知道这个事情到底能不能成也不想太早

就是说给大家画一个太大的笔是吧所以这个东西就是还挺纠结的就是对我感觉大家问也是这种钱的发展太快的压力就经典不知道要学什么怕我又给大家挖开了不要再出威又一四了学不完了学不动了学不动了

所以你看我最近一直跟大家强调我们要求稳定我们不会再搞这种大的范式的改变叫什么多跟一万说说真的有用他真的不出 VU14 了至少在这两年应该是没有好官方成员质子说两年不出 VU14 你们有没有听说他话中有话意思说以后还是会有四的

我以为说两年不出就是明年出最后一个斯文斯答问题就是 GitHub ID 的那一串数字是有什么含义吗那个是我初中的学号很多人以为是你的生日对对对

我之前一直以为你是 99 年的因为我们听友中我们刚才也问了就是我们听友中有很多年轻人在学大学生还有也有刚就参与前端没多久的人然后如何参与开源我们在前面也提到了那从如何学习前端或者如何精进前端的水平让自己变得更厉害你有什么过来的经验或者说给他们一些指导我觉得这个是一个很

兴趣驱动的东西就是我一直认为就是呃兴趣是一种天赋就是因为很多时候你在一个领域的提升取决于你花了多少时间去钻研吗对吧然后但是对于有些人来说强迫自己去钻研很累很痛苦但是对于有些人来说钻研一个东西就是乐趣他觉得说我

就是给我一天 12 个小时都不够我就天天可以搞这个东西这其实就是一种天赋其实我觉得对吧所以你你如果能够进入那种说专业的一个东西一天我觉得说啊时间不够用我还要继续搞那这就是说明你就是生来就是干这行的你就可以在这一行去干的就是说能够提升但是嗯如果说你觉得就是说强迫自己去去研究一些工作之外的东西很痛苦的话呢

我觉得这个可能就是说就一个比较不好的消息就可能说你在这方面如果没有充足的兴趣确实很难支撑你长期的在这个领域去精进下去所以说这深深的热情是很重要的对我基本上就是学东西也好做东西也好是一个兴趣为导向的路线

所以我我总的来下来说还是就是学的比较快的所以这也是一个天生的动力我觉得兴趣是一种天赋这个真的是

我一直有类似的观点但是好像没有浓缩成一句话就是如果你感觉你在下班之后再去学前端是一个非常痛苦的事情那我觉得这不是你的兴趣你去找你自己真正的兴趣以及有可能是很难找到兴趣点其实对很多人来说所以我觉得我们可能是幸运的我们找到了编程并且他是可以让我们养活我们的一件事

因为我在读书的时候我看到一句话我真的觉得非常有共鸣就是他们让我去做世界上最有趣的事情然后甚至愿意付我钱就是变成对因为这个可能就是涉及的更广一点就不仅仅是一个如何在你的职业道路上更进一步就是说从我个人的人生的一些经验来说就是说你想要过得开心你得让这个你

你用来糊口的这个事情跟你的这个跟你的兴趣能够契合这是一个很大很大很大的一个 utility bonus 就是中文叫什么呢就是说因为本质上你还是你过日子是要让自己开心就如果你做一件你自己不开心的事情最后还要再花钱再去让自己开心那还不如你宁可少赚点钱做一件让你自己能开心的活这是一个更划算的买卖可能是

感觉可以翻译成原子满足最小化的满足就是有 txt 在经济学里叫效用吗嗯 ok 呃呃我这边这个问题问差不多然后看看各位呃小白菜开意我我没有其实今天光是能来听听游老师讲话就已经很开心了

你你刚才之前不是那么什么你不都喊着祖师爷吗哈哈哈哈成有老师了怎么怎么看待别人好像都对你的这个昵称很多很多哎我觉得祖师爷这个是绝对是不合适的了因为哈哈对吧这个我祖师爷这种你得追溯到比如说像什么高利贷

编程这种对吧对你你网上一直可以追逐比如说你说前端你这个前面还有什么像 java script 的这个开发者对吧有 brand and neck 然后你在说编程语言的这个开发者那 java script 还抄了 java 那是不是 java 是 java script 的这个组事业对吧然后在一路追溯上还有 c 然后还有这个什么

所以说我觉得这个祖师爷这种称号肯定我是担当不起的所以其他的我觉得更多的就是大家如果只是一个单纯的作为一个这种昵称的话我觉得我都是无所谓的我觉得原因可能是因为

因为因为 view 这种框架确确实实给了相当大的一部分人一个工作机会所以很多人叫你主事业其实是有他们的想法的对就是我之前在开发 element plus 的时候就是我们那个 team 基本上含理就叫主事业因为我们就好像是在 view 下面做的一个框架然后给了一个范畴

对是然后还有一些昵称就可能显得不是那么的友好比如我我我昨天也听过了我真的没没听过其他的昵称你需要我说出来需要我打出来哇攻击这么强吗

我觉得组师爷一个点是因为呃 Viu 相对入门入门上手会会容易一些其实给了很多这种呃可能对这种代码他也没有对对编程技巧没有那么娴熟的人也找到了一个不错的岗位不错的工作学了他有饭吃对我觉得这个真的对真的叫什么功德无量的一个事情嗯

好我们刚才聊得很开心我们刚才大概都有快两小时我们刚从整场讨论围绕还是两个艾文出的两个那个作品那 VUGS 和 WIT 那我们围绕这两个作品从技术的一些演进一些思考展开了一些讨论那也围绕这两个作品背后的一些那个开源协作的生态展开了一些讨论

后面也围绕艾文最近的一些生活状态和一些对前端的发展一些思考也展开了一些讨论这是整场全部内容我是聊非常开心的星巴奥特小白菜我是再次非常激动能够和尤大一起聊播客的小白菜开意我是听完整场之后真的成为尤大的粉丝然后今晚就 remove react 所有框架

Smart 我是坚持学到 v4 的 SmartOK 智子我是 PUA 老板的智子川哥我是一边听着尤老师讲话一边默默改完了 VT5 中文文档的小川对鼓掌鼓掌鼓掌鼓掌鼓掌 OK 准备发 PR 我是

没想好什么梗啊不会玩梗的 EvanOK OK OK