Hacker News Reader

Comment by Waterluvian | Hacker News Reader

I'm pretty delighted by a lot of the concurrency stuff that's popping up.

At this very moment I'm wrestling with a UI where the left side is a list of cartographic datasets, and the right side is a rich OpenLayers preview renderer.

I want the right side to be "low priority" where it tries to render a preview, but is happy to abort or not get done in-time if the user selects a different dataset. At the moment, the processing acquiring and rendering the preview makes the rest of the UI a bit laggy.

I suspect a good bit of my custom code can be replaced with some of this transition stuff.

View on HN

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

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.

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.ht...

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.

> 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?

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.

> 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.

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.

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

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.

I know you said you are not expecting informed suggestions but it got me thinking of another solution that has not been proposed. If the right ui is low priority and you want to unblock the left window's thread then maybe just a iframe for the right side would separate the work loads completely.

Reply on news.ycombinator.com