4 ms·

I think a lot of what you're saying is very true. Its been said before that the React and SPA community in general has had the pleasure of rediscovering past co

I think a lot of what you're saying is very true. Its been said before that the React and SPA community in general has had the pleasure of rediscovering past concepts as the community has evolved. I suspect in a couple of years handling application state in your view layer, even using their native capabilities like Context in React or Vuex in Vue will be viewed as an anti-pattern. As I said in another comment. Effector is something that interests me as it seems to hit a lot of right ideas in terms of reactivity outside the view layer. It can hook into React with hooks or Vue with the Composition API. Hell its stores just work natively with Svelte. This brings us onto the most interesting point. Virtual DOM libraries aren't necessarily the only/best solution. Compiled solutions like Svelte and SolidJS are offering alternatives that address some of the size and performance concerns that VDOM libraries raise. If your state management is tied into that whole ecosystem, you have to throw all that away to benefit for advancements in the view layer. This is to say nothing of the fact that even sharing code between React and React Native is difficult to do easily. Whether Effector is the answer I don't know, but I believe it has the right ideas (it is inspired by the likes of Reframe and Flux). Something else might come along that is similar but presented better. However I could totally see a movement that espouses developing your apps data first and then wiring in your UI layer later. Maybe it would even have a TDD or repl based approach. Unfortunately I think it would ultimately be at odds with the beginner friendly, just get something working perspective that a lot of libraries take. How to bring new starters along so they can follow and understand is a much bigger question

Chris_Newton 6y ago
This brings us onto the most interesting point. Virtual DOM libraries aren't necessarily the only/best solution. That is surely true as well. Even a perfect implementation of a VDOM library is necessarily doing a lot of extra work compared to direct DOM updates if you already know exactly what needs changing. For a “typical” SPA, if there is such a thing, React’s virtual DOM system is fast enough to make its declarative UI strategy viable, which is enough to make it widely useful. However, it can still become a bottleneck given sufficiently demanding conditions. React without a lot of help can still choke quite easily if it’s asked to render something like a table with thousands of cells or an intricate SVG diagram that needs to animate smoothly. Giving React the help it needs typically means bypassing some of the diff logic one way or another, for example by providing sCU in a class-based component or a list of dependencies to hooks. However, these kinds of changes also introduce potential inconsistency between what you’d normally render and what gets rendered with a bypass in place, which creates an opportunity for bugs and seems to be fighting against the whole idea of declaring your UI once and then letting React worry about all the details of maintaining it.

Chris_Newton 6y ago

This brings us onto the most interesting point. Virtual DOM libraries aren't necessarily the only/best solution. That is surely true as well. Even a perfect implementation of a VDOM library is necessarily doing a lot of extra work compared to direct DOM updates if you already know exactly what needs changing. For a “typical” SPA, if there is such a thing, React’s virtual DOM system is fast enough to make its declarative UI strategy viable, which is enough to make it widely useful. However, it can still become a bottleneck given sufficiently demanding conditions. React without a lot of help can still choke quite easily if it’s asked to render something like a table with thousands of cells or an intricate SVG diagram that needs to animate smoothly. Giving React the help it needs typically means bypassing some of the diff logic one way or another, for example by providing sCU in a class-based component or a list of dependencies to hooks. However, these kinds of changes also introduce potential inconsistency between what you’d normally render and what gets rendered with a bypass in place, which creates an opportunity for bugs and seems to be fighting against the whole idea of declaring your UI once and then letting React worry about all the details of maintaining it.