React vs Vue for LLM-generated frontend code: an 11x ecosystem gap and benchmark parity

Frontend developers keep reporting the same irritation: when a model writes UI code, React output lands closer to something you can ship, and Vue output needs fixing. The report is consistent with what anyone can measure — React pulls 222.8 million npm downloads a week against Vue's 20.2 million, in the seven days ending 2026-10-03 — and it is easy to slide from that into "the models support React better."

That sentence hides at least four different claims: that models pick better component boundaries in React, that they misremember Vue APIs more often, that agentic edits over a large Vue codebase drift more, and that generated Vue code looks worse on screen than generated React code. Only the last two have published numbers behind them, and the numbers are less flattering to the popular story than the download chart suggests.

Ecosystem volume

The asymmetry is real and it is large. Weekly npm downloads for the week ending 2026-10-03, from the registry's own API:

Package	Weekly downloads
react	222,767,611
react-dom	210,124,779
vue	20,219,736
next	76,367,573
nuxt	2,750,836
@ai-sdk/react	10,912,101
@ai-sdk/vue	2,023,755

React's gap over Vue is roughly 11x; the meta-framework comparison is wider still, with Next at 28x Nuxt. The AI-tooling adapters land in between: the React binding of the Vercel AI SDK is 5.4x its Vue binding, and Vue's own adapter is ahead of Svelte's 701,483. Vue support in AI tooling exists and is maintained — it is just thinner.

GitHub stars, the metric developers reach for first, do not show this gap at all: a 2025 benchmark snapshot collected React at 229K and Vue at 208K in March 2025. Stars measure attention paid once; downloads measure code installed continuously, and only the second one accumulates in the kind of volume that ends up in training corpora. Download counts still overstate the split in one direction — CI reinstalls and transitive dependencies from meta-frameworks inflate React, since react is pulled in by tools that are not React applications at all. The honest reading is that React's public code surface is several times larger, not necessarily eleven.

Framework syntax and error shape

The two frameworks ask a model to hold different things in its head, and that difference shows up in the specific mistakes.

JSX is JavaScript with a markup-shaped expression inside it, so a model's general JavaScript prior transfers directly; React's remaining traps are things like a missing "use client" directive at the top of a file, which is a placement rule rather than new syntax. A Vue single-file component mixes three languages in one file — a template with its own directive vocabulary (v-for, v-model with modifiers, v-if chains, slots, defineProps/defineEmits macros) plus a script block and a style block — and the template is not JavaScript at all. The compiler is strict about structure in a way JSX rarely is.

DesignBench, a 2025 benchmark from CUHK and SMU covering 900 webpages across React, Vue, Angular and vanilla HTML/CSS, published the error taxonomy for nine models. React failures cluster on Unexpected Token, Expression Expected and Use Client Missing. Vue failures cluster on Missing End Tag, Unexpected EOF and Attribute Error. Different failures, same class of problem: both frameworks have syntax the models do not fully track.

Repair effort is the more practical number, and it is a tie. Asked to fix 30 pages with real compilation errors, the nine models averaged a repair rate of 0.53 on React, 0.52 on Vue and 0.53 on Angular.

The benchmark also found something that cuts across frameworks: models barely use components. Averaged across models, component-based implementation appeared in 0.24% of React pages, 5% of Vue pages and 19% of Angular pages. The published case study is a Vue page with a repeated list item — a textbook v-for — where the model emitted copy-pasted hardcoded markup instead of the directive. That is exactly the "React is better supported" complaint, except the failing pattern is a model failing to use a framework feature it clearly learned about, not a model lacking Vue knowledge.

The measured gap

On the tasks DesignBench measures — generating UI code from a screenshot, editing it on instruction, and repairing visual bugs — React does not beat Vue. The top line for Claude-3.7:

Metric	React	Vue	Angular	Vanilla
Compilation success, generation	0.9541	0.9746	0.6867	—
CLIP similarity, generation	0.8083	0.8319	0.6024	0.8132
Compilation success, edit	1.0000	0.9810	0.9091	—
Code modification localization, edit	0.5555	0.5961	0.7696	0.5862

