HTML 很容易生成。这就是问题所在。

Source: Dev.to

生产 HTML 的问题

HTML 无处不在，但如今大多数生产环境中的 HTML 都是意外产生的——由模板在字符串中隐藏逻辑生成。结果通常能工作，这也是 HTMLForge 等工具存在的原因。在许多技术栈中，HTML 是流水线的终点：它被生成而非设计，几乎不做验证，几乎从不被质疑。因此，HTML 已不再是开发者用来推理的一级构件。

HTMLForge 的理念

HTMLForge 从相反的假设出发：HTML 应该是 有意的、显式的、可验证的。它把 HTML 当作编译后的产出，对元素、属性和结构进行显式定义。如果出现错误，会在早期就失败——而不是在生产环境、浏览器或屏幕阅读器中才出错。正确性是其首要特性。

为什么有意的 HTML 很重要

• 可访问性体现在属性上；你可以生成看起来完美渲染的 HTML，却仍然是无效的、不可访问的或结构错误的。大多数工具不会提示，但 HTMLForge 会——且不需要猜测。
• 大多数工具追求编写速度，这是一种有意的取舍，当 HTML 以编程方式生成并长期存在时，会导致系统性问题。
• 小的差异会演变成系统性问题；糟糕的 HTML 静悄悄地蔓延，而良好的 HTML 则保持乏味且可靠。

使用场景

HTMLForge 在 HTML 成为基础设施时表现出色：

• CMS 渲染层
• 服务端 HTML 生成
• 邮件系统
• 管理后台界面
• 框架适配器
• 长期维护的设计系统

如果你只是原型化一个页面，HTMLForge 可能显得有点笨重，但它是为生产环境中的可靠性而构建的。

集成与核心设计

HTMLForge 并不与框架竞争；框架会变化。这就是为什么 HTMLForge 保持核心小巧、稳定且刻意“无聊”。集成代码放在核心之外，适配 Laravel、WordPress 或其他任何平台，而基础保持坚固。

开源

HTMLForge 是开源的并在积极演进。你可以浏览项目、阅读文档，或在 GitHub 上关注它的进展：

https://github.com/golchha21/htmlforge

HTMLForge 的存在是因为 HTML 应该像代码一样被对待，而不是副作用——不是更响亮、更潮流，而是更诚实。