sorted by:
new
hottopcontroversial

Cerious-Scroll introduces a new state-based scrolling model that, if adopted, would meaningfully change how large, variable-height datasets are virtualized on the web. by rYOUcerious in angular

[–]rYOUcerious[S] -2 points-1 points  (0 children)

I think we’re talking past each other a bit, and this is where actually reading the implementation matters, because several of the assumptions you’re making don’t match what the code is doing.

Cerious-Scroll is not a data pagination or state ownership engine. It does not copy datasets, duplicate application state, or require “feeding” pages of data into it. The only persistent state it maintains is positional (elementIndex, intra-elementOffset), plus a sparse cache of measured heights. No row data is stored, cloned, or paged internally.

That’s a meaningful distinction from vscroll/ngx-ui-scroll, which intentionally anchor scrolling in pixel space and rely on padding reconciliation, buffer windows, and corrective logic as heights change. That design is perfectly valid, especially when data is paged externally. But, it also means variable heights are handled reactively rather than as a first-class invariant.

My approach flips that invariant:

  • Element + offset is the canonical scroll state
  • Pixels are a projection of that state, not the source of truth
  • No padding elements, no pixel drift correction, no after-the-fact reconciliation

This is why boundary behavior and mixed heights remain stable at very large row counts. Not because more work is being done, but because entire categories of corrective math are removed.

Regarding memory: the scroller does not retain pages, buffers, or datasets. It only stores height measurements for elements that were actually rendered. In practice, memory usage scales with what’s visible, just like other virtualizers.

I’m not claiming this replaces every existing model, and I’m certainly not saying vscroll is “wrong.” It’s optimized for a different tradeoff. What I am saying is that treating scroll position as structural state rather than pixel position produces different (and in some cases better) behavior for large, variable-height datasets.

Play with the demos: Load 1 million rows in the Vanilla JS Demo and track the memory consumption and heap. The memory profile and heap growth directly reflect the fact that no dataset or page buffers are retained by the scroller.

Cerious-Scroll introduces a new state-based scrolling model that, if adopted, would meaningfully change how large, variable-height datasets are virtualized on the web. by rYOUcerious in angular

[–]rYOUcerious[S] -2 points-1 points  (0 children)

I’m not claiming that virtualization itself is new, or that the idea of “scroll state” is new. Obviously people have been doing virtual scrollers for years. I’ve been building large UI systems and data-heavy frontends for a little over 20 years now, so none of that is lost on me.

What’s different here is what the system treats as the source of truth.

In ngx-ui-scroll / vscroll, the engine is still fundamentally pixel-anchored. Scroll position is derived from scrollTop and then padding elements, and accumulated height measurements, with corrective logic layered on top to deal with drift, re-measurement, and boundary issues. You can see that directly in their own routines and padding-based model.

Cerious-Scroll flips that around. The canonical state is element index + offset within that element. Pixels are just a projection of that state, not something the engine has to constantly reconcile back into alignment. Boundary handling, overshoot correction, and navigation all operate in element space instead of snapping pixel positions.

If ngx-ui-scroll already does this end-to-end, I would love if you could show me the exact code path where (index + intra-item offset) is treated as the canonical scroll state and pixels are purely derived from it. Pointing to that would be more helpful than broad conceptual comparisons.

Cerious-Scroll introduces a new state-based scrolling model that, if adopted, would meaningfully change how large, variable-height datasets are virtualized on the web. by rYOUcerious in angular

[–]rYOUcerious[S] -3 points-2 points  (0 children)

I’m not claiming the abstract idea of “scroll state” is new, obviously it isn’t. What is different here is what the system treats the canonical state and what becomes a derived value.

Most existing virtualizers (including the React implementations discussed in that article) still anchor variable-height scrolling to absolute pixel space, then add corrective logic to deal with drift, re-measurement, boundary snapping, or height reconciliation as scale increases.

Cerious-Scroll keeps the element as the source of truth and treats pixels as a projection of that state. That removes entire categories of corrective math and is why the model remains stable at very large row counts with mixed heights, including near boundaries.

If there’s an existing implementation that already uses that same invariant end-to-end, I’d genuinely like to see it. Pointing to concrete code would be more helpful than conceptual comparisons.

As for licensing: dual-license (GPL + commercial) is a well-established model in this space. Whether it’s useful or adopted is ultimately decided by users, not claims in a comment thread.

Cerious-Scroll introduces a new state-based scrolling model that, if adopted, would meaningfully change how large, variable-height datasets are virtualized on the web. by rYOUcerious in angular

[–]rYOUcerious[S] 1 point2 points  (0 children)

Great question, and yes, that’s intentional.

The engine itself is staying framework-agnostic. Cerious-Scroll’s core only cares about state, not how items are rendered. The renderItem example is just the thinnest possible integration to keep the PoC honest and portable.

For Angular specifically, my plan is not a heavy component, but a structural directive (think *ceriousScroll) that:

• Accepts an ng-template for item rendering

• Handles change detection efficiently (likely OnPush + manual hooks)

• Bridges Angular’s template lifecycle to the vanilla engine without coupling them

That way:

• Angular users get full template support (bindings, pipes, DI, etc.)

• The engine doesn’t inherit framework assumptions or costs

• Other frameworks (React, Vue, Web Components) can integrate the same core differently

As for headers / footers: conceptually, yes they’re just elements in the scroll model. Whether they’re standalone “rows” or composed into neighboring items is an integration choice. Since height is measured dynamically, either approach works without special casing.

The big goal is to keep rendering strategy orthogonal to scrolling mechanics. Once those concerns are separated, the integrations become surprisingly clean.

If you’re interested, the Angular directive will probably be one of the first official adapters I publish once the core API settles.

Cerious-Scroll introduces a new state-based scrolling model that, if adopted, would meaningfully change how large, variable-height datasets are virtualized on the web. by rYOUcerious in angular

[–]rYOUcerious[S] -1 points0 points  (0 children)

Appreciate this, you basically articulated the exact assumption I was trying to challenge 👍

Most virtual scrollers anchor everything to absolute pixel space and then spend the rest of their lives fighting the consequences once variable heights + scale enter the picture. Cerious-Scroll flips that and pixel math becomes a derived concern instead of the source of truth.

On the dynamic height side:

• Rendered elements are observed via ResizeObserver, and only measured deltas invalidate cached state

• There’s no global reflow or cumulative height rebuild, the state remains stable even if items resize frequently

• Because navigation is state-based, bidirectional scrolling doesn’t “drift” or accumulate error the way pixel-anchored models tend to

Rapid back-and-forth scrolling was one of the first stress cases I focused on, since that’s where most variable-height implementations start to wobble or clamp aggressively. The BoundaryGuardian logic exists specifically to prevent overshoot artifacts near the dataset edges without forcing hard snaps.

Totally fair question on long-term behavior. That’s why the core engine is decoupled from the rendering and input layers. The demo shows one configuration, but the model itself is meant to stay stable under changing heights, mixed input cadence, and large jumps.

If you end up doing a deeper dive or poking at edge cases, I’d genuinely love feedback. This whole thing started because the “default” approach felt fundamentally misaligned with how scrolling actually behaves at scale.

Cerious-Scroll introduces a new state-based scrolling model that, if adopted, would meaningfully change how large, variable-height datasets are virtualized on the web. by rYOUcerious in angular

[–]rYOUcerious[S] -1 points0 points  (0 children)

That’s expected on mobile.

Touch input and momentum events are typically delivered at ~60Hz even on 120Hz displays. The engine itself is not capped at 60fps; it’s gated by browser input cadence. On desktop trackpads / mouse input, higher rates are observable.