Vue leads React on generation quality and compile rate, and again on code-localization during edits (0.5961 against 0.5555); React's only lead in the table is a marginal one on edit compile rate. Angular, despite the worst generation numbers, posts the highest localization score — a reminder that no single metric in this table stands in for overall usability. Both frameworks lose to vanilla HTML/CSS on visual similarity. The benchmark's own summary of the framework comparison is that models do best on vanilla, worst on Angular, and sit at intermediate levels on React and Vue, with the gap to vanilla coming from the syntactic complexity frameworks add.

Angular is where the model story actually breaks down, and the numbers are not close: a 0.6867 generation compile rate against Vue's 0.9746, and CLIP scores in the 0.60 range against 0.83. If a team is reading "framework support" as a reason to standardize, the evidence supports "avoid the least-represented framework" far more strongly than "prefer React over Vue."

Web-Bench is the other relevant 2025 publication, and it measures the harder thing: 50 projects of 20 sequential, dependent tasks each, designed by engineers with five to ten years of experience, run against four UI frameworks including React and Vue on identical project specs. Its top score is 25.1% pass@1 for Claude 3.7 Sonnet — the framework-based, long-horizon work is simply unsolved, for every framework. The paper's conclusion is not that one framework is better represented; it is that models need optimization tailored to standards and frameworks, proposing standard-aware pretraining and framework rule-checkers in the decoding loop.

The gap between the popular claim and this evidence has a plausible explanation that is not adversarial to either side. What a developer notices in daily work is not the benchmark's averaged CLIP score; it is how much of the model's output is React-shaped. A model trained on a corpus with many times more React will reach for React idioms when the prompt does not forbid them, will decorate Vue files with patterns that belong to React, and will hand back a codebase whose structure is idiomatic for the wrong framework. That reads as "worse Vue support" even when the generated Vue file compiles and renders, and it is a real cost: an idiomatic-in-the-wrong-framework diff is more work to review than a broken one, because nothing fails loudly.

Adoption notes

For teams on Vue, the actionable part is narrow and dull. Pin the API surface in project context — Vue 3 Composition API with <script setup>, or the Options API, but not both — and treat that as a build-time constraint, not a preference expressed in a prompt.

Hand the model the docs rather than hoping it recalls them. Vue publishes a machine-readable tree at vuejs.org/llms.txt with a .md version of every guide and API page, React publishes the equivalent at react.dev/llms.txt, so neither side has an agent-documentation disadvantage to complain about, and the working agent integration is the same amount of effort on both.

Gate on the compiler, not on the model's confidence. vue-tsc and eslint-plugin-vue catch the Missing End Tag and Attribute Error classes that the benchmarks show models producing, and they catch them in seconds; a passing type-check is worth more than a plausible-looking diff. Expect the same failure class in React — Unexpected Token and missing "use client" are the React halves of the same problem.

Budget for component-boundary review in both frameworks. If models use components in 0.24% of React pages and 5% of Vue pages on a benchmark built from real sites, the majority of generated UI code will be one large file, and the review cost lands on whoever has to split it.

The download numbers say the model ecosystem will keep favoring React, and nothing in the published benchmarks shows that a Vue team pays a measurable quality penalty for it on the tasks those benchmarks cover. What it does show is that framework-specific syntax is a shared bottleneck, that Angular carries a much larger penalty than Vue, and that the failure developers describe — idiomatic React patterns leaking into Vue code — is real, visible in the error distributions, and cheap to catch with the toolchain each framework already ships.

References

1. DesignBench: A Comprehensive Benchmark for MLLM-based Front-end Code Generation (arXiv:2506.06251v3)
2. Web-Bench: A LLM Code Benchmark Based on Web Standards and Frameworks (arXiv:2505.07473)
3. bytedance/web-bench — GitHub
4. Vue.js documentation index for agents (llms.txt)
5. React documentation index for agents (llms.txt)
6. npm registry download API — weekly downloads