Jim Nielsen 这次复盘的点很小：一个博客菜单。

常见做法是点一下按钮，JavaScript 展开弹层或侧边栏。Nielsen 的做法更“老”：菜单不是弹层，而是一个独立的 /menu/ 页面。打开菜单，就是跳到另一个 HTML 页面。

有意思的地方正在这里。

过去很多站内交互，默认会被做成组件、状态、动画和客户端路由。但在个人博客、内容站、文档站里，有些交互可能根本不需要这么重。一个链接就能完成的事，不一定要先交给 JavaScript。

这不是说 JavaScript 多余。Nielsen 也用了少量 JavaScript。更准确的判断是：在轻量网站里，浏览器本来就擅长“从一个文档去另一个文档”，不要太早把它改造成应用运行时。

菜单页的核心：把交互还给链接

Nielsen 的菜单实现很直接。

普通页面上的菜单按钮，是一个指向 /menu/ 的链接。用户点击后，浏览器进入菜单页。菜单页里原来的按钮变成“X”，也就是关闭按钮。

这个“X”本质上仍是链接。默认情况下，它指向首页 /。

为了让体验更像“打开—关闭菜单”，页面再加一小段 JavaScript：如果 document.referrer 显示用户来自站内页面，就执行 history.back()；如果用户直接打开 /menu/，那就回到首页。

这段 JS 的作用很窄：少污染一次浏览器历史。它不是整个交互的地基。

CSS View Transitions 也是增强，不是前提。支持它的浏览器可以看到更顺滑的页面过渡；不支持的设备、旧浏览器，甚至禁用 JavaScript 时，链接仍然能用。

这点很关键。降级不是事后补丁，而是这个方案的默认形态。

路线怎么做适合什么主要代价
页内 JS 弹层用脚本控制菜单显示、隐藏、动画和状态状态复杂、交互密集的产品要维护状态、组件、异常和降级逻辑
多页面 HTML 导航把菜单做成 /menu/，用普通链接跳转博客、个人站、轻量文档站页面必须小，跳转必须快
渐进增强用 View Transitions 和少量 JS 改善体验想保留链接兜底，同时要更顺滑不能把增强能力当成必要条件

我更在意的是这个顺序：先让链接成立，再谈动画和脚本。

很多前端实现的问题，不是用了 JavaScript，而是把所有问题都先翻译成 JavaScript 问题。菜单、筛选、切换、返回，有时只是导航问题。

对前端和站点维护者，影响是两套动作

这套做法对复杂应用不是通用答案。

在线表格、设计工具、复杂后台、实时协作应用，通常有大量本地状态、权限变化、输入过程和多人同步。把它们拆成一堆小 HTML 页面，并不会更简单。那不是克制，是把问题搬到别处。

但对个人网站和轻量内容站，这个思路很实用。它能直接影响开发者怎么下手。

对象更现实的动作不该误读成什么
前端开发者做菜单、目录、简单设置页时，先判断能不能用链接和独立页面完成不是以后都不用 React、Vue 或客户端脚本
个人网站维护者少写弹层组件，少引依赖，优先保证 HTML、链接、返回路径可用不是把所有页面跳转都伪装成 App 动画
内容站/文档站团队给导航、菜单、目录页定简单规范，避免每页各写一套脚本不是无条件回到“古早网页”

这里的收益不是“技术更酷”。收益更朴素：少一个组件，少一组状态，少一类失效方式。

可访问性也会跟着受益。普通链接、独立页面、浏览器历史、地址栏，这些能力天然更容易被键盘、读屏器和浏览器工具理解。当然，前提是 HTML 结构本身写得正常。链接不是免死金牌。

代价同样清楚。

设计要顺着导航模型走。你不能先画一个复杂弹层，再强行用页面跳转模拟。那样只会得到两边都别扭的实现：既不像页面，也不像应用。

真正要看的不是动画，而是页面是否够轻

这类实践能不能成立，关键变量不是 View Transitions 支持率。

更该看三件事：页面体积、缓存策略、信息架构。

页面小，跳转快，浏览器导航就像交互。页面一重，服务器响应一慢，用户感受到的就是整页重载。再好的过渡动画也遮不住。

缓存也很重要。菜单页、导航页、常用内容页如果能被稳定缓存，多页面方案才有轻快感。反过来，如果每次打开菜单都要拉一堆脚本和数据，那就只是把弹层换了个 URL。

信息架构决定它会不会失控。个人博客靠作者自律就能维持克制；多人维护的内容站更容易滑坡。今天一个菜单页，明天每个栏目都塞脚本，最后又回到“每页一个小应用”。

所以这篇复盘的价值，不是提供一个万能架构。

它更像一条工程纪律：能归于链接的，先归于链接；确实需要状态和即时反馈的，再交给 JavaScript。知止而后有定，用在个人网站上，反而很现代。

开头那个博客菜单，看起来只是一个小实现。它提醒的是一个更常见的选择：内容站不必默认应用化。浏览器已经会导航，别急着替它发明一遍。