Vize
蒸汽模式
蒸汽模式描述得太狭窄了。
简而言之：渲染Vue组件时，采用更直接的细粒度路径，虚拟DOM开销更小。
这倒是真的，但它忽略了更有趣的工具问题。
如果编译器变得更直接，那么编译器表面就更重要。
为什么蒸汽很重要
传统Vue渲染拥有强大且成熟的思维模型：
将模板编译为渲染函数
创建虚拟节点
微分动态区域
修补DOM
这种模式灵活且经过实战考验。
Vapor询问当编译器能够生成更直接的反应式用户界面表示时会发生什么。编译器可以发射操作，将反应性与DOM更新本身更接近，而不是将虚拟DOM作为核心运行时抽象。
这使压力从运行时的通用性转向了编译时的精度。
对Vize来说，这很令人兴奋，因为Vize已经基于这样一个理念构建：Vue工具链应在SFC发出任何东西之前深入理解它。
另一种编译员责任
当编译器输出更直接时，错误会更明显。
编译器必须知道：
哪些绑定是反应式的
哪些DOM操作是稳定的
哪些表达式需要获取器
哪些动态道具需要更新路径
哪些时隙和组件需要运行时边界
哪些模板作用域是循环、分支和槽位的本地
在虚拟DOM模型中，运行时差分可以吸收一些不确定性。
在更直接的Vapor式模型中，编译器承载更多意图。这意味着分析质量更重要。来源映射更为重要。快照覆盖更为重要。
这正是 Vize 设计时要探讨的问题。
蒸汽作为一流的后台
Vize 的架构将编译器的输出模式视为相关的后端，而非无关的实现。
相同的SFC结构和模板分析应能提供：
DOM 编译器输出
SSR 编译器输出
蒸汽编译器输出
解释为何支持或不支持某个构念的诊断
这很重要，因为蒸汽不应成为一个与世隔绝的特殊情况。
如果 Vapor 支持与 DOM 和 SSR 支持处于同一工具链模型中，Vize 可以比较输出、重用快照，并使诊断在不同模式间更加一致。
调试表面的变化
蒸汽模式还改变了调试体验。
当输出更直接时，开发者需要对以下方面充满信心：
生成操作顺序
反应性依赖边界
事件听众排名
组件道具更新语义
分支与环清理行为
水合或SSR兼容性（如相关）
这不仅仅是运行时的问题。这是工具问题。
一个好的Vapor工具链应该能帮助解答：
编译器认为什么是静态的？
它觉得什么是动态的？
某个特定的更新路径是从哪里来的？
哪个源表达式产生了该生成操作？
为什么这个构造会退却或失败？
这正是Vize静态分析和快照重度测试方法发挥作用的地方。
表演而不丢失语义
Vapor以性能为导向，但性能不能以牺牲Vue语义为代价。
用户不应该为了使用更快的路径而背诵第二种模板语言。最好的结果是编译器足够理解Vue代码，使直接渲染感觉自然。
这需要：
与正常Vue预期的兼容性测试
现实世界的灯具
对无支持模式的精确诊断
细致的源映射
包含大型应用的基准测试，而不仅仅是玩具示例
目标不是“不惜一切代价蒸发”。
目标是编译器路径快速，因为它理解更多，而不是默默支持的更少。
为什么这适合维兹
Vize仍处于实验阶段。这正是蒸汽成为天然环境的原因。
独立工具链可以探索：
替代编译器输出形状
更严格的诊断
更快的快照
直接的DOM操作建模
与类型感知模板分析集成
面向人工智能的编译器选择解释
官方生态系统需要稳定。Vize可以更快行动，积极测试，并在公共场合学习。
这才是正确的关系。
蒸汽模式不仅仅是Vize的另一个复选框。这是对统一Vue工具链理念的压力测试。
如果解析器、分析器、编译器、诊断、快照和现实世界的夹具都能匹配，那么 Vapor 就不仅仅是运行时优化。
这证明了工具链足够深刻地理解Vue，能够为它创造出不同的未来。