[simion314]

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.

[lucideer]

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.

[simion314]

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.