Virtualization

The problem

The naive approach to rendering a 50,000-row data grid is to create 50,000 DOM nodes. The browser then spends its time laying out, painting, and reflowing elements the user can’t even see. Virtualization (also called windowing) fixes this by rendering only the rows currently visible in the viewport, plus a small buffer above and below for smooth scrolling.

Libraries like react-window and TanStack Virtual provide the infrastructure. For complex enterprise grids with frozen columns, dynamic row heights, and horizontal scrolling across hundreds of columns, teams often build a custom implementation tuned to their data shape, or adopt AG Grid. We use AG Grid at Coinbase for internal, data-heavy apps; it's excellent and highly customizable.

See the difference

Two inboxes, the same 10,000 messages, scrolling together. Render every row on the left and watch what it costs to build them. The list on the right never builds more than fourteen, however far you scroll.

Fixed versus variable height

Fixed height is trivial: every offset is index * ROW_H. Variable height must be measured: render with an estimate, measure the real height after layout, cache it by index, and anchor the scroll position so a re-measured row does not make the list jump.

Trade-offs

You take back behaviors the browser handled for free:

• Ctrl or Cmd + F only finds mounted rows.
• Linking or scrolling to an off-screen row needs manual offset math.
• Keep list semantics intact and do not strand focus on an unmounted row.
• Drag and drop reorders by data, since the target may be unmounted.

Reach for a library (react-window, @tanstack/react-virtual, react-virtuoso); hand-roll only to learn or customize.

Why interviewers ask this

"The list could have thousands of items" is a standard scaling turn, and virtualization is the expected answer. It shows you know rendering cost scales with DOM size, not screen size. It recurs in feed, chat, table, and board questions.