3 ms·

You issue is likely due to a heavy computation blocking the main js thread (rendering). In this scenario the suspense api will not solve the UI lag. I've had th

You issue is likely due to a heavy computation blocking the main js thread (rendering). In this scenario the suspense api will not solve the UI lag. I've had the exact same pattern with a home build markdown editor where the right side preview should render quick, but lag behind if too heavy and give priority to left hand side. I tried the alpha and speak from my own experiences, you'll have better luck by offloading render computations to a background web worker. The preview can do a 1 time synchronous render, cache the result in it's local component react state, then all future state updates are computed async on the background thread. Main thread left unblocked

Waterluvian 5y ago
It's considerably more complex than that. There's just a lot of stuff that gets compiled and rendered. No single part takes more than a few milliseconds, so I can bin it across many tasks. Picture a canvas that I'm calculating then drawing tens of thousands of elements to before displaying it. Very binnable. Very hard to get right to a point that you can't "feel" the lag when working with the rest of the app. I also explored web workers but it's currently more hassle than I want to be bothered with.
- pier25 5y ago
  If your use case requires rendering and updating thousands of components, maybe React wasn't a good fit? You could try switching to Preact which has better performance and should be painless. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
  - Waterluvian 5y ago
    Not components. Elements that compile to a canvas. Think tens of thousands of points, lines, polygons, all drawn as vector or raster images. Ie. compiling a deeply rich interactive map of data. I appreciate the advice but I didn't provide sufficient information for informed responses. It was just a general comment about why I'm excited for React 18 to help better manage concurrency in a number of ways. Suspense will also be nice because I can eliminate a lot of my own "loading screen" logic.
    - pier25 5y ago
      > Not components. Elements that compile to a canvas. Ah right. I thought the canvas example was just an example. Still, a faster framework would be better for high performance use case, no?
brundolf 5y ago
The problem comes when the rendering itself is the bottleneck. You can't put that on a Worker because it's so entwined with the DOM. We ran into this several times at a past company where our UIs rendered elements in the 10s of thousands, and we had no real recourse except to optimize everything to death (and things were still laggy). In one case we implemented our own, bespoke, crappy equivalent of suspended rendering and it was a mess but it was just barely worth it because we were so desperate.
- KronisLV 5y ago
  > We ran into this several times at a past company where our UIs rendered elements in the 10s of thousands Maybe that's the real problem? If at all possible, such intensive tasks should be done in native frameworks, not web technologies. Alternatively, why not simply do less? Pagination, extracting separate sections of the app into separate pages/views and many others are perfectly valid approaches to something like that in my eyes, not just turning to low level optimizations.
  - brundolf 5y ago
    We had various project constraints and user demands that made most of those suggestions untenable. We used pagination in some places, but in others our users refused to accept it (they wanted Ctrl+F, fast browsing of huge datasets, etc). Writing a native app would have been miles outside the realm of possibility (we had a small team making a very complex product, none of us had native app experience, we needed to support multiple platforms, we specifically needed instances of our server to be able to serve up their own GUI, we needed to be able to interface with them from arbitrary remote machines without installing new software, etc). To use the words of a commenter in another thread: I didn't provide sufficient information for informed responses. It was just a general comment about why I'm excited for React 18 to help better manage concurrency in a number of ways.
- stevemk14ebr 5y ago
  In my case the right hand preview being generated is literally HTML that is presented as formatted markdown. The solution for me was to detach the generated markdown html tree from the creation of the react elements. You can have the worker return a json tree shape that defines all the elements it wishes to place onto the dom, ships it over to the main react element that React.CreateElement's through the tree. This way the cached elements can be shown until the new tree elements are created and you can just react setState to the new elements and it's instant

Waterluvian 5y ago

It's considerably more complex than that. There's just a lot of stuff that gets compiled and rendered. No single part takes more than a few milliseconds, so I can bin it across many tasks. Picture a canvas that I'm calculating then drawing tens of thousands of elements to before displaying it. Very binnable. Very hard to get right to a point that you can't "feel" the lag when working with the rest of the app. I also explored web workers but it's currently more hassle than I want to be bothered with.

pier25 5y ago
If your use case requires rendering and updating thousands of components, maybe React wasn't a good fit? You could try switching to Preact which has better performance and should be painless. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- Waterluvian 5y ago
  Not components. Elements that compile to a canvas. Think tens of thousands of points, lines, polygons, all drawn as vector or raster images. Ie. compiling a deeply rich interactive map of data. I appreciate the advice but I didn't provide sufficient information for informed responses. It was just a general comment about why I'm excited for React 18 to help better manage concurrency in a number of ways. Suspense will also be nice because I can eliminate a lot of my own "loading screen" logic.
  - pier25 5y ago
    > Not components. Elements that compile to a canvas. Ah right. I thought the canvas example was just an example. Still, a faster framework would be better for high performance use case, no?

brundolf 5y ago

The problem comes when the rendering itself is the bottleneck. You can't put that on a Worker because it's so entwined with the DOM. We ran into this several times at a past company where our UIs rendered elements in the 10s of thousands, and we had no real recourse except to optimize everything to death (and things were still laggy). In one case we implemented our own, bespoke, crappy equivalent of suspended rendering and it was a mess but it was just barely worth it because we were so desperate.

KronisLV 5y ago
> We ran into this several times at a past company where our UIs rendered elements in the 10s of thousands Maybe that's the real problem? If at all possible, such intensive tasks should be done in native frameworks, not web technologies. Alternatively, why not simply do less? Pagination, extracting separate sections of the app into separate pages/views and many others are perfectly valid approaches to something like that in my eyes, not just turning to low level optimizations.
- brundolf 5y ago
  We had various project constraints and user demands that made most of those suggestions untenable. We used pagination in some places, but in others our users refused to accept it (they wanted Ctrl+F, fast browsing of huge datasets, etc). Writing a native app would have been miles outside the realm of possibility (we had a small team making a very complex product, none of us had native app experience, we needed to support multiple platforms, we specifically needed instances of our server to be able to serve up their own GUI, we needed to be able to interface with them from arbitrary remote machines without installing new software, etc). To use the words of a commenter in another thread: I didn't provide sufficient information for informed responses. It was just a general comment about why I'm excited for React 18 to help better manage concurrency in a number of ways.
stevemk14ebr 5y ago
In my case the right hand preview being generated is literally HTML that is presented as formatted markdown. The solution for me was to detach the generated markdown html tree from the creation of the react elements. You can have the worker return a json tree shape that defines all the elements it wishes to place onto the dom, ships it over to the main react element that React.CreateElement's through the tree. This way the cached elements can be shown until the new tree elements are created and you can just react setState to the new elements and it's instant