再见 Next.js，我用 AI 写了个定制框架
最近关于定制/个人软件和大型语言模型（LLM）的讨论很多。我一直是它的超级粉丝——我写这篇文章时正处于一个Markdown 编辑器我为自己创造了。最近我一直在思考框架的未来。两者巧妙交汇，似乎是一个个人框架。
所以从9月1日起，这个网站不再运行在Next.js上。取而代之的是，它由Fable架构和Opus实现的定制定制框架构建。如果这是商业项目，我可能会继续用Next，但事实并非🤷如此
本网站整体上是相当简单- 它是完全静态的，构建时会编译成 HTML。但它需要大量 React 和一些不简单的构建时处理，比如MDX.我给《Fable 5》（用claude代码CLI）赋予了以下内容：
我对用AI进行按需编码很感兴趣——Claude能否理论上打造一个按需定制的“网络框架”，更快比专门为这个网站设计的NextJS还要好吗？它能支持我们需要的那些功能吗？它还能部署到Vercel吗？帮我在这里看看情况，如果可行我们会发货——你负责协调Opus子代理。用OPUS做任何子代理，因为你是一个非常棒的类似AGI但价格昂贵的模型。一定要仔细操作[原文如此]
~3小时工作后，我终于有了东西可以看。
我就让数字自己说话吧：
之前与之后
| Next.js | 定制 | 变化 | |
|---|---|---|---|
| 主页 | |||
| HTML | 24.7 KB | 16.3 KB | -34% |
| JavaScript，渴望 | 208 KB，11个文件 | 2.3 KB （1 KB inline runtime + analytics） | -99% |
| JavaScript，首次绘制后 | 没有，大家都很渴望 | 10.6 KB（桌面窗口管理器） | |
| JavaScript，按需 | 1.8 KB（命令调色板，第一个 Cmd+K） | ||
| 灯塔移动 | 98，LCP 2.4秒，重量1,153 KB | 100 台，LCP 1.3秒，78 KB 重量 | LCP -46%，重量 -93% |
| 博客文章 | |||
| HTML | 20.6 KB | 11.6 KB | -44% |
| JavaScript | 200 KB，11个文件 | 2.3 KB | -99% |
| 灯塔移动 | 99，LCP 2.2秒，405 KB 重 | 100，LCP 1.1秒，57 KB 重量 | LCP -50%，重量-86% |
| 软导航有效载荷 | RSC飞行，每个链路0.7至29 KB | 3 KB 部分（Safari/Firefox）或预渲染页面（Chrome/Edge） | |
| 构建与回收 | |||
| 暖气全装 | 2.4秒 | 0.5秒 | -79% |
| Vercel构建（平均） | 28秒 | 11秒 | -61% |
| 锁文件中的包 | 706 | 550 | -22% |
这是会话统计数据（大部分墙上时间和持续时间是我的笔记本处于睡眠状态）：
Total cost: $669.45
Total duration (API): 8h 27m 17s
Total duration (wall): 1d 1h 34m
Total code changes: 20914 lines added, 2022 lines removed
Usage by model:
claude-haiku-4-5: 272.7k input, 12.8k output, 0 cache read, 0 cache write, 5 web search ($0.3869)
claude-fable-5: 57.4k input, 165.3k output, 66.8m cache read, 2.8m cache write ($131.09)
claude-opus-5: 547.6k input, 2.0m output, 562.9m cache read, 32.5m cache write ($537.98)
Prompt cache (main): 195 requests · 95% of input tokens from cache · 6 misses (last 16s ago, 2.5m tokens re-cached) · warm (1h TTL, last activity 16s ago)它用了我 Claude Code 20x 订阅的 ~10%。
注意，自从这些数据记录下来后，我做了一些小的修改和改进，但我估计这些数据覆盖了95%的工作。
你可以试试这个网站的 Next.js 版本next.maxleiter.com.
工作原理
以下内容由Claude撰写，我编辑：
- 它更像是一个构建脚本，而不是一个框架。
build.ts阅读次数posts/，在服务器端用React渲染每条路径到静态index.html，并写入Vercel 构建输出目录。我的M2 MBP构建时间是热~半秒。 - MDX 在构建时每个文件编译一次，使用之前相同的备注和 rehype 插件。在构建时用 shiki 执行语法高亮，将两个主题都导出到 HTML，因此主题切换无需 JavaScript。
- 博客/内容页面完全没有JavaScript，只有一个2KB的内嵌脚本，负责主题切换、Cmd+K和懒人岛加载。
- 岛屿用于交互性。桌面窗口管理器和命令调色板是 Preact 组件，它们会在服务器渲染的标记上进行水合，仅加载在使用它们的页面上。调色板加载时按 Cmd+K 键。Preact 通过其 React 兼容层的 7 KB，而 React 的 52 KB。
- 图像优化、不可变资产缓存、重定向和分析都来自 Build Output API 的配置和 Vercel。
- Claude编写了一个“奇偶校验框架”。它快照了Next网站的所有101条路由，并在每次变更时将不同头标签、可见的文字和代码块对比新构建。它发现（并修复了）八篇未发布的帖子泄漏到RSS源中，还有一张404ing的原始图片。
为什么要这样做？
原因有很多。首先，你可以递归地运行这样的循环，替换大部分甚至全部依赖，从而消除大量供应链攻击.你只卖你需要的，别无他物，这正是这个框架——网站实际使用的Next.js部分。第二，这个框架是5,000行;无论是人类还是模型都能轻松审查。Next.js和React有数十万个。
当然，如果我选择一个更简单的静态站点生成器，切换到Python之类的，这一切可能会简单得多。这些（大部分）都是真的，但这只是软件未来的演示，不仅仅是静态站点。
缺点
有很多。
- 我相信有成百上千个小的优化和修复Next.js LLM不知道/无法复现的
- 还有许多刻意省略的功能，比如没有代理的框架MCP。Claude-in-Chrome 对我来说已经足够了。
- 根据你更换的设备，可能会遇到过时的安全问题，这些问题会在上游修复。但这里不适用，因为这是一个静态站点。
- 现在你拥有它了。漏洞、安全问题和功能请求现在由你来处理。
Claude遇到的两个浏览器问题，推测由Next处理：
- Chrome / 跨文档视图切换。当目标页面中有外部文件时，Chrome 会悄无声息地跳过跨文档视图过渡的入站部分
<head>.内联模块脚本不会触发它。用两页控制页一分为二;这就是运行时被内嵌到每个页面而不是链接的原因。- WebKit / Speculation 规则。Safari 硬代码
HTMLScriptElement.supports('speculationrules')在只实现预取的一半时将 为真，并且它会暴露 nodocument.prerendering.所以“此浏览器可以预渲染”的功能检测需要同时检查。
这意味着什么？
我觉得试图从软件工程的零星解读是徒劳的。谁知道模型六个月后会变成什么样子，更别说两三年了。但我还是会试试看：
显然，我们会看到供应商和代理重写（“slop forks”）的增加。我们已经看到这个：Bun自主重写了从Zig到RustCloudflare也做了类似的事维内克斯.
更极端的看法是，框架终将消失。
从上面Chrome和WebKit的问题中可以看出，重要的是框架中内置的庞大知识。这些知识可以提炼成技能或未来的标准——也许是框架的继任者。
注释
- 目前谁知道我的看法会是什么，模型一年后会在哪里
- https://web.archive.org/web/20260228224244/https://slopforks.com/
点赞
收藏
点踩
分享