3 ms·

it sounds sort of wild to expect there to be diffing! why do you have to generate a whole copy of the stuff instead of just telling the browser what changes to

it sounds sort of wild to expect there to be diffing! why do you have to generate a whole copy of the stuff instead of just telling the browser what changes to make? bonus: the existing apis instead of one that don't exist yet.

Bilal_io 5y ago
Diffing seems necessary when your UI gets complicated to the level that a small change requires a full page re-render. However, I don't think this is necessary for at least 95% of the websites on the internet.
dymk 5y ago
Diffing is exactly what you need to do (barring newer methods like svelte) to figure out what to tell the browser to change. The vdom tree is much faster to manipulate than DOM nodes.
- recursive 5y ago
  But you can't see those changes until the actual DOM changes as well. It's only because of react's insistence that mutation is evil that this became a problem. You could just directly update the thing you wanted to and just skip the whole diff thing.
  - dymk 5y ago
    No, the reason React has a VDOM is because the DOM is slow to update, compared to manipulating javascript objects. It's worthwhile to calculate the list of minimum updates ahead of time rather than using the DOM as the source of truth. Not sure where you think mutation comes into play here, that's an orthogonal concern—you can have an API that mutates some internal representation of a VDOM, and it's still faster than manipulating the DOM directly.
    - recursive 5y ago
      In order to achieve immutability, large chunks of state have to be cloned whenever a single value changes. This sometimes causes a whole new DOM node to be created during reconciliation. React encourages you not to think about it too much. But some nodes can't be replaced. Like canvas or anything contentEditable. It's not orthogonal. It's a direct consequence of the design philosophy.
Philip-J-Fry 5y ago
Because it can be automated? Every app that doesn't do this is just implementing the diff by hand, e.g. on this event delete this element, update this element, add CSS class to this element, etc. When the UI gets complicated you have to maintain this all yourself and it's a pain. Multiple event listeners between components to say something has happened. It makes sense to be able to describe what you want to achieve and to let the browser determine how to get there in the most efficient way. If the browser could do this it would make a tonne of JS code so much simpler. There's a lot that goes into making sure that there's no unnecessary DOM updates because it's just slow. I don't write assembly and move things between registers by hand, I write a function and the compiler decides the most efficient way of doing it. UI should be the same way, I say what I want to happen and the browser decides how to get there.
- 5560675260 5y ago
  > When the UI gets complicated you have to maintain this all yourself and it's a pain This is also something that can be automated by a framework. Check out https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead
  - Philip-J-Fry 5y ago
    Yes... but that's the exact argument I'm making here. Unless you want to go through that pain, you need a framework. Whether that's Svelte without a VDOM or React with a VDOM. The entire point of these frameworks is that you can write complex UI in a declarative way. They both exist because writing it declaratively in pure JS leads to performance issues. But there's nothing stopping the browser implementing something that does this optimisation for you.
    - recursive 5y ago
      I find the "pain" to be drastically overstated. See this HN post.
      - 4y ago

Bilal_io 5y ago

Diffing seems necessary when your UI gets complicated to the level that a small change requires a full page re-render. However, I don't think this is necessary for at least 95% of the websites on the internet.

dymk 5y ago

Diffing is exactly what you need to do (barring newer methods like svelte) to figure out what to tell the browser to change. The vdom tree is much faster to manipulate than DOM nodes.

recursive 5y ago
But you can't see those changes until the actual DOM changes as well. It's only because of react's insistence that mutation is evil that this became a problem. You could just directly update the thing you wanted to and just skip the whole diff thing.
- dymk 5y ago
  No, the reason React has a VDOM is because the DOM is slow to update, compared to manipulating javascript objects. It's worthwhile to calculate the list of minimum updates ahead of time rather than using the DOM as the source of truth. Not sure where you think mutation comes into play here, that's an orthogonal concern—you can have an API that mutates some internal representation of a VDOM, and it's still faster than manipulating the DOM directly.
  - recursive 5y ago
    In order to achieve immutability, large chunks of state have to be cloned whenever a single value changes. This sometimes causes a whole new DOM node to be created during reconciliation. React encourages you not to think about it too much. But some nodes can't be replaced. Like canvas or anything contentEditable. It's not orthogonal. It's a direct consequence of the design philosophy.

Philip-J-Fry 5y ago

Because it can be automated? Every app that doesn't do this is just implementing the diff by hand, e.g. on this event delete this element, update this element, add CSS class to this element, etc. When the UI gets complicated you have to maintain this all yourself and it's a pain. Multiple event listeners between components to say something has happened. It makes sense to be able to describe what you want to achieve and to let the browser determine how to get there in the most efficient way. If the browser could do this it would make a tonne of JS code so much simpler. There's a lot that goes into making sure that there's no unnecessary DOM updates because it's just slow. I don't write assembly and move things between registers by hand, I write a function and the compiler decides the most efficient way of doing it. UI should be the same way, I say what I want to happen and the browser decides how to get there.

5560675260 5y ago
> When the UI gets complicated you have to maintain this all yourself and it's a pain This is also something that can be automated by a framework. Check out https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead
- Philip-J-Fry 5y ago
  Yes... but that's the exact argument I'm making here. Unless you want to go through that pain, you need a framework. Whether that's Svelte without a VDOM or React with a VDOM. The entire point of these frameworks is that you can write complex UI in a declarative way. They both exist because writing it declaratively in pure JS leads to performance issues. But there's nothing stopping the browser implementing something that does this optimisation for you.
  - recursive 5y ago
    I find the "pain" to be drastically overstated. See this HN post.
    - 4y ago