Vue + JSX 全编译项目

如果说 纯运行时项目 是在回答“没有模板编译器，Vue 还能不能工作”，那么这一篇要回答的是另一个问题：

当你不用 .vue 模板，而改用 jsx / tsx / h() 组织界面时，Vue 的编译链会发生什么变化？

答案是：Vue 依然可以工作，但编译参与的位置变了。

先记住核心区别

在 SFC 模板场景里，Vue 主要负责把模板编译成渲染函数。

在 JSX / TSX 场景里，模板编译这一层会弱很多，更多工作会转移到：

• JSX 自身的语法转换
• Vue JSX 插件注入的运行时调用
• 你手写的 h() / 组件组合逻辑

也就是说，这不是“完全没有编译”，而是编译输入形式发生了变化。

为什么这一类项目值得看

它能帮你看清楚三件事：

1. Vue 的灵活边界到底有多大
2. 模板不是 Vue 唯一的表达方式
3. 编译器优化、开发体验和表达能力之间存在真实取舍

很多人把“Vue”默认等同于“.vue + template”，但实际上这只是最主流的写法，不是唯一写法。

这一类项目通常长什么样

在这种项目里，你会同时看到几种表达方式混用：

• render() 函数
• setup() 返回渲染函数
• h() 调用
• JSX / TSX 组件
• 少量保留的 Vue 运行时辅助能力

所以它很适合拿来观察一个问题：

抛开模板语法之后，Vue 剩下的核心能力到底是什么？

答案通常会回到这些关键词：

• 响应式系统
• 组件模型
• VNode
• 渲染器
• 生命周期

和 .vue 模板项目相比，差异在哪里

1. 模板编译阶段弱化了

你不再主要依赖 template -> render function 这条路径，而是直接写更接近渲染函数的代码。

2. 代码表达能力更自由

复杂条件分支、动态组合、函数式抽象，在 JSX / h() 里通常更直接。

3. 编译器自动优化机会变少

模板能让 Vue 编译器更稳定地分析静态节点、Patch Flag 和 Block Tree；手写 JSX / h() 时，这部分自动优化空间通常不如模板明显。

4. 可读性取决于团队习惯

有些团队觉得 JSX 更统一，因为它把“视图就是 JavaScript”贯彻到底；也有些团队会认为模板更清晰，因为结构和逻辑分离得更自然。

适合什么场景

更适合：

• 高度动态渲染
• 组件组合逻辑复杂
• 更偏函数式组织方式
• 团队已经熟悉 JSX / TSX

不一定适合：

• 以模板驱动为主的业务页面
• 需要大量借助 Vue 模板语法糖的团队
• 希望尽量吃满模板编译优化的场景

建议怎么阅读这个示例

读这类项目，不要只感受“Vue 很灵活”，更建议重点观察下面几件事：

1. 哪些地方直接手写了 VNode 结构
2. 哪些能力仍然依赖 Vue 运行时
3. JSX / h() 写法相比模板到底省了什么、又多写了什么
4. 哪些优化本来由模板编译器完成，现在需要你自己承担

和纯运行时项目的区别

纯运行时项目 更接近“只剩下渲染器和运行时 API 本体”。

而这一篇的“全编译项目”本质上是在说：

• 你仍然有编译
• 但不再主要依赖 SFC 模板编译
• 而是把更多表达交给 JSX / TSX 和手写渲染逻辑

它比纯运行时项目更接近日常工程实践，也更能体现 Vue 作为“可选模板框架”的另一面。

阅读源代码

运行一下 fully-compiled 项目，观察 vue + jsx + h 的混合写法，感受 Vue 在表达层面的灵活性。

源代码详见 apps/fully-compiled

线上地址：https://fully-compiled.netlify.app/

建议继续阅读

读完这篇后，建议顺着这条链路继续：

1. 纯运行时项目
2. vite dev 和 build 下的 vue 产物
3. render vs setup render 函数

这样能把“模板写法之外的 Vue”理解得更完整。