4 ms·

I never got past 30,000. I'm sure there are applications where it could have meaning but I started noticing completely different performance trends. Certain way

I never got past 30,000. I'm sure there are applications where it could have meaning but I started noticing completely different performance trends. Certain ways of writing the code would work better at 30,000 but be slower at 500. Ultimately it seemed fruitless as increasing amount of effort is spent in the DOM. The amount the JS matters is so small. On one hand even 10k is too many rows as you'd likely use windowing. Instead I've been going the other way. Using less rows but using Chrome to throttle CPU. This lets you focus must more on what can be done in the JS.

alok-g 8y ago
I would like to understand your message better. Can you share more about this variation in the way of writing code in this situation? I am personally not a fan of this trend of browser libraries falling apart beyond a few tens of thousand items. Native apps scale well to such numbers of items and stay performant, albeit there would be a freeze for a while. Excel and Matlab come to mind as examples. I have given millions of items to both for real use cases.
- ryansolid 8y ago
  I was playing with using timeouts and request animation frame, along with storing certain internal objects in Maps vs Objects. All I meant was that the time the browser spends on rendering/layout/GC trumps an implementation code consideration. Optimized handwritten JS has the issue before even considering libraries. People attempt to come up with smarter solutions rather than actually just rendering a million rows. Playing with timeouts and asynchronous rendering the view in parts is an approach. Windowing is another, by which I mean setting a viewport essentially(ie only render what's in view). But currently these sit in userland since there are tradeoffs. I've seen libraries try to offload to WebWorkers but every attempt I've seen so far in that vein is slower than just optimal main thread code. I know the WASM crowd is looking into that. Also things like Time Slicing in React Fiber are trying to bring this to the library level. And Solid's primitives can be used to similar effect but these approaches aren't generalized yet. It's one of the areas I see Solid's model having an advantage.
  - alok-g 8y ago
    This is helpful for me to follow the details. Thanks!

alok-g 8y ago

I would like to understand your message better. Can you share more about this variation in the way of writing code in this situation? I am personally not a fan of this trend of browser libraries falling apart beyond a few tens of thousand items. Native apps scale well to such numbers of items and stay performant, albeit there would be a freeze for a while. Excel and Matlab come to mind as examples. I have given millions of items to both for real use cases.

ryansolid 8y ago
I was playing with using timeouts and request animation frame, along with storing certain internal objects in Maps vs Objects. All I meant was that the time the browser spends on rendering/layout/GC trumps an implementation code consideration. Optimized handwritten JS has the issue before even considering libraries. People attempt to come up with smarter solutions rather than actually just rendering a million rows. Playing with timeouts and asynchronous rendering the view in parts is an approach. Windowing is another, by which I mean setting a viewport essentially(ie only render what's in view). But currently these sit in userland since there are tradeoffs. I've seen libraries try to offload to WebWorkers but every attempt I've seen so far in that vein is slower than just optimal main thread code. I know the WASM crowd is looking into that. Also things like Time Slicing in React Fiber are trying to bring this to the library level. And Solid's primitives can be used to similar effect but these approaches aren't generalized yet. It's one of the areas I see Solid's model having an advantage.
- alok-g 8y ago
  This is helpful for me to follow the details. Thanks!