That's basically a home-made React (& co.) duplicate (which is great). This simplifies development considerably, because you break the original problem into a) updating the state and b) translating the state into UI elements, and the framework (hopefully) automatically updates UI as needed.

This is called prop drilling. It technically works for any size or complexity of app if you're willing to make every intermediate component have knowledge about every possible piece of state that might be wanted by a component lower in the tree. It's extremely cumbersome though.

Back in my day we could search for child elements with specific attributes without needing the intermediate elements to know anything about it.

What REALLY happened is the shadow DOM. People decided it was too slow and created an intermediate representation. That then created all kinds of OTHER problems that started resulting in solutions that wouldn't have been necessary without the shadow DOM.

A shadow DOM is basically a cache, with all the problems that entails.

> Note that the shadow DOM is not a new thing by any means — browsers have used it for a long time to encapsulate the inner structure of an element.

https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

And for even longer than that, it was a term describing the technique of keeping a tree-like structure that would gather updates so you could eventually update the actual DOM all in one go because updating the DOM piecemeal was slow.

The term was popularized long before "web components" was a thing, and in fact, that's where they got the name.

Do you mean virtual DOM?