>Apply separation of concerns properly With the component paradigm, these things can't always easily be separated. Or, it is useful to consolidate data concern

>Apply separation of concerns properly With the component paradigm, these things can't always easily be separated. Or, it is useful to consolidate data concerns and UI concerns, but often data concerns like UI have a hierarchy, or the concerns are spread all over the place (not in neat, clear groups). It is very useful to declaratively specify the recipe for both UI and data, and allow the framework to coordinate these things across and within components. >Rendering should never need to be interrupted. Following this line of thought would lead to not rendering anything until everything is ready. Large applications have multiple levels of components and data concerns. These solutions allow for isolating responsibilities at smaller levels, and coordinating their presentation in ways that produce good UI (few loading spinners, flickering etc). >and if limited to that use This simply passes the responsibility somewhere else no? And any significant apps can't avoid these concerns. You'd still be left with the coordination between React and whatever else was handling these concerns, but with much more code likely to tie them together.