Comment by jwells89 | Hacker News Reader

Comment by jwells89 | Hacker News Reader

Parent Full thread

In these situations what’s eating up your resources usually isn’t the data being represented but instead the representation.

This is why native apps use recycler views for not just infinite scroll, but anything that can display more rows/columns/items/etc than can fit on screen at once. Recycler views only create just enough cells to fill the screen even if you have tens of thousands of items to represent, and when you scroll they reuse these cells to display the currently relevant segment of data. When used correctly by developers, these are very lightweight and allow 60FPS scrolling of very large lists even on very weak devices.

These are possible to implement in JavaScript in browsers, but implementation quality varies a lot and many web devs just never bother. This is why I think HTML should gain a native recycler widget of its own, because the engineers working on Blink, Gecko, and WebKit are in much better positions to write high quality optimized implementations, plus even if web devs don’t use it directly, many frameworks will.

There was a proposal for a browser-native virtual scroller: https://wicg.github.io/virtual-scroller/

Apparently it was abandoned (for now?) in favor of content-visibility / CSS containment primitives: https://web.dev/articles/content-visibility

I find this idea interesting ‘These are possible in JavaScript in browsers, but implementation quality varies a lot and many web devs just never bother.’

Do you have any examples that you consider good implementations? I ask because tables seem to be the biggest offenders of slow components in say Angular / PrimeNG. I am going to a legacy app soon that is being updated (Angular but not PrimeNG). Would like to see if we can build a feature rich table that is more performant than the PrimeNG one that I know looks amazing but is the cause of many headaches.

NOTE: its not Angular or PrimeNG specifically that make the tables slow/hogs, but the amount of DOM elements inside and some of the implementation details that I disagree with (functions that are called withing the HTML being evaluated every tick). Would be great to see if this idea of a ‘recycler widget’ can help us. Cheers.

> its not Angular or PrimeNG specifically that make the tables slow/hogs, but the amount of DOM elements inside

Yep, this happens even with nothing but a 10-line vanilla JS file that adds N more items every time the user scrolls to the bottom of the page. Performance degradation increases with every load due to the growing number of DOM elements which eventually exceeds whatever margin is afforded by the machine the browser is running on, causing chug.

Web is not my specialty so I don’t have specific recommendations, but plenty of results turn up when searching for e.g. “angular recycler” or “react recycler”.

We do this at Fastmail and, if I say so myself, our implementation is pretty damn good. We’ve had this for over a decade, so it was originally built for much lower powered devices.

These suck donkey balls because they break searching for keywords on the page.

Which is another reason why an HTML-native recycler is desirable. The browser could be easily avoid this is issue if it were the one to implement the recycler, rather than it being a third-party bolt-on.

Reply on news.ycombinator.com