3 ms·

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

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.

dmitriid 5y ago
> This isn't in the slightest but true. 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.
- lucideer 5y ago
  > It is. I personally used a virtual list 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?
  - dmitriid 5y ago
    > 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.

dmitriid 5y ago

> This isn't in the slightest but true. 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.

lucideer 5y ago
> It is. I personally used a virtual list 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?
- dmitriid 5y ago
  > 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.