Vize: A Rust-native Vue toolchain that trades maturity for speed

What Vize actually fixes

Vue developers today stitch together several tools: @vue/compiler-sfc for compilation, eslint-plugin-vue for linting, Prettier for formatting, vue-tsc for type checking, and a language server for editor support. Each parses your SFCs separately, which costs time and can produce inconsistent results. Vize replaces that patchwork with one Rust-native core. A single parser feeds the compiler, linter, formatter, type checker, LSP, and a story system. The README calls this "one shared parser" and positions Vize as a toolchain you add to an existing Vue app, not a scaffold. The intended user is a Vue 3 developer on Vite or Nuxt who wants faster tooling and is willing to accept an experimental stage. The project is explicit about its phase: "Real World Testing," not production-ready.

The single-parser architecture and what it means

The core design is that every surface reads the same syntax tree. That is different from the current ecosystem where each tool has its own parser, and it is why the benchmarks show such large speedups. When you lint and format, you are not re-parsing the file from scratch each time. The compiler, linter, and formatter all operate on the same representation. The README lists the surfaces: compiler, linter, type checker, formatter, LSP, story system, and editor extensions. The type checker uses tsgo (Corsa), the Go-based TypeScript compiler, not the JavaScript one. That is an important detail: the type-check speedup is not purely from Rust, it is from switching engines. The project acknowledges this and deliberately publishes no single speedup for type checking, ranking results within each engine class instead. This honesty is rare and worth noting. The trade-off is that a shared parser means a bug in the parser affects every tool at once. There is no fallback to a separate, battle-tested parser for a single surface.

Getting it running: drop-in, init, and migration

The README gives three paths. The shortest is a drop-in swap for Vite: install `@vizejs/vite-plugin` and replace `@vitejs/plugin-vue` in `vite.config.ts`. The example shows `plugins: [vize()]` and then the same `dev` and `build` scripts work. That swap only changes SFC compilation. Lint, format, and type-check stay on your current tools until you add them. For a new setup, the README says create a Vue + Vite or Nuxt app first, then run `npx vize init`. That command can add the Vite plugin or Nuxt module, Oxlint, `vize fmt`, `vize check`, and a VS Code recommendation. For existing projects, `npx vize init --dry-run` previews the plan before applying it. The README claims `init` is idempotent: a second run adds no duplicate plugin, script, or dependency. It also says existing `vize.config.*` is left as-is, and custom `vue({ ... })` options are not rewritten automatically. That last point is a real constraint: if your Vite config has unusual Vue options, the migration will not handle them, and you will need to edit manually.

Benchmarks: what the numbers do and do not show

The README publishes a benchmark table measured on a Blacksmith runner, median of 5 runs. The headline numbers are large: SFC compile at 15,000 files is 329.2ms versus 17.15s for @vue/compiler-sfc, a 52.1x speedup. Lint is 324.8ms versus 56.20s, a 173x speedup. Format is 2.83s versus 143.13s, a 50.6x speedup. These are impressive, but the README is careful to note the corpus is not the same size for every row. Only SFC compile, lint, and format run at 15,000 SFCs. Type check runs on 500 files, and Vite build on 1,000. The type-check row publishes no single speedup because vue-tsc runs the JavaScript TypeScript compiler while Vize runs native tsgo. The Nuxt row is a 1.0x ratio, and the README calls it "diluted" because both variants run the same Nitro/Vite/Rollup pipeline, and SFC compilation is only about 2% of that build. So the Nuxt number is what a user experiences, not a measure of Vize's compiler. The benchmark rows are pinned to a committed JSON file and a test, so they cannot drift. That is good practice, but it does not change the fact that these are synthetic workloads, not your project.

Limitations and failure modes

The most important limitation is stated at the top of the README: Vize is experimental and in Real World Testing, not completely production-ready. Breaking changes and behavior that diverges from Vue are expected. That is a direct warning, and it should shape your decision. If you have a large Vue codebase that relies on edge cases of the Vue compiler, Vize may compile it differently. The README also says the drop-in swap covers Vue 3 SFCs in Vite, but the scope is limited. Custom `vue({ ... })` options are not rewritten, and unusual Vite configs are not handled automatically. Another failure mode is the type checker: because it uses tsgo, it is a different engine from vue-tsc. Your type-check results may differ, and the README does not claim parity. For Nuxt users, the 1.0x build speedup means you get no end-to-end gain today, so the only reason to adopt is to test the compiler, not to speed up your builds. The project is also looking for test beds, which means you become a beta tester, not just a user.

Alternatives and how they differ

The obvious alternative is the current Vue toolchain: @vitejs/plugin-vue, eslint-plugin-vue, Prettier, and vue-tsc. That stack is mature, stable, and well documented, but each tool parses separately and runs on JavaScript. Vize's approach is to unify parsing and move to Rust, which is why it can be faster, but it sacrifices maturity. Another alternative is Volar.js and vuejs/language-tools, which the README credits as inspiration. Volar provides editor tooling and language support for Vue, but it is not a full compiler replacement. The difference is architectural: Volar works with the existing Vue ecosystem, while Vize builds its own core. For linting specifically, the README mentions oxlint-plugin-vize, which means you can use Oxlint as the linter front-end, but the parsing is still Vize's. If you want a Rust-based tool without changing your compiler, you could use Oxlint alone, but it does not understand Vue SFCs the way Vize does. The real choice is between a proven but slower ecosystem and a fast but experimental one.

Maintenance, license, and upgrade cost

The project is under the MIT license, which is permissive and poses no unusual restriction for commercial use, but this is not legal advice. The maintenance situation is more concerning. The last push and the latest release are from 2026-08-24, and there are three releases on the same day (v0.387.0, v0.386.0, v0.385.0). That release cadence suggests very active development, but it also means the tool is changing fast. Breaking changes are expected, so upgrading Vize may require config or code changes on your side. The README points to a stability guide and a support policy, but those are not summarized in the material. The upgrade cost is real: every time you update the Vite plugin or the `vize` package, you need to re-run your tests and check for behavioral divergence. The project has a test suite of over 10,000 tests, which is a positive signal, but the README does not say those tests cover your use case. The maintenance burden is on you to track releases and validate against your project. The project is actively seeking fix requests and PRs, so you can contribute, but that is a cost, not a benefit, for most teams.

Editorial conclusion

Adopt Vize if you run a Vue 3 + Vite or Nuxt project, you are comfortable with experimental tooling, and you want to test a single-parser Rust pipeline that shows dramatic speedups on SFC compile, lint, and format. Do not adopt it if you need a stable, production-ready toolchain today: the README explicitly warns of breaking changes and behavior that diverges from Vue, and the type-check and Nuxt build numbers do not prove a clear win. Before adopting, verify three things: run `npx vize init --dry-run` on a copy of your project to see the exact config changes, compare `vize check` output against `vue-tsc` on your own codebase, and check the stability guide and production-readiness checklist linked from the repo. The project is in Real World Testing and wants test beds, so your contribution is welcome, but treat it as an evaluation, not a replacement.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes