看了尤雨溪的直播，聊聊过程和感受

关注公众号 前端开发博客，领27本电子书

回复加群，自助秒进前端群

在掘金上看了一场尤大的直播。

怎么说呢，我很享受这种氛围。和一群志同道合的朋友，看同一个东西，然后各自发表自己的意见和看法，这种感受与看直播发弹幕很不一样。

我进入直播间的时候，直播已经开始了十多分钟了。尤大正在如数家珍的吐槽 React hooks 的缺点：心智负担，闭包陷阱，useEffect 的依赖项等等。

不过对于这些吐槽，我有不同的意见。闭包陷阱的由来在于大家对于闭包的理解不够深刻，因此在使用部分 hooks 的时候，对于某些闭包的产生无法感知到。实际上闭包陷阱的逻辑如果成立的话，并不仅仅存在于 React hooks 中，而是存在于 JavaScript 的所有可能出现的场景。特别是匿名函数这种弱感知的场景。

useEffect 的依赖问题其实在我看来不仅不是 hooks 的缺点，反而是 hooks 的优点。我在新书 《React 知命境》最重要的一个章节《React 哲学》中专门介绍了这一特性。useEffect 的依赖项能够帮助我们监听单一数据以驱动多个数据，于是我们就可以借助这个特性完成单数据驱动多数据，再由多数据驱动 UI 的开关思维。能够极大的简化我们的开发，提升开发效率。

开关思维是我个人独创的开发概念，指的是由一个数据状态驱动多个数据状态，再由多个数据状态驱动 UI 的设计理念。

useEffect(() => {
  if (refreshing) {
    http.get(api).then(res => {
      setList(res.data)
      setRefreshing(false)
    })
  }
}, [refreshing]) 
// refreshing 发生变化时，useEffect 回调函数必定执行

// 开关回调就变得异常简单
function onRefresh() {
  setRefreshing(true)
}

// 使用时，可用使用非常简洁的代码实现复杂的交互逻辑
function App() {
  const {refreshing, incresing, list, setRefreshing, setIncresing} = usePagination(api)

  return (
    <PaginationList 
      list={list}
      refreshing={refreshing}
      incresing={incresing}
      onRefresh={() => setRefreshing(true)}
      onIncrese={() => setIncresing(true)}
    />
  )
}

尤大又介绍了 Options API 和 Composition API 的优点。

Vue3 与 ts 的结合

第二个问题探讨的是 vue3 与 ts 的结合不够完善的事情。主要是 props 的定义方式与泛型组件的问题。

只能说，提问的朋友确实比较尖锐，属于哪壶不开提哪壶的典范。尤大侧面回答的这个问题，也认可了存在的问题。对于这个问题其实在知乎就有非常好的探讨，尤大本人也参与了。大家可以在这里去深入了解一下。

https://www.zhihu.com/question/453332049

Vue 3 跨端

许多朋友在期待 Vue3 能够提供一些官方支持的稳定维护的跨端方案。这里就要让大家失望了，尤大明确的表达了 Vue 团队没有精力去做这些事情，只有公司级别的体量才有能力去做，因为跨端的支持确实很复杂。

不过这个时候尤大一句带过踩了一下 uniapp，所以技术选型准备使用的可能要稍微小心一些，群里也有小伙伴在吐槽 uniapp 的坑点，比如 css 只支持类选择器等等。

除此之外，尤大介绍了 Vue 一个非常强大的特性：vue3 直接暴露了一套自定义渲染器的接口，理论上可以接入任何渲染目标，比如有个团队的小伙伴正在接入一套很炫酷的命令行 UI。

如何加入开源项目

几位大佬对于开源的讨论挺多的。月影认为开源项目的复杂并不低运营一个公司低。郭辉认为搞开源需要有热情，初衷单纯一些，因为可能没有回报，甚至还要义务去解决很多 issue。加上许多使用者态度并不是那么友好。

对于尤大而言，他更在意的是你能够持续的为某一个项目提供优质代码，就能够很大机会加入该开源团队。

尤大潜台词：都来给 vue 干活吧，哈哈。

Vue -> canvas

这个问题其实非常有意思，理论上是可以实现的。但是这种方向其实有点类似于跨端方向的一种，尤大认为浏览器实现这些能力其实花费了很多精力，言外之意就是说，可能 Vue 并不会考虑这个事情。

我们其实也可以思考一下这个实现的复杂度，例如，我们需要有 vue 组件结构，需要有样式标准，那么就额外需要实现一个组件解析器和样式解析器，需要将两者的解析结果合并计算成为类似 render tree 的东西并渲染到 canvas 上。这个过程确实比较复杂，也是浏览器底层原理实现的一套解析和渲染的机制。

状态管理 vuex5

很可惜尤大并没有介绍 vuex5 的特性，只是介绍了相关的背景。我不是 vue 的深度用户，所以没听出来什么特别有用的信息。

vue3 的缺点，vue4 新的变化

对于这个问题，尤大明确的表达了 ts 方面还需要再完善，包括泛型与 slots。

除此之外，vue3 过于在意大型项目的可维护性问题，导致了在特别轻量的嵌入式场景反而显得有些笨重。因此后续会出一个非常小的只有 6KB 左右的 petite-vue 来解决这种场景的应用。

最值得期待的是，尤大明确的表示了 vue 会借鉴 solid 的编译模式。了解 solid 的朋友应该知道，那将是一次巨大的性能飞跃。

solid 是一个摈弃了虚拟 DOM，走编译型路线的框架，别的不说，他的性能是能吊打目前的 Vue 与 React。因此如果 Vue 真能做到借鉴这种模式的话，性能上的表现是非常值得期待的。

月影：前端技术新趋势

在聊前端技术新趋势的时候，月影大佬扯了很多历史，大概针对 web1.0 和 web2.0 都做了一些描述和感受。比如 web 1.0 的只读特性，web2.0 的强交互，我觉得都谈的非常到位。我心想，花了那么多时间聊前世今生，那肯定是要聊 web 3.0 的一些展望了预判吧，然而，我等了个寂寞。

结果他只是针对网速越来越快，前端的项目会越来越重这个点出发聊了一些内容。并表达了技术虽然变化莫测，但是万变不离其宗的核心哲学。

说得很有道理，不过多多少少还是有些失望。

郭辉：低代码，无代码

说实话很多小伙伴都在关注低代码，甚至有的焦虑型选手在担心低代码的推进会不会影响前端程序员的饭碗。郭老师用简单明了的表达打消了我们的顾虑。

他说确实有很多团队都在尝试低代码，甚至有一些财务公司「我怀疑他说的可能是金蝶」在低代码做得非常成熟，但是呢，大多数团队都做得不是很好。主要的原因在于许多场景业务逻辑比较复杂，不通用，无法抽象。也就导致了低代码的实现成为了一种愿景。

许多团队在攻克组件渲染这一层的东西，但是实际上这些都是比较简单的，不是项目的核心痛点。也就是说，郭老师觉得他们的方向走错了。

低代码仅仅只适合逻辑抽象比较简单，比较通用的场景。例如发票。业务逻辑抽象比较容易。toB 的业务逻辑是无法解决的。

无代码，低代码，早在很多年前，在其他语言有其他类似的概念场景和应用。郭老师也提了一个非常有用的概念：我们应该适当跳出前端的圈子。甚至不要局限于技术圈子。

我深表认同。

尤大：前端新技术的看法

国外国内对于低代码的看法不一样。国内搞低代码的大多数都是一些大厂，为了绩效什么什么的「哈哈哈，含糊的提了一句，懂的都懂」

国外呢，更多的是小厂在搞这些。

不过尤大提了一个我很赞同的观点：不同的阶段，关注的东西应该是不一样的。比如初入前端，关注低代码没太大的必要。更应该关注自身能力的提升。

其实尤大在新技术这一块，给我们提供了一个非常好的展望。那就是前端工程化的变迁。当项目变得更加复杂，更快的开发性能成为了我们的追求。他列举了一些例子。

使用 rust 重写 postcss，用于快速处理 css AST 的转换。这种场景使用原生语言去写，收益回报比比较确定。

当然除此之外，还有我们熟悉的 esbuild，使用 go 语言编写。工程化的变迁已经慢慢的渗透到了我们的项目开发者。

这其实是对于高级前端工程的一次大的挑战和机遇。

除了工程化之外，尤大也提供了一些原生化场景的决策思考，对于业务逻辑，迭代速度，灵活性，稳定性，性能等多方面去聊了对应的场景「图像处理、前端框架」是否适合原生化。

例如在框架层面原生化是否合适：一部分计算快了，但是与DOM的通信成本更高。实现成本也更高了。所以用原生语言写一个模块，获得明确的性能提升。抛弃 JavaScript，all in WebAssembly 是不现实的。

程序员未来的出路

对于这个问题，尤大并没有提供什么有参考价值的建议。

他也直接表达了个人经验参考价值比较有限。比如找到机会做一个用户量比较大的开源项目是一次偶然性事件。能力虽然是前提条件，但是运气占很大一部分。

他觉得自己是比较幸运的。做 vue 的时候，前端刚好处于一个刀耕火种的年代。

并且给了一些建议，如果要做一个产品卖给某些团队的话，应该更多的关注海外市场。

整体看下来，还是有一些收获，不过，最大的收获就是几个群人同时在群里吐槽这些大佬的欢乐。哈哈。

我是这波能反杀，关注我解锁更多前端技能！

最后