4 ms·

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 ti

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
- brundolf 5y ago
  Right, so you're offloading the markdown processing but not the actual React render logic. Reasonable enough for this case, but doesn't translate to the majority of scenarios.

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

brundolf 5y ago
Right, so you're offloading the markdown processing but not the actual React render logic. Reasonable enough for this case, but doesn't translate to the majority of scenarios.