Thread by @dan_abramov

I wonder if our early messaging about Concurrent Mode should have been focused on mounts rather than updates. Some of the conversation I’m seeing assumes we could just “do less work” which is not an option for rendering *new* subscreens — where granular rerendering doesn’t help.

This depends on the app — some apps, like dataviz, almost exclusively do “updates”. So dataviz example, while effective visually, may have been a misdirection. In consumer apps a lot of the interactions we want to make smoother are mounts — like switching tabs or infinite scroll.

There’s also a question of responsibility. We consider what happens when you have hundreds of components that all run a little bit of code *our* responsibility. Userland code then dwarves library overhead in CPU time. We can’t just wash our hands and say “don’t write slow code”.

Granular rerendering is certainly useful (and disproportionally useful for dataviz and graphical editors). There are several ways you can solve it. The problem with many popular solutions is that they preclude solving the mounts. This is why we start from the other end.

There are many features that your library gets if you solve non-blocking mounts. Like pre-rendering the contents of a hidden tab optimistically without blocking the initial paint and delaying user input. Or rendering long lists in visually intentional chunks.

I don’t care if the library authors of today see this as a problem worth solving. But I want to inspire the authors of libraries of tomorrow to at least consider it. We have several tabs, each has a deep tree inside, each layer has a fixed user code cost. Now make it responsive.

Maybe this problem alone by itself isn’t worth your effort. It is hard. But if you spend enough time on it, you might discover that other areas — animations, data fetching, hydration, code splitting — now allow new solutions you couldn’t consider before. If your model allows it.