我一直觉得 Vite 在目前的阶段，最有竞争力的使用场景就是作为各种 meta frameworks （元框架，如 Next.js、Nuxt.js）的底层：

* SSR 支持是 Vite 的长项，在如今前端纯 ES module / Node 端 CommonJS 与 ES module 长期混用的分裂生态下，Vite SSR 踩了非常多的坑，现在的实现足以弥合多数差异；
* ... 展开

Shopify 刚在 Unite 大会上发布了 Hydrogen 框架，基于 Vite，内建 React Server Components (不是 SSR) 支持 网页链接

个人感觉这个使用场景非常符合 Vite 的定位……开发体验一定比基于 webpack 的 React Server Components 好。期待能看到内部实现。

发现一个有意思的项目：OldOS，在 iPhone 12 上体验 iOS 4。
整个界面都是用 SwiftUI 复刻的，其中大部分内置 App 的功能都真实可用，甚至可以当作第二系统来日常使用。
作者 Zane K，目前 17 岁，在纽约上高中……

代码是完全开源的：github.com/zzanehip/The-OldOS-Project
TestFlight 地址： ... 展开

「不要用 export default」这个说法是有时代背景的，现在 JS 生态面临的问题和当年已经不一样了，export default 带来的问题迟早都是能被工具解决掉的（注意正确使用 package.json 的 exports 字段）。
而现在真担心兼容性的话，可以先从避免 module.exports = {...}做起
考虑有空写篇文章讲讲。有兴趣 ... 展开

补充：不要想着靠「不用 export default」来规避 JS 模块规范的坑。默认导出都不能解决好的工具，难道处理命名导出时就不会有坑了吗？语言既然提供了这个功能，该用就用，没必要为一时的工具问题改代码风格

这种问题最烦的一点是，处理起来极靠经验，但心里清楚再过几年这种经验就相当于现在的「精通各个版本 IE 区别」，即使好不容易解决了也不见得多有成就感……

今天维护 Vite 时定位到（还在修）的两个 bug：

1. 一个 npm 库，源代码是 TypeScript，其中引用了一个外部 ES module，然后库本身先被 tsc 编译到 CommonJS，再由 webpack 打包成 Web / Node 通用的版本发到 npm，最后在应用中用到时，当 ES module 引入，由 esbuild 整体打包。

由于包了三层模 ... 展开

又一个 CSS-in-JS 库，vanilla-extract，主打类型安全、零运行时、基于 CSS 变量的主题功能，来自 CSS Modules 的发明者之一 Mark Dalgleish。
试了下还挺有意思的，有官方 Vite 插件可用。

说起来 styled-components 就是 CSS Modules 的另一位共同发明者 Glen Maddern 搞出来的。

一直觉得纯 JS 的 ... 展开

Vite vs Snowpack