Vize publishes the row where it lost and the row where it is five patches behind

The headline numbers describe an older build

The benchmark table is generated from one committed artifact and states the versions it measured. Vize is quoted at 0.424.11. The newest published release is 0.429.2, published on 2026-09-30, and the workspace manifest already reads 0.430.0. So the table describes a build several patch releases behind the line you would install, and the measurement date on it is 2026-09-16, two weeks before that release.

The page does not hide this. It states that the ratios do not prove a performance improvement over an earlier Vize version, which is an unusual sentence to find in a project's own benchmark section, and it links a snapshot with per-variant timings, diagnostic counts, rejected measurements and methodology, plus the actions run, the commit hash and the raw results file.

So the table is best read as a single observation on one day, on one machine: a 32 CPU Ubuntu 24.04 runner, three runs, one warmup. It is evidence that the tool is fast. It is not a claim about the version you get, and a reader who quotes 182 times without quoting the caveat is quoting the wrong half of the sentence.

One row is a loss, and the page explains it

The sixth row is a case where the tool is slower. Over 250 files, the Nuxt build measured 3.07 seconds against 3.21 seconds, a ratio of 0.95 times, and the page says plainly that a ratio below 1 means Vize was slower in that run.

It also explains why, which is the part that makes the row useful. The Nuxt row measures the entire build pipeline rather than isolated component compilation, and most of the work in that pipeline is shared by both variants. When the shared work dominates, swapping the component compiler cannot show a speedup, and a small regression in the replaced part becomes the whole difference.

That is the correct explanation and it is also the reason the row is not embarrassing. Publishing the loss, naming the reason and leaving it in the same table as the wins is a habit most projects do not have. The five other rows are: component compilation over 3,000 files from 3.57 seconds to 65 milliseconds, lint over 3,000 files from 20.75 seconds to 114 milliseconds, formatting over 3,000 files from 29.72 seconds to 351.4 milliseconds, type checking over 500 files from 6.75 seconds to 1.37 seconds, and a Vite build over 1,000 files from 1.66 seconds to 889 milliseconds.

The shape of that list is the point. The gains collapse from two orders of magnitude to under two as the measured unit moves from a single tool to a whole pipeline.

The biggest figure compares a linter against a plugin

The 182 times figure is the row to read carefully. The comparator for lint is named as the ESLint plugin for Vue, not ESLint, and Vize's side is its own linter in full. So the row measures a complete linting pass against a rule set that would run inside somebody else's linter.

That is not a dishonest comparison, because the plugin is what a Vue project actually runs, but it is not a comparison of like with like, and the page partly acknowledges it. It says the full snapshot contains per-engine-class tables that rank same-engine tools against each other in order to isolate a single layer. In other words the project knows the aggregate ratio mixes layers and has published a second view that does not.

The type-check row has the same shape for a different reason. Vize drives the native TypeScript compiler while vue-tsc drives the JavaScript implementation of it, and the page says so directly: the ratio covers the whole toolchain rather than the Vue layer alone. Most of that 4.9 times is native versus interpreted, not a better type checker.

Which leaves the format row, where Prettier is a whole formatter compared with a whole formatter, and the two build rows, where a whole build is compared with a whole build. Those three are the cleanest comparisons on the page, and none of them reaches two orders of magnitude.

The comparators are pre-release as well

The version line under the table lists what was installed, and two of those are betas. Vue itself is a 3.6.0 beta. The alternative type checker in the set is a 0.0.1 beta. The rest are a native TypeScript compiler at 7.0.2, the current Vue type checker at 6.0.3, and Node at 24.14.0.

So the field being measured against is not entirely a set of stable releases either. That is normal for a project tracking a framework closely and it is worth knowing when reading a table, because a beta Vue means the input corpus can change under the measurement.

Two further caveats are stated in the same paragraph. Each timed invocation passes a validation check that the work it was asked to do actually happened, which stops a tool from winning by doing nothing. And diagnostic coverage differs between tools, so the page explicitly disclaims the comparison people most want: these ratios do not prove accuracy parity. A tool that is 182 times faster and reports half the problems is not better, and the page says so rather than letting the multiplier imply it.

It closes by noting that rejected comparators have no published timing or rank, which is a quiet admission that some tools were dropped from the table and that a reader cannot see which.

The drop-in path swaps exactly one thing

The shortest path into Vize is deliberately narrow. On a Vue 3 project using Vite, you replace the Vue plugin with Vize's and your single file components stay as they are:

npm i -D @vizejs/vite-plugin

