vue-compiler: Vue's template compiler reimplemented in Rust

The compiler, not the framework

vue-compiler is described in one line as Vue's template compiler reimplemented in Rust. That is a deliberately narrow scope. It is not a Vue runtime, not a reactivity system and not a component library. It is the piece that takes a `.vue` template, parses it, applies the template transforms and produces the render function code, done in Rust rather than in JavaScript.

The reference implementation is vuejs/core, which the README marks in its own distinctive way. The stated goal of the project is to make that transform native.

The motivation is quoted in the README from Evan, in a discussion on the Vue RFCs repository, where he speculates that in the long run the whole transform, and even the Vue compiler, might be implemented in native Go or Rust so that performance would no longer be a concern. The README's response to that comment is three words.

So the project exists to settle a question rather than to ship a product: is a native template compiler a good idea? The answer implied by the repository is yes, and the way to judge that answer is to look at the output rather than the marketing.

Five ways to consume it, one of them removed

The intended usage list is the most concrete part of the documentation, and it names five delivery shapes.

A Rust library is the first, and the base of the others. A CLI binary comes next. A napi based Node.js library is the third, which is what lets a JavaScript build tool call into the Rust code directly. A wasm based npm package is the fourth, described as a fallback if napi fails to work and a toy for the browser.

The fifth entry is the interesting one: no browser build. The README explains that there is no support for it, because most features in the full build are additional except for browser based expression checking or HTML escaping, and the browser build removed them for size.

That last sentence deserves unpacking. The browser build was not removed because browser support was impossible. It was removed to keep the package small, and what was sacrificed is exactly the checking and escaping behaviour that matters most in a browser context, where untrusted content ends up in the DOM. The README also points at a spreadsheet for a browser specific summary.

For a build tool that runs in Node, that trade is fine. For a browser bundler plugin, it is not, and the wasm package is the only route left, with the caveats attached.

A workspace of crates with a napi crate on the side

The repository is a Cargo workspace, and the manifest is short enough to read in one screen:

[workspace]
resolver = "2"
members = ["crates/*", "benches", "napi"]
default-members = ["crates/*"]

So the bulk of the code lives under `crates/`, with `benches` and the `napi` binding as separate members, and the default member set being the crates alone. That shape matches the five usage modes: the library is the crates, the CLI and the napi binding are built on top of them, and the benches exist to measure the code rather than to ship it.

The release profile sets `lto = true`, which is a performance decision rather than a size one, and it fits the project's stated goal.

Around the workspace the repository carries a `rust-toolchain` file that pins the compiler version, a `rustfmt.toml`, a `renovate.json` for dependency updates, a `.pre-commit-config.yaml`, and a `playground/` directory. There is a `tests/` directory as well as `benches/`, which is a reasonable split: tests check correctness, benches track performance, and for a compiler whose entire argument is speed, having both is the point.

The wasm playground and the reference material

There is a browser playground, hosted through GitHub Pages at herringtondarkholme.github.io/vue-compiler, and the README invites you to try the compiler there. The repository also has a `playground/` directory with its own assets, including a WebAssembly-themed image and the Vue logo.

The reference section is a careful list of what to trust when output looks wrong, and the ordering carries the argument. vuejs/core is listed first, with a Japanese phrase marking it as the original. The HTML spec is named as the definitive guide for parsing HTML-like files. The Vue Template Explorer is described as giving instant results for code generation and error reporting, and it is the natural companion tool for checking what the Rust compiler produced against what the reference implementation produces.

Then there is the Nu html checker, described as the official html validator from W3C and, more importantly, as the canonical error reporter for HTML parsing when there is a discrepancy between the framework and the spec.

That last entry is the most useful thing in the reference list. When a template compiler and the HTML spec disagree about how to parse something, the project does not treat the spec as wrong. The AST explorer at astexplorer.net rounds it out for inspecting the parse tree node by node.

The project docs are separate from the reference list. There is an architecture design document, a project roadmap, and a contributing guide, all under `docs/` and the `.github/` directory.

No releases, a badge for CI, and what the repository does not say

The repository has no GitHub releases, and for a project in this state that is reasonable rather than a warning sign. The Rust version is a reimplementation of the Vue compiler, so a tagged 1.0 would imply a stability commitment the project has not made.

What the repository does show is continuous work. The last push was on 2026-10-15, the repository is not archived, and there are CI and Playground workflow badges at the top of the README, the second of which is the deployment of the wasm playground to GitHub Pages. There is also a codecov badge pointing at coverage reporting for the branch.

The gap between what is documented and what a reader needs is the practical issue. The README does not list the transforms that are implemented, does not name the crates, does not show a build command, and does not say which Vue version the output is intended to match. Those details are in the architecture design and roadmap documents, which the README links but does not summarize.

That means you cannot evaluate this project from the README alone. The comparison to make is empirical: compile the same template with the Rust compiler through the playground and with the reference through the Vue Template Explorer, and see whether the generated code matches. Anything less specific than that is guesswork.

Editorial conclusion

vue-compiler suits a team that wants the Vue template compilation step in a native binary or a Node.js binding rather than in the JavaScript toolchain, and that is willing to follow a project with no tagged releases. It does not suit a browser bundler setup, since the browser build was removed and the wasm package is described as a fallback and a toy. Before adopting it, read the architecture design and roadmap documents under `docs/`, run the wasm playground at herringtondarkholme.github.io to compare output against the Vue Template Explorer, and confirm that the `crates/*` workspace members cover the transform features your build needs.

Frequently asked questions

Official sources

1. HerringtonDarkholme/vue-compiler on GitHub
2. Issues
3. License: MIT
4. README