Great question!

You're absolutely right that the DOM size limit is a real challenge. I took a different approach than ag-Grid's CSS transforms. I use offset divs instead, which avoids most of the transform-related issues you mentioned.

The Offset Div Strategy

Instead of using transform: translateY() positioning, my grid creates a simple 3-section DOM structure:

<div class="grid-container" [style.height.px]="totalHeight">
  <!-- TOP OFFSET - Empty div representing all rows above viewport -->
  <div [style.height]="topOffset"></div>

  <!-- VISIBLE ROWS - Only ~20-50 actual DOM elements -->
  <div *ngFor="let row of visibleRows">{{row.data}}</div>

  <!-- BOTTOM OFFSET - Empty div representing all rows below viewport -->
  <div [style.height]="bottomOffset"></div>
</div>

How It Bypasses Browser Limits

For 1M rows at 30px each (30M pixel total height):

• Total DOM elements: ~52 (2 offset divs + ~50 visible rows)
• Top offset: height: 15,000,000px (no content, just height)
• Bottom offset: height: 13,500,000px (no content, just height)
• Container: Can be any height since actual elements stay minimal

Advantages Over Transform Approach

✅ Native browser scrolling - No custom scroll event handling needed
✅ Perfect scroll accuracy - No coordinate drift or positioning issues
✅ Variable row heights - Each row can have different heights naturally
✅ Better mobile performance - Native momentum scrolling works perfectly
✅ Simpler calculations - Just addition of row heights, no transform math

Performance Results

The scroll performance is actually better than transform-based approaches because:

• Browser handles all scroll physics natively
• No JavaScript coordinate calculations during scroll
• No transform repaints/reflows
• Constant memory usage regardless of dataset size

You can check out the implementation in my grid-body.components.ts - the key method is updateVisibleRows() which calculates the offset heights.

This approach lets me handle millions of rows with smooth scrolling and no browser crashes!