4 ms·

This guide assumes web components is a viable alternative for frameworks like React or Vue. That's a very superficial assumption. React and Vue render the UI as

• mbrumlow 1y ago
  State management, state manage management everybody yells when talking about web dev. It’s not some sort of mystery, it’s just a global of your variables. The example given clearly showed components backed by JavaScript. Which means you could implement a state management system in seconds. But beyond that state management is overrated. I remember when react came out and somebody from face book was describing updating some pending message count number. And how they had trouble with it. The issue was they made shitty code, and the result of react was a solution that hid that shitty code. Because I bet to this day if you profile their example they still had the bug but the state management system silently hid it as a future performance problem.
  • mmcnl 1y ago
    The solution to not using a framework is... building your own framework? What problem does that solve?
• evantbyrne 1y ago
  State should really only be kept at rest in the backend, form elements, and the occasional variable. SPA state management is fun to puzzle around with, but gives developers the false impression of productivity and is totally redundant to the browser's built-in capabilities for shuttling data back and forth to a server.
  • hdjrudni 1y ago
    C'mon. Even something simple like a date picker. Where are you going to store which month you're looking at? There's state everywhere, and we should not be sending it all back and forth to the server.
    • evantbyrne 1y ago
      Date pickers aren't simple. I would challenge you to explain why you couldn't just store it in a variable or on the element itself.
      • MrJohz 1y ago
        Could you explain what you mean by "storing it in a variable"? It's perfectly fine to store data in a variable (that's what most frameworks do in the end), but that state needs to be reactive in some way — updating that state needs to trigger the necessary UI changes (and ideally in such a way that the entire component isn't being regenerated every time the state changes). This is what makes state management so hard.
        • evantbyrne 1y ago
          Maybe I'll write a blog post on it someday. It depends on the exact method you use to build the calendar my man. You could just change classes and attributes. Or you could use a variable within the scope of where you initialize the component. I wouldn't re-render the whole thing to apply changes, but that's up to you. The nice thing about using vanilla APIs is you don't typically have to worry about thrashing the DOM with unnecessary renders because that's rarely (perhaps never?) the easiest way to patch changes to it, unlike in React where useMemo is prevalent.
          • MrJohz 1y ago
            Sure, that's what we did in the good old days, and there's good reason that most of us, when building more complex components, switched to better state management systems. The main issue is that, typically, if you're storing data directly in the DOM, you're storing redundant data. For example, if you've got an input that should have a green background if the input is one string, and a purple background if the input is another string, what state should you store here? Fundamentally, there's only one thing that's interesting: the input's value. Anything else — say, the class used to set the background colour — is derived from that value. And therefore we always want our data to flow in one direction: the input value is the source, and any other state or UI updates are based on that. But in practice, it's usually hard to maintain that strict flow of data. For example, you'll probably have multiple sources that combine in different ways to create different derived data. Or you might have multiple different ways of updating those sources that all need to perform the same updates to the derived data. Or you might have multiple levels of derived data. It's definitely possible to build applications like this — I started out this way, and still use this for simple projects where the state is fairly easy to manage. But as projects get more complex — and as the state gets more complex — it almost invariably leads to weird glitches and broken states that shouldn't exist. Hence why state management is the core of most modern frameworks — it's the most important problem to solve. N.B. `useMemo` in React has nothing to do with the DOM — React will never thrash the DOM with unnecessary changes, that's the point of the diffing process. `useMemo` is instead about reducing the number of times that React builds its own VDOM nodes.
  • mmcnl 1y ago
    Is UI state really a backend concern? I think this is a nice theory but anyone who has built a sizeable SPA (web application, not website), knows you'll be dealing with UI state complexity very soon.
• austin-cheney 1y ago
  I get so tired of framework people talking about state as the hill they are willing to die on. State is stupid simple. You use the frameworks because you cannot figure it out on your own and need the giant tool to do it for you.
• spankalee 1y ago
  Web components only solve the interoperable, encapsulated component problem. Rendering libraries like Lit handle declarative templates, and there are many state management solutions, the same ones you can use with React, etc.
  • sesm 1y ago
    Encapsulated - yes. Interoperable - can you expand on this?
    • WorldMaker 1y ago
      Interoperable: You can build a Web Component once and it should work "out of the box" in the latest Angular, React, Vue, Svelte, etc. (React was among the last holdouts on Web Component support because of Virtual DOM silliness.) Interoperable Web Components get us away from the era of needing to build npm libraries like ng-mycomponent, react-mycomponent, vue-mycomponent, for all the various combinations of drastically different component systems and ways of writing components, even when your component's core was as Vanilla as you could make it and you shared as much code as you could between implementations there were still so many small subtle things to do differently.