5 ms·

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

by dbxkcichhdfufu 4y ago

have_faith 4y ago
Browsers do nothing to help us manage state outside of individual elements.
- hellcow 4y ago
  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.
  - bornfreddy 4y ago
    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.
  - have_faith 4y ago
    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.
    - P5fRxh5kUvp2th 4y ago
      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.
      - dalmo3 4y ago
        > 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/Using_shadow_DOM https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
        P5fRxh5kUvp2th 4y ago
        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.
      - creatable 4y ago
        Do you mean virtual DOM?
    - deleted 4y ago
      [deleted]
ozim 4y ago
Which state are you referring to? I feel parent poster is talking about different state than what you have in mind.
- dbxkcichhdfufu 4y ago
  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.

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

have_faith 4y ago

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

hellcow 4y ago
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.
- bornfreddy 4y ago
  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.
- have_faith 4y ago
  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.
  - P5fRxh5kUvp2th 4y ago
    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.
    - dalmo3 4y ago
      > 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/Using_shadow_DOM https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
      - P5fRxh5kUvp2th 4y ago
        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.
    - creatable 4y ago
      Do you mean virtual DOM?
  - deleted 4y ago
    [deleted]

ozim 4y ago

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

dbxkcichhdfufu 4y ago
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.