Pretty good writeup. I can’t say I’m an expert on this topic, but I believe React using VDOM allows it to have what React team calls “transitions”. In simple terms, if triggering a state change will take long (loading code, data, or blocked on CPU) you can tell React to keep showing the current UI while working on the next screen. (Kinda like double buffering.) React also allows you to schedule a smaller state change to indicate loading state. This is available today.
This makes me think of React as not a UI library but a UI runtime. Reactive libraries, on the other hand, are not able to not “react” to state changes, they need to perform their work immediately. I think this is a limiting factor in building user interfaces, because it’s nearly impossible to perform work immediately, especially if network is involved. For this reason, a UI runtime that allows you to be more intentional about loading boundaries and different kinds of state changes, is more future proof.
Pretty good writeup. I can’t say I’m an expert on this topic, but I believe React using VDOM allows it to have what React team calls “transitions”. In simple terms, if triggering a state change will take long (loading code, data, or blocked on CPU) you can tell React to keep showing the current UI while working on the next screen. (Kinda like double buffering.) React also allows you to schedule a smaller state change to indicate loading state. This is available today.
This makes me think of React as not a UI library but a UI runtime. Reactive libraries, on the other hand, are not able to not “react” to state changes, they need to perform their work immediately. I think this is a limiting factor in building user interfaces, because it’s nearly impossible to perform work immediately, especially if network is involved. For this reason, a UI runtime that allows you to be more intentional about loading boundaries and different kinds of state changes, is more future proof.