Starlight 0.42：用更少的JavaScript，做更健壮的文档站——这是一个关于「回归本质」的哲学故事

Astro的官方文档框架Starlight在9月2日发布了0.42版本，名字叫「Less JavaScript, and more JavaScript, all in one release」。这个标题本身就挺有意思的——一边说「减少了JavaScript」，一边说「又增加了JavaScript」，这不矛盾吗？

还真不矛盾。

发生了什么

这次更新有两个核心改动，正好对应了标题里的两个方向。

第一个：「减少」面向用户端的JS。

Starlight的移动端菜单从原来纯JavaScript驱动的实现，切换成了浏览器原生的 Popover API。这意味着什么？

简单说，以前移动端菜单的展开和收起是由一段JS代码控制的，如果你的浏览器禁用了JS，或者JS加载失败了，菜单就打不开了。而Popover API是浏览器内置的原生能力，不需要JS参与——菜单在JS完全不可用的情况下，依然可以正常开关。

Starlight官方放出了一个演示视频：他们在开发者工具里强制禁用了JavaScript，然后打开手机模拟器，发现导航菜单依然能正常使用。

这个变化很小，小到很多用户根本不会注意到。但它的意义不小：健壮性不是一个功能，而是一种设计选择。 追求「无JS也能工作」不是为了炫技，而是对真实用户负责——有人在地铁里信号差，JS可能加载不完全；有人在用隐私插件屏蔽脚本；还有些无障碍工具本身就不运行页面JS。给这些场景留一条退路，是好的工程实践。

第二个：「增加」的是项目自身的构建复杂度。

Starlight这次把自己从TypeScript源码发布切换成了编译后的JavaScript + 类型声明文件。听起来好像是多此一举，但实际上是有代价要付的。

原因在于：npm上分发.ts源文件，用户安装后在编辑器里运行tsc类型检查时，会把node_modules里这些TypeScript文件也一起检查一遍——用你的tsconfig、你的配置。这不仅慢，有时候还会跟用户的配置冲突，导致一些奇怪的问题。

所以Starlight这次选择了把自己的源码编译成纯JavaScript，然后附带上独立的.d.ts类型声明文件分发出去。对用户来说体验更好了（类型检查更快了），但对Starlight团队来说构建流程确实复杂了一点。

这个取舍本身就很有意思：「我多做一些，用户少烦一些」——这其实是开源项目最朴实的产品哲学。

还有两个值得注意的改进

Sidebar数据处理速度提升了1400倍。这对文档站点来说是个大数字——如果你有一个内容很多、层级很深的导航侧边栏，之前的处理逻辑在大规模场景下会卡，现在直接快了三个数量级。对用户来说感知可能不那么直接，但对有大量文档内容的站点（比如一个开源项目的所有历史版本文档）来说，这是实实在在的体验提升。

另外，Starlight这次更新还要求了更高版本的Astro（v7.2.10+），连带把内部依赖的Markdown处理器Sätteri也升级了。这意味着如果你用的是老版本Astro，升级Starlight 0.42会连带升级一整条依赖链。

「少即是多」的前端哲学

说了这么多，我觉得这次Starlight 0.42最值得回味的地方在于它呈现了一种前端世界里越来越清晰的趋势：

当浏览器原生能力（Popover API、View Transitions、CSS等）越来越强，「能用原生解决就不用JS」正在从一种小众极客偏好，变成主流工程实践。

这样做的好处是：更少的JS意味着更快的加载、更低的解析成本、更稳定的行为。坏处是：你需要了解这些浏览器API，需要处理兼容性问题，需要理解能力边界在哪里。

但对于做内容网站——尤其是文档站——来说，这个取舍是值得的。文档是给人看的，而人用各种不同的设备、网络环境、浏览器配置访问你的内容。让内容在更多条件下可用，比让页面多两个花哨动画更重要。

结语

Starlight 0.42不是什么大版本，没有颠覆性的API变化，但它身上体现的这种「用更少代码做更健壮的产品」的设计思路，我觉得值得所有做内容站点的开发者想一想。

尤其是那些还在用老框架、堆了一堆JS做交互的站点——也许可以问自己一个问题：如果把JavaScript关掉，我的网站还能用吗？

如果答案是「不能」，也许值得看看Starlight是怎么做的。