While I agree with the sentiment of this comment (there are so many aspects of modern web development that are layers of abstracted complexity to re-invent wheels long-since optimised). However...
scrolling lists are, once one gets to thinking about them in depth, a lot more tricky to implement than they are to use. In fact I can't actually think of a better example of something that seems at first glance simple, but upon closer inspection is riddled with challenges.
It basically comes down to the simple question of: how do I render as little as possible at a time, but also render everything/anything in the list "immediately" or as fast as possible. These are fundamentally oppositional requirements, and no solution, whether arrived at after 20 or 50 years, will ever not be a compromise of some sort between them.
This was solved, you render the visible items, and a few extra items before and after, then when the user scrolls you never render new items widgets but recycle the existing ones and refresh their state to match. It is super efficient and was solved in many toolkits, I am sure it is done in Flex4.
An example from Flex4 is the DataGrid and AdvancedDataGrid.
You get a basic component for simple use cases and a very advanced one if you need stuff like resizable columns, re-ordering columns, sort-able columns.
IMO you don't have experienced with this powerfull tookits, your imagination is lacking and you think that shit that existed for so many years is impossible to do. Nah, it can be done but Google and Mozilla are focusing on JS and failling to implement even the most basic customization stuff for native components , they are probably not even aware that things can be done better because their heads are to deep into the web ass and not seen any good Desktop or mobile toolkit in their lives.
It has of course been "solved" many times in many toolkits, that wasn't my point.
My point was that each solution is a compromise, and none can ever be one-size-fits-all optimal.
Rendering "a few" items before and after is a heuristic requiring bounds which will produce variable performance impact depending on the content of your list items. It also doesn't account for scroll jumps at all.
Refreshing state is only more efficient than creating/destroying items in some systems and its performance characteristics are again highly dependent on the content of each list item in your application.
This not true, it was solved correctly before and nobody would force you to use an AdvancedDataGrid instead of a table or 100+nested divs.
>Refreshing state is only more efficient than creating/destroying items in some systems and its performance characteristics are again highly dependent on the content of each list item in your application.
YEs it depends but 99% of cases you refresh the string for some Label/Text components and some img src , since you do it with native code it will be much faster then creating new DOM elements or changing a DOM element attribute. Plus hacked-up widgets that are not native are forced to listen to tons of events and run non-native code to detect if they should or not run and what to do when to run.
TLDR the problem was solved, we need good enough widgets like in good toolkits and we can still give people the option to create their own "improved" version with their cool library if they want.
Scrolling lists is the first thing that comes to mind when I see someone proclaiming that PWAs will run the world soon, and everything will be based on web tech.
iPhone SDK has this from the very beginning. With data sources, delegates, reused cells, etc. It's even easier with SwiftUI (with swipe actions and what not). Yet people are willing to break even simple scroll on the web. Why?
> how do I render as little as possible at a time, but also render everything/anything in the list "immediately" or as fast as possible.
Isn’t that the constraint of basically any rendering system?
The html page itself — I want to only render what’s on screen, but still scroll down quickly
video games — I want to render only what’s in sight, but still turn quickly and render appropriately
Windows — I want to render the visible parts of opened apps, but still switch apps quickly
Etc
This isn’t fundamentally oppositional — it’s the most basic rendering optimization you’d apply (basically view culling), before getting into anything fancy
It is exactly, and it's a hard problem to generalise.
My point is that rendering a list widget is more complex than other widgets because it's as complex as general full-page rendering / scene rendering
> This isn't fundamentally oppositional — it's the most basic...
It can be both.
View culling is essentially the complexity I'm talking about. View culling is a heuristic, it produces different impacts depending on many variables within the view, as well as the parameters of your cull.
This isn't in the slightest bit true. Many UI frameworks provide performant list elements, they are not performant in all cases. Recreating the functionality of those list elements on the web is not the hard problem here: optimising them for your specific application is.
It is. I personally used a virtual list with custom rendering in Delphi in early 2000s. It is, for all intents and purposes, a solved problem. That is, solved everywhere else.
> Many UI frameworks provide performant list elements, they are not performant in all cases
Yes. On the web.
> Recreating the functionality of those list elements on the web is not the hard problem here
It is a very hard problem on the web because you don't have any APIs to do this properly: asking for element sizes causes the browser to recalculate the layout, you can't batch-render anything, and a million other things that are readily available, once again, literally everywhere else.
I've used virtual lists (outside the web). They often work well. They sometimes don't. I'm not refuting that they exist, I'm just refuting absolutist statements about their generalised perfection.
>> they are not performant in all cases
> Yes. On the web.
They are often very performant on the web (creating your own virtual list implementation is straightforward). They are often not performant in non-web environments. There is no major fundamental difference between web and non-web in this regard: it's just rendering content to a screen.
> asking for element sizes causes the browser to recalculate the layout
This isn't really the case as stated.
It's true if the layout has changed since last size read, as layout changes will trigger a layout flush, requiring recalc (which are done lazily). For Chrome, this is unfortunately a global flush, but for e.g. Firefox it's on a "frame" basis (an internal frame object, not HTML element). Recalc of dims, either eager or lazy, will be necessary for any drawing system (you're just looking at whether the request for a component size is an internal implementation detail or an application API).
> you can't batch-render anything
Not sure what this means? Why can't you batch-render on the web?
> It's true if the layout has changed since last size read
For elements that don't yet exist in screen and want to be "custom-rendered" this will be a change in size.
And while there's no element, you can't pre-calculate its size because there are no useful browser APIs for that. And you can't effectively control layout behaviour in the browser when you dump an element into it. And...
> > you can't batch-render anything
> Not sure what this means? Why can't you batch-render on the web?
There is no good way of telling a browser "pause rendering on this particular set of elements" and then "render these particular elements in one go". Any change you do to an element is immediately passed to the renderer.
scrolling lists are, once one gets to thinking about them in depth, a lot more tricky to implement than they are to use. In fact I can't actually think of a better example of something that seems at first glance simple, but upon closer inspection is riddled with challenges.
It basically comes down to the simple question of: how do I render as little as possible at a time, but also render everything/anything in the list "immediately" or as fast as possible. These are fundamentally oppositional requirements, and no solution, whether arrived at after 20 or 50 years, will ever not be a compromise of some sort between them.