一门像 Forth 的小语言，现在被拿来写网站。
Forge 的做法很直接：开发者在 .forge 文件里定义“词”，用栈操作拼出 HTML。比如把一段字符串压栈，再调用 h1，词定义会把它包成 <h1> 标签输出。
有意思的地方不在“又来了一个前端框架”。Forge 目前也没有把自己说成成熟发布、生产可用或通用替代品。
它更像一个问题：个人网站一定要被大型框架、构建链和组件体系接管吗？还是说，一个小语言、一个二进制、一套双端编译机制，也能把博客、笔记页和 IndieWeb 页面写得足够清楚？
Forge 写的不是组件，而是一组会吐 HTML 的词
Forge 的站点结构很朴素：pages、lib.forge、style.css。运行时用单个 forge 二进制启动，例如 forge --log forge.log my-site/。
页面写在 .forge 文件里。公共能力放在 lib.forge。最终输出的是实际 HTML，而不是只在浏览器里临时拼出来的页面。
这就决定了它的气质。
它不像 React 那样围绕组件、状态和虚拟 DOM 展开，也不像 Next.js 那样把路由、构建、部署和服务端能力打成一整套。Forge 更接近一个很小的静态站点生成器，但它又不是纯静态，因为后面还有服务端和浏览器端编译。
更关键的是，作者还写了生成 microformats 的词定义。对 IndieWeb 用户来说，这比语法新奇更实在。microformats 常用于标记作者、发布时间、永久链接、内容摘要等信息，方便 WebMention、订阅器和其他个人网站工具识别页面。
| 维度 | Forge 的做法 | 更接近什么 | 现实判断 |
|---|---|---|---|
| 页面表达 | Forth 式词定义和栈操作生成 HTML | 小语言 / 模板系统 | 小众，但能让输出更可控 |
| 站点结构 | pages、lib.forge、style.css | 轻量站点工具 | 适合个人站，不像团队框架 |
| 语义标记 | 用库词生成 microformats | IndieWeb 工具链 | 对 WebMention 和订阅识别有用 |
| 运行方式 | 单个 forge 二进制 | 简化部署入口 | 工具链薄，不能高估生态 |
对个人博客作者或 IndieWeb 开发者，最直接的动作不是“迁移全站”。更合理的是拿一个小页面试：一篇文章页、一个 about 页，或者一个 WebMention 相关页面。
如果你维护的是团队前端项目，Forge 现在更适合旁观。它没有展示足够的生态、测试、构建优化和协作方案，不适合作为替换主流框架的依据。
双端编译，才是 Forge 最值得看的设计
Forge 不是纯客户端框架。
用户直接访问页面时，后端会把 .forge 编译成真实 HTML。这样爬虫、WebMention 工具、不开 JavaScript 的访问场景，都能拿到可读页面。
同时，源 .forge 文件会保留。站内跳转时，浏览器里的 service worker 会拦截请求，拉取对应的 .forge 源文件，并在本地运行编译器，把它编译成 HTML。
这套设计的好处是取了两边的一部分。
后端编译给它可索引性和语义可见性。浏览器端编译给它类似单页应用的跳转体验。它没有把网站完全交给客户端，也没有停在传统静态页面的交互手感上。
但边界也在这里。
主流框架解决的是团队协作、复杂状态、组件复用、构建优化、测试生态和大型应用维护。Forge 目前能说明的是：一个人维护的小站，能不能用更少概念，把源文件、HTML 和语义标记放得更近。
这对两类人最有价值。
一类是关心个人网站可长期保存的人。他们会在意页面最终是不是 HTML，语义标记是不是清楚，关掉 JavaScript 后还能不能读。
另一类是喜欢小语言和 WebAssembly 工具链的开发者。他们会关心：编译器能不能同时跑在服务端和浏览器端，语言最小集合能不能撑住日常写站。
普通前端团队的动作很简单：不要迁移，不要采购式评估，也不要按框架成熟度去要求它。把它当成一个设计样本看，更合适。
边界很小，而且是有意小
Forge 的交互能力很克制。
它支持把内容写入 state、localStorage，或者追加到服务器上的 JSONL 日志。示例里的点赞机制，并不是完整数据库。它只是把字符串 1 写入类似 likes:demo 的主题日志。
表单也类似。表单可以提交到其他 .forge 页面，提交内容会被放到栈里。目标页面是否调用 log-append 写入后端，由页面自己决定。
这套东西适合小站点、小交互和实验页面。比如点赞、简单反馈、轻量日志。
但不要把它误读成后端应用框架。一旦进入账号权限、垃圾提交、数据校验、查询、迁移、审计，JSONL 追加日志就不够了。开发者需要自己补复杂度。
我更在意的观察点也在这里：
- 文档是否能讲清 `.forge` 语法、词定义、错误处理和部署方式；
- service worker 端编译失败时，页面如何降级；
- JSONL 日志如何处理垃圾提交、并发写入和权限边界；
- microformats 和 WebMention 的支持能否保持简单，而不是变成另一套重工具链。
目前能下的判断应该收住。Forge 不是 React、Next.js、Astro 的竞争者。它也没有证据支撑性能、安全性或可维护性的夸张结论。
它的价值在更窄的地方：把个人网站重新拉回到“源文件可读、HTML 可见、工具链可理解”的尺度上。
这件事不大，但有现实意义。很多个人网站最后不是死于访问量不够，而是死于工具链太重、升级太累、作者自己也不想再碰。Forge 至少把另一条路摆出来了：小器可以小用，先让一叶扁舟能下水。