/ Docs

What AI Thinks About vlist #

PublishedUpdated May 13, 2026

We gave 6 leading AI models access to the vlist repository with no context, no coaching, and no prompting beyond "explore the codebase and answer these questions." Same questions, raw unedited answers.

The Models #

Model Platform Access Recommendation
Gemini 3.1 Antigravity Local repo "It deserves to be the industry standard."
Claude Opus Claude Code Local repo "The strongest option available today."
GPT 5.5 Codex Local repo "Yes, with a caveat."
Grok xAI GitHub "Strongly — the author clearly knows what they're doing."
Mistral Large Le Chat GitHub "Yes, absolutely."
DeepSeek R1 DeepSeek GitHub "Qualified yes — brilliant choice for early adopters."

The Questions #

  1. First impressions — Analyse the vlist package and tell me what you think.
  2. Architecture — How would you describe the architecture to a senior developer? What design decisions stand out?
  3. Comparison — How does vlist compare to other virtual list libraries?
  4. Accessibility — Review the accessibility implementation.
  5. Development process — Check the git history and tell me what you think about the development process and the timeline.
  6. What would you improve? — What would you change, fix, or add?
  7. Recommendation — Would you recommend this library?

First Impressions #

Every model independently identified the same core strengths: the builder pattern, zero dependencies, accessibility-first design, and performance discipline.

"It reads like a serious virtualizer, not a toy package." — GPT 5.5

"It's a highly impressive, modern, and extremely well-architected virtual list library." — Gemini 3.1

"This is one of the most carefully engineered frontend libraries I've read." — Claude Opus

"It feels like a batteries-included TanStack Virtual but with built-in A11y, more layouts, and smaller footprint." — Grok

"The standout feature is its default accessibility and constant memory footprint." — DeepSeek R1

Architecture #

The models converged on a shared description but each found their own vocabulary for it.

Gemini called it a "Domain-Driven, Zero-Allocation Virtualization Pipeline" — the core is a geometry engine, not a UI component. Features are pure functions that inject logic into lifecycle hooks at build time. "Inversion of control applied to tree-shaking."

Claude described it as a microkernel — the core is the kernel scheduling renders and managing the element pool, features are drivers that can replace kernel subsystems. The function replacement pattern (features replace getVisibleRange, positionElement, etc.) is the key architectural insight.

GPT 5.5 framed it as "bundle-budget driven" — the architecture is shaped around keeping the base tiny. Features don't inherit; they compose. The BuilderContext is powerful but is a "soft internal protocol" guarded by tests and conventions.

Grok highlighted the axis-neutral code path — vertical and horizontal share one implementation — and the internals export (./internals) for power users building custom features.

DeepSeek emphasized constant memory — by never storing the full item list internally (only the visible range and cached sizes), memory stays O(visible items) not O(total items).

Comparison #

All six models agreed on vlist's key differentiator: feature density per kilobyte. No other library combines grid, masonry, table, groups, async, selection, sortable, scale, and full ARIA accessibility in a single tree-shakeable package.

The models also agreed on the main caveat: ecosystem maturity. TanStack Virtual and react-virtuoso have years of production battle-testing. vlist is 3.5 months old.

GPT 5.5 provided the most balanced comparison table:

Library Personality Best Fit
vlist Tiny framework-agnostic virtualizer with opt-in features Product UIs needing lists, grids, tables, groups, async, a11y, selection, huge counts
TanStack Virtual Headless primitive/engine Teams that want full markup/control and already compose their own UI
React Virtuoso High-level React components React apps that want polished behavior with low setup
react-window Minimal React virtualization Simple React lists/grids where you want a small, proven primitive

Gemini was more direct: "The current landscape forces a choice: lightweight headless hook or heavy monolithic component. vlist bridges this gap."

Accessibility #

This is where the models diverged most sharply — and that divergence is informative.

Gemini found no issues and called the implementation "a masterclass in how to write highly accessible UI components without sacrificing runtime performance." It highlighted the minimal-move DOM sorting, data-space ARIA resolution, and 2D keyboard extensibility.

GPT 5.5 found two P1 bugs:

  • aria-activedescendant is set on the focusable root (.vlist), but role="listbox" is on a child element (.vlist-items) — a semantic mismatch
  • Table rows use a different ID format than selection expects, breaking aria-activedescendant references in table mode

Claude praised the implementation but flagged the same structural concern: JSDOM testing can't fully validate screen reader behavior.

DeepSeek gave it a "grade A for effort and design, but needs audit" — the design is exemplary, but without documented screen reader testing (VoiceOver, NVDA, JAWS), full trust requires verification.

Grok and Mistral were positive but less specific in their analysis.

Development Process #

The models painted a consistent picture: 702+ commits in ~100 days by a focused solo developer, with a clear 5-phase trajectory.

GPT 5.5 provided the deepest quantitative analysis:

  • 843 total commits across all refs, 65 active commit days
  • Average 13 commits/day on active days, peak of 49 on February 16
  • 55 release tags from v0.3.1 to v1.7.8
  • Commit breakdown: 268 fix, 140 feat, 124 chore, 66 refactor, 62 docs, 59 test, 47 perf

Gemini identified the 5-phase evolution: hardest problem first (scroll compression) → zero-deps pivot → core features → complex layouts + adapters → ruthless micro-optimization.

GPT 5.5 also noted signs of AI-assisted workflow from .claude references in the git history — "not a problem by itself, the small commits plus tests suggest a controlled workflow."

DeepSeek raised a fair red flag: "The velocity is extremely high for a library of this complexity. It suggests either the author is a virtuoso with existing internal code, the test suite is light, or there are undiscovered bugs."

What Would You Improve? #

Each model found different things to criticize — which is what makes the format work.

Bugs Found #

  • GPT 5.5: aria-activedescendant semantic mismatch (P1), table ID format mismatch (P1), interactive: false still exposes listbox/option roles (P2), table headers are pointer-only (P2)
  • GPT 5.5: updateItem/removeItem API ambiguity between index and id

Architectural Concerns #

  • Claude: Type safety across feature boundaries (ctx.methods is Map<string, Function> with no compile-time checks)
  • Claude: Missing per-feature entry points (vlist/grid, vlist/selection) for guaranteed code splitting
  • GPT 5.5: BuilderContext as a "soft internal protocol" — powerful but fragile

Testing Gaps #

  • Claude, Grok, DeepSeek: JSDOM-only test suite — need real browser tests (Playwright/WebDriver)
  • Gemini: Playwright E2E visual regression tests for pixel-level rendering bugs
  • DeepSeek: Automated axe checks and documented screen reader testing

Feature Requests #

  • Gemini: withTree() for collapsible hierarchies, nested virtualization state preservation, bi-directional async for chat UIs
  • Grok: Official SvelteKit/Next.js/Nuxt examples, withInfinite convenience wrapper
  • DeepSeek: React adapter stress-testing with concurrent rendering, withScale() edge case documentation

Documentation #

  • Claude, Grok, DeepSeek: Plugin authoring guide, feature compatibility matrix, architecture docs
  • Mistral: More real-world examples with data-fetching libraries

Recommendation #

All six models recommended vlist. The gradient of enthusiasm is itself a credibility signal:

Most bullish:

"It deserves to be the industry standard." — Gemini 3.1

"Yes, absolutely — especially for accessibility, performance, and framework-agnostic design." — Mistral Large

Confident with caveats:

"The strongest option available today... the main caveat is maturity." — Claude Opus

"Strongly — especially if you value accessibility, multi-framework support, or need grid/masonry/table/groups/sortable out of the box." — Grok

Most cautious:

"Yes, with a caveat. I'd want a little more real-world mileage before calling it the default choice." — GPT 5.5

"It feels like a v2.0 library at v1.7.8. Brilliant choice for early adopters who can tolerate some risk." — DeepSeek R1

Why This Matters #

These reviews weren't prompted to be positive. Each model was given the repo and asked to form its own opinion. The consistency across models — all independently reaching the same conclusions about architecture, performance, and accessibility — is the strongest form of validation an AI can provide.

The criticisms are equally valuable. GPT 5.5 found real accessibility bugs. DeepSeek raised fair concerns about maturity. Claude flagged type safety gaps. These aren't hypothetical concerns — they're specific, actionable findings from models that have seen every virtual list library in their training data.

vlist is built by a human orchestrating AI teammates. It's fitting that AI models are also the first to review it.