Web UI Benchmark (webuibench.dev)

TL;DR

webuibench.dev is a side-by-side viewer that runs identical UI prompts through multiple models and renders the outputs next to each other. The prompt set is a small fixed library of common web component types (Button, TextField, ProductCard, DropdownMenu, DataTable, CommandPalette, DateRangePicker). It is a qualitative arena, not a scored benchmark — no metrics, no leaderboard exposed on the landing page at filing time.

Key claims

Comparison is by component prompt, with a fixed catalogue of seven primitives: Button, TextField, ProductCard, DropdownMenu, DataTable, CommandPalette, DateRangePicker [landing page].
Format is side-by-side rendered outputs from different models on the same prompt — explicitly framed as a comparison of “how different models handle the same UI prompts” [landing page].

Method

The landing page is minimal at filing time and exposes neither the model list nor the scoring methodology. The seven component categories listed are the prompt taxonomy; presumably each model is asked to produce a working/rendered instance of each component and outputs are placed adjacent for human inspection. No automated metric (visual similarity, code-quality, accessibility, render-fidelity) is surfaced on the public page. Functionally this is a vibe-coding leaderboard for narrow, well-specified UI components rather than an open-ended app-generation benchmark.

Note: this is distinct from the academic WebUIBench (Lin et al., ACL Findings 2025, arXiv:2506.07818), which evaluates MLLMs across WebUI Perception, HTML Programming, WebUI-HTML Understanding, and WebUI-to-Code with 21K QA pairs over ~0.7K real websites. The webuibench.dev site does not appear to be that benchmark’s official artifact — same name, different scope (component arena vs. multi-task MLLM evaluation).

Results

None published on the landing page. Headline numbers not available; only rendered output strips per component.

Why it’s interesting

UI generation is one of the cleanest harness-able coding tasks for frontier models because outputs are visually scorable by humans and compilable/runnable, and component-level prompts factor out the long-horizon planning problem that dominates FrontierSWE — benchmarking coding agents at the limits of human ability and SWE-Vision: A Minimal Agent for Advancing Visual Intelligence. As a qualitative arena it complements those scored agentic benchmarks: where FrontierSWE measures whether the agent finishes a hard PR and SWE-Vision measures multi-step visual-software workflows, webuibench.dev isolates “can the model produce a clean idiomatic component in one shot.” Useful mainly as a quick eyeball test for product UI work; not yet a quantitative input.