What that changes is stated in one sentence: single file component compilation, nothing else. Lint, formatting and type checking stay on whatever tools the project already uses, until you add Vize's. The page scopes the claim the same way, to Vue 3 components in Vite, and points Nuxt users at a separate module rather than at the Vite plugin.

For a new project the direction is reversed. Vize does not scaffold anything. You create the app with the standard Vue or Nuxt creator, and then run an init command that wires the toolchain into what already exists. The init step can add the bundler plugin or the Nuxt module, the Oxlint plugin, the formatter, the checker and an editor recommendation, and you choose which.

That is a sensible design for a tool asking to be adopted in a real world testing phase. A toolchain that refuses to generate a project cannot break your project layout, and a drop-in that changes one layer cannot break your lint setup.

Init is idempotent, and not complete

The migration path previews before it acts. A dry run prints the plan, the same command without it applies, and the page states the properties that matter for a tool that edits your configuration: init is idempotent, it lets you choose surfaces, an existing configuration file is left as it is, and a second run adds no duplicate plugin, script or dependency.

It is also candid about what the first run will touch. Scripts prefixed with the tool's namespace may be added, and a plain bundler or Nuxt configuration file may be updated. That is a broader footprint than a purely additive change and worth reading before running it on a repository with a careful configuration.

The limitation is in the next paragraph and it is the one to plan around: custom options passed to the Vue plugin, and unusual bundler configurations, are not rewritten automatically. So a project with a hand-tuned bundler config gets a partial migration. The tool will add its plugin and leave the rest alone, and finishing the job is manual.

There is a non-interactive form for scripted use, which takes a yes flag and explicit surface flags for lint, bundler, formatting, type checking and editor, so a script does not have to guess which surfaces were offered.

A Vue toolchain with a MoonBit dialect and six vendored crates

The Rust workspace has thirty nine members and a few things a Vue toolchain does not obviously need. There is a tiered family of crates under a directory named after a Renaissance painter, running from a base level through four intermediate ones, with explicit conversion crates between adjacent tiers, plus a guest crate, an extension contract and an extension host, and a benchmark harness under the tools directory. There is a member named for a MoonBit dialect, and a MoonBit version file at the repository root. There is a vendored directory, a submodule file, and an explicit exclusion in the workspace manifest for the vendored parser.

The workspace itself is set to resolver 3, edition 2024, a minimum Rust version, and a workspace version of 0.430.0. On the JavaScript side the root package is private and enables publish provenance, pins its package manager and its Node version with a download-on-mismatch policy, and routes most development dependency versions through package manager catalogs rather than repeating ranges.

One detail explains a benchmark row. The native TypeScript compiler that the type-check comparison depends on is delivered as six optional dependencies, one per platform and architecture across three operating systems. So the fastest type-check path in that table is partly a prebuilt native compiler shipped per platform, which is exactly the kind of thing the engine-class caveat is warning about.

The rest of the root is infrastructure: a Nix flake and a default environment file, a patches directory, a formatting and lint configuration for Rust, a changelog generator config, a supply-chain security config, and one document whose name refers to redundancy that nothing on the page explains.

The project calls itself a test phase and asks for test beds

The first thing on the page after the badges is a warning, and it is not a formality. Vize is described as experimental and in a real world testing phase, not a production ready toolchain yet, with breaking changes and behaviour that diverges from Vue expected. Three documents are linked for anyone about to adopt it: a stability guide, a production readiness checklist and a support policy.

The rest of the page is consistent with that. The project asks for fix requests and pull requests, and it says it is looking for reasonably large Vue projects to use as test beds. The distribution description makes a related claim, that the project has passed more than ten thousand test suites and includes real world end to end coverage.

There is one gap worth naming. The version line is 0.429.x, so this is pre-1.0 software by any convention, and the warning tells you that divergence from Vue is expected. That is not a criticism so much as a condition: a Vue toolchain whose own tests pass and whose behaviour differs from Vue in places is asking you to find the difference before your users do, which is what the test bed request is for.

Editorial conclusion

The benchmarking discipline here is better than the numbers deserve, and that combination is worth something on its own. The table states which engine it compared against, publishes the row where the tool lost, names the commit and the machine, and says in plain words that the ratios do not prove accuracy parity. Take it that way. Three things to check before adopting Vize. Read the caveats in the table rather than the multipliers, because two of the biggest figures mostly measure native code against interpreted code and one measures a linter against a rule plugin. Confirm which build you are getting, since the table describes 0.424.11 while the released line is 0.429.x and the manifest is already at 0.430.0. And plan for the project's own stated status, which is a real world testing phase that asks for test beds, with breaking changes and divergence from Vue explicitly expected.

Frequently asked questions

Official sources

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