By shadow DOM do you mean the virtual DOM? The shadow DOM is also a thing, but it's largely unrelated to web frameworks.
The idea behind the virtual DOM is that it's usually easier to render everything in a functional sort of way. You treat rendering like a function that takes state as an argument, and returns your desired UI. Every time an event handler fires and changes some state somewhere, you rerun all the functions with the new state and that produces a (potentially different) UI.
For various reasons, it's not practical for these functions to actually return a new DOM every time the state changes, so instead they return the VDOM, which is a description of what the DOM should look like, and React diffs the real DOM against the VDOM and updates it if there are any changes. This way, if you've got an input that the user is typing in, it doesn't get replaced completely every time the component updates, but React might update properties on it as they change.
Originally the React team talked about how the VDOM made React faster, and this claim got stuck in everyone's heads, but it's not really true. The VDOM allows React to separate the rendering phase (i.e. when all the component render functions are called) and the DOM update phase, which can have some performance improvements against more naive approaches, but if you could optimally update the DOM directly whenever state changes, then this would still always be quicker. (And a lot of frameworks are moving towards this model, and away from the more React-like VDOM approach.) The main benefit of the VDOM is that it simplifies the programming model: it allows the "UI as a function of state" concept, and makes it easier to reason about what's happening while a render function is being executed.
A lot of more modern frameworks are moving away from VDOM-based approaches, although React is staying very much where it is. Like I said, there are faster approaches, but these arguably come with tradeoffs about complexity. Personally, I tend to avoid React because of the VDOM approach, in large part because it's a layer of abstraction that I don't really need.
The idea behind the virtual DOM is that it's usually easier to render everything in a functional sort of way. You treat rendering like a function that takes state as an argument, and returns your desired UI. Every time an event handler fires and changes some state somewhere, you rerun all the functions with the new state and that produces a (potentially different) UI.
For various reasons, it's not practical for these functions to actually return a new DOM every time the state changes, so instead they return the VDOM, which is a description of what the DOM should look like, and React diffs the real DOM against the VDOM and updates it if there are any changes. This way, if you've got an input that the user is typing in, it doesn't get replaced completely every time the component updates, but React might update properties on it as they change.
Originally the React team talked about how the VDOM made React faster, and this claim got stuck in everyone's heads, but it's not really true. The VDOM allows React to separate the rendering phase (i.e. when all the component render functions are called) and the DOM update phase, which can have some performance improvements against more naive approaches, but if you could optimally update the DOM directly whenever state changes, then this would still always be quicker. (And a lot of frameworks are moving towards this model, and away from the more React-like VDOM approach.) The main benefit of the VDOM is that it simplifies the programming model: it allows the "UI as a function of state" concept, and makes it easier to reason about what's happening while a render function is being executed.
A lot of more modern frameworks are moving away from VDOM-based approaches, although React is staying very much where it is. Like I said, there are faster approaches, but these arguably come with tradeoffs about complexity. Personally, I tend to avoid React because of the VDOM approach, in large part because it's a layer of abstraction that I don't really need.