053

buildinpublic

最近周末花时间在做一个工具，起因遇到一个问题，我使用 SWC 编译一个 monorepo 的项目的时候，目标项目依赖的子包并不发布，我经常要提前把这些子包和目标项目一起打包。而在我使用 TSC 时候，这一切似乎是自动化的。因此，我打算写一个工具，底层使用 SWC，配置文件使用 tsconfig.json。让使用者并不需要提前指定要编译的文件，而是通过 glob 的语法，同时解决 TSC 编译时并不能自动替换 alias 和 extension 的问题，也支持原生的 SWC 插件。

工程师

https://www.infoq.com/presentations/hydration-lazy-loading/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=JavaScript

这个文章太棒了，介绍了几乎所有框架能够用到的优化手段（除非未来有新的技术），比如像是懒加载，渐进式水合等。其中有些结论蛮打开思路的，大家都知道水合很慢，但是对于 SSR 来说很必要，如何加速这个流程呢？这个文章主要是在说这个。以下是观点：

渐进式/部分水合可能没什么用，因为你还是需要下载全部代码，并且从 root 开始便利找到需要水合的部分，这点和没做渐进式水合没什么区别，使用的代码数量并没有减少。
懒加载更打开思路了，懒加载仅仅对那些在首次渲染没有使用到的组件有用，如果某些组件在首次渲染时候用到了，但是懒加载了，会导致水合变慢，因为它需要等待这部分代码，另一句话说就是你把关键代码懒加载了，这并不是一件好事。但是路由懒加载是有用的，因为除了当前路由之外，其余都不在当前的 render tree 里面，自然会加快水合速度。所以就有了 prefetch，但是比较难的时候 prefetch 什么，往往没有一个自动化的过程，prefetch 下个路由需要用到组件或许比较容易，但是当前路由需要的更加细微的组件往往比较难，所以 qwilk 做了类似二次收集的事情，就是第一次，往往比较慢，收集完毕之后，第二次就会 prefetch 了。说白了，这个 prefetch 的工作最好能自动化。
代码减支 = 服务端组件，服务端组件相当于把部分代码从客户端移动到了服务端，某种意义上就是代码减支，但是除了这种实现之前，编译阶段 svelte 等框架还有做到其他的实现。

https://github.com/bigskysoftware/idiomorph/blob/main/README.md#htmx

看起来是一个 DOM 更新比较的库，如果有尝试自己实现渲染框架的话，看起来是比较好的选择。