Implement a Virtualized List That Renders Only Visible Rows

Q: Implement a Virtualized List That Renders Only Visible Rows

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Hard > **How to read this doc:** the entire real point of virtualization — that only a small, BOUNDED number of rows ever need real DOM nodes, regardless of total list size — was verified directly across 3 real scroll positions in a 10,000-item list, confirming the computed range never exceeded roughly 15 items. ## 1. The problem, restated Rendering a real DOM node for every one of 10,000+ list items would genuinely crush real browser performance. Virtualization instead renders only the small handful of rows currently VISIBLE (plus a small buffer), computing that range purely from the current scroll position and item dimensions — while still maintaining a correctly-sized, real SCROLLABLE container so the scrollbar itself behaves as if all 10,000 items genuinely existed. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Overscan items

The problem

Problem, as an interviewer would state it: "Given a scroll position and a list of 10,000+ items, compute which small RANGE of item indices actually needs to be rendered — the entire real point being that a real browser genuinely cannot render 10,000 real DOM nodes efficiently."

Examples:

Code

getVisibleRange({ scrollTop: 4000, viewportHeight: 400, itemHeight: 40, totalItems: 10000 });
// { start: 98, end: 112, count: 15 } -- NOT all 10000

Clarifying questions expected:

Should the range include extra "overscan" items just outside the visible viewport, to reduce flicker during fast scrolling?
Are all items a fixed, uniform height, or could they genuinely vary?
Does the container need a real spacer element to maintain correct scrollbar proportions, given only a handful of real DOM nodes actually exist?

Code / implementation expected: Yes — real, direct proof across multiple real scroll positions confirming only a small, bounded window is ever computed as needing to render, never anywhere close to the full item count.

performance
dom
virtualization

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Hard

How to read this doc: the entire real point of virtualization — that only a small, BOUNDED number of rows ever need real DOM nodes, regardless of total list size — was verified directly across 3 real scroll positions in a 10,000-item list, confirming the computed range never exceeded roughly 15 items.

1. The problem, restated

Rendering a real DOM node for every one of 10,000+ list items would genuinely crush real browser performance. Virtualization instead renders only the small handful of rows currently VISIBLE (plus a small buffer), computing that range purely from the current scroll position and item dimensions — while still maintaining a correctly-sized, real SCROLLABLE container so the scrollbar itself behaves as if all 10,000 items genuinely existed.

2. Clarifyi

The solution is hidden so you can try first

6 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: the visible-range calculation stays small (never more than ~15 items) across multiple real scroll positions in a 10,000-item list