5 ms·

The biggest benefit to this is that it makes one of the slowest parts of virtual DOM diffing (longest common subsequence) no longer required. After this becomes

by wlib 2y ago

The biggest benefit to this is that it makes one of the slowest parts of virtual DOM diffing (longest common subsequence) no longer required. After this becomes supported in the mainstream, not even signal-based frameworks will have to include VDOM algorithms. I know this because I remember pushing for this to be supported a few years ago — a nice reminder that the standards are evolving and that nothing stops you from being a small part of the effort. Next up — DOM parts and standardized signals, unified.

dimal 2y ago
Why would this eliminate the need for any VDOM algorithm? I could see how it would simplify VDOM diffing but not eliminate it altogether.
- spankalee 2y ago
  VDOM hasn't been needed for a long while, if ever. You can do a lot better just checking if the template that/s rendering to a spot in the DOM is the same or different from the previous template. If it's the same, just update the bindings from the template, if it's different re-render the whole thing. That's simpler and faster, but the one thing it leaves out is stateful reordering of lists. So you can have a specific re-ordering code path, which is simpler than a full VDOM, but if you want to preserve state like moveBefore() does, even that reordering gets pretty complicated because you can only preserve state for one contiguous range of nodes that you don't actually move - instead you move all the other nodes around them. moveBefore() just eliminates all that extra complexity. There's also a couple of standards issues open for native reordering of siblings, like reorderChildren(). That would eliminate the re-ordering code completely.
  - theultdev 2y ago
    there's other reasons for the vdom though. vdom is necessary in react to abstract the view from the platform so it can be represented by react-dom and react-native[-x] bridges.
    - spankalee 2y ago
      That has very little bearing on the web platform. I personally don't care for meta-platforms that abstract away the web.
      - theultdev 2y ago
        It does have an impact on app development. I personally don't care for web-only libraries / frameworks.
        spankalee 2y ago
        I mean that's fine, but when mixed into a conversation on web standards and APIs it leads to a place where you don't care about any web-specific evolution including most progress on the DOM. You end up only caring about a future of WASM + WebGPU, etc. This is exactly where some of the original React core team said they wanted to go - they just wanted a network connected framebuffer. Again, fine, but I personally prefer a vibrant web platform that evolves to meet the needs of web developers.
        theultdev 2y ago
        Don't get me wrong, I'm happy for the change. It will improve things overall, and more power to web-only implementations. My only intent was to point out another function of the vdom being discussed. For WASM+WebGPU, I doubt it will ever be up to the same accessibility and feel that react-native-web gives. Just look at Flutter.
      - nsonha 2y ago
        I'm a web developer and the web api is bloated and ugly. React API is, or at least was, acceptable to work with.
    - wlib 2y ago
      You can still have a framework-specific render tree that maps to the DOM that tracks changes with signals instead of diffing. We’re just saying that there’s no requirement for diffing algorithms anymore to performantly and correctly reconcile state to the DOM. Keyed children was the last place it was needed.
spankalee 2y ago
DOM Parts + Signals will be an absolute game changer for the web platform. Then there's a direct line to built-in declarative reactive templating: https://github.com/WICG/webcomponents/issues/1069 https://github.com/WICG/webcomponents/issues/1069
giancarlostoro 2y ago
How do you even bring this up in a way that it gets noticed by the right people? There's so many times I read niche parts of the DOM that I feel need serious enhancements. I use Blazor (WASM) a lot more these days, so a lot of that is masked from me now.
notnullorvoid 2y ago
Signal based libraries already don't need VDOM. It's possible that it'll allow faster reordering of elements that are already connected, but the added checks needed to see if an element is connected (need to use insertBefore if not connected) might also cause overall perf regression. The main thing is that it allows elements to be moved without triggering disconnect/connect.

by wlib 2y ago

dimal 2y ago

Why would this eliminate the need for any VDOM algorithm? I could see how it would simplify VDOM diffing but not eliminate it altogether.

spankalee 2y ago
VDOM hasn't been needed for a long while, if ever. You can do a lot better just checking if the template that/s rendering to a spot in the DOM is the same or different from the previous template. If it's the same, just update the bindings from the template, if it's different re-render the whole thing. That's simpler and faster, but the one thing it leaves out is stateful reordering of lists. So you can have a specific re-ordering code path, which is simpler than a full VDOM, but if you want to preserve state like moveBefore() does, even that reordering gets pretty complicated because you can only preserve state for one contiguous range of nodes that you don't actually move - instead you move all the other nodes around them. moveBefore() just eliminates all that extra complexity. There's also a couple of standards issues open for native reordering of siblings, like reorderChildren(). That would eliminate the re-ordering code completely.
- theultdev 2y ago
  there's other reasons for the vdom though. vdom is necessary in react to abstract the view from the platform so it can be represented by react-dom and react-native[-x] bridges.
  - spankalee 2y ago
    That has very little bearing on the web platform. I personally don't care for meta-platforms that abstract away the web.
    - theultdev 2y ago
      It does have an impact on app development. I personally don't care for web-only libraries / frameworks.
      - spankalee 2y ago
        I mean that's fine, but when mixed into a conversation on web standards and APIs it leads to a place where you don't care about any web-specific evolution including most progress on the DOM. You end up only caring about a future of WASM + WebGPU, etc. This is exactly where some of the original React core team said they wanted to go - they just wanted a network connected framebuffer. Again, fine, but I personally prefer a vibrant web platform that evolves to meet the needs of web developers.
        theultdev 2y ago
        Don't get me wrong, I'm happy for the change. It will improve things overall, and more power to web-only implementations. My only intent was to point out another function of the vdom being discussed. For WASM+WebGPU, I doubt it will ever be up to the same accessibility and feel that react-native-web gives. Just look at Flutter.
    - nsonha 2y ago
      I'm a web developer and the web api is bloated and ugly. React API is, or at least was, acceptable to work with.
  - wlib 2y ago
    You can still have a framework-specific render tree that maps to the DOM that tracks changes with signals instead of diffing. We’re just saying that there’s no requirement for diffing algorithms anymore to performantly and correctly reconcile state to the DOM. Keyed children was the last place it was needed.

spankalee 2y ago

DOM Parts + Signals will be an absolute game changer for the web platform. Then there's a direct line to built-in declarative reactive templating: https://github.com/WICG/webcomponents/issues/1069 https://github.com/WICG/webcomponents/issues/1069

giancarlostoro 2y ago

How do you even bring this up in a way that it gets noticed by the right people? There's so many times I read niche parts of the DOM that I feel need serious enhancements. I use Blazor (WASM) a lot more these days, so a lot of that is masked from me now.

notnullorvoid 2y ago

Signal based libraries already don't need VDOM. It's possible that it'll allow faster reordering of elements that are already connected, but the added checks needed to see if an element is connected (need to use insertBefore if not connected) might also cause overall perf regression. The main thing is that it allows elements to be moved without triggering disconnect/connect.