Hacker News Reader

Comment by dbxkcichhdfufu | Hacker News Reader

Browsers already managed state just fine. We just didn't like the way it looked.

Browsers do nothing to help us manage state outside of individual elements.

That’s actually all I use for state management. Elements pass data to children through attributes and bubble data up through events. It’s worked well for us on a complex front-end using native web components.

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?

Which state are you referring to? I feel parent poster is talking about different state than what you have in mind.

The state that matters to users. All the rest is lies we tell ourselves.

There's a reason developers are constantly inventing ways to remove state from their code. Managing state is messy. Frameworks simply move it around.

Most react apps would be better off written in PHP, html, and progressively enhanced JS.

This is coming from a react developer. Most of what I do is bullshit work someone else invented for me.

But it pays well so ohwell.

Reply on news.ycombinator.com