BGrid decouples scroll height from dataset size to push React grids past one million rows

The makers of BGrid (BeautifulGrid), an open-source React and TypeScript data grid released under Apache-2.0, say version 1.0.3 can display one million rows in the browser. According to a post on dev.to, the component's earlier public demo stopped at 550,000 rows, and the reason was not rendering performance but a limit on how tall a single DOM element can reliably be.

A spacer nobody can see

Like most modern grids, BGrid uses virtual scrolling: only the rows visible in the viewport exist in the DOM, regardless of dataset size. The problem, the post explains, was the scrollbar. To let users drag through the whole dataset, the grid still needed an element whose height matched the full data, at roughly 29 pixels per row. At 550,000 rows that works out to about 15,950,000 pixels, and around that range the team began hitting practical CSS and layout limits for extremely large element dimensions in their target browsers.

The symptom was strange rather than fatal. As they pushed past 600,000 and 700,000 rows, the layout started breaking even though React was not crashing, memory was not exhausted, and only a small window of rows was rendered. That also explains the oddly precise 550,000 figure in the original demo: the team sized it to stay under the practical scroll-height ceiling they were observing, not because the grid slowed down at row 550,001.

Logical scrolling in v1.0.3

Version 1.0.3 changes the architecture. Instead of letting the browser's physical scroll position stand in for the dataset position, BGrid separates the two. The browser only scrolls across a bounded, safe physical range; the grid maps that position into the much larger logical range of the dataset, works out the target row index, and renders the visible rows. The container's height no longer grows with the data, so a million rows never requires a 29,000,000-pixel element. Once that dependency was removed, the old ceiling disappeared, and the one-million-row example became the project's large-data demo.

Out of curiosity, the team then pushed further to 10 million rows, and the grid displayed those as well. The post is explicit that this was an architectural test rather than a recommendation.

Limits that remain

Logical scrolling removes exactly one constraint: the tie between dataset size and the maximum physical height of a DOM element. Everything else still scales with the data. The post lists memory usage, sorting, filtering, searching, serialization, network transfer and application state management as the real costs at large sizes, and points to server-side processing, pagination and incremental loading as the sensible strategies at that scale.

More than a benchmark

BGrid is aimed at business applications rather than record-chasing. Alongside virtual scrolling it currently offers cell editing, cell merging, sorting, filtering, summaries, pivot, frozen rows and columns, custom editors and keyboard navigation. The team says it built the grid because it wanted something open source, strongly typed and React-friendly for the applications it ships, and the Apache-2.0 license means no commercial license is needed for the open-source features.

Why it matters

The scroll-height ceiling is one of the quieter constraints in front-end engineering: any virtualized list whose dataset implies a taller spacer than the layout engine will handle is capped well below what JavaScript or memory can actually process. BGrid's fix is a useful reminder that the scrollbar is just an input device, and its physical range does not have to equal the dataset's extent. For log viewers, analytics tables and large result sets, the practical bottleneck now shifts back to data delivery and processing, where pagination and incremental loading belong anyway. And as another Apache-2.0 grid with editing, pivoting and frozen panes, BGrid widens the open-source options in a category where commercial licensing dominates.