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.

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.

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.

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.

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.

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.

This is a comical misrepresentation of reality. The actual reason people switched to React was because it was what Facebook was doing and they wanted to imitate one of the wealthiest companies to ever exist, not because the masses had problems with rendering form widgets. This problem was solved twenty years ago. Perhaps the worst part about this slander is that benchmarks have actually shown time and again that vanilla JS is superior to React in terms of performance.

Of course vanilla JS is superior to any framework in terms of performance. Anything you can do in a framework, you can do directly in vanilla JS. But performance isn't the only issue here, otherwise we'd all be writing a lot more assembly code.

I find your version of history amusing, because the first project that I migrated away from vanilla JS was actually to Angular, because the team found React's JSX syntax too weird. And these weren't even the first wave of frameworks — people had been using state management systems long before then, but they had other flaws that made them difficult to work with in their own right. React became popular very quickly because it had a very simple rendering model, and because it was quick in comparison to a lot of other options at the time. Since then, the field has developed a lot, and at this point I wouldn't recommend React at all.

Listen, if you're losing track of the date in your date picker as implied previously, then I don't know what to tell you man. Not a problem I've ever seen with progressive enhancement, and I've worked on more complex user interfaces than most. I have witnessed people struggle to solve state-related issues in SPAs for even relatively simple problems though, where the solution would be trivial in vanilla js. If it's not for the performance, and it's not cutting down development time, then what is the endless framework churn really accomplishing? Because that js date picker from twenty years ago still works.

> at this point I wouldn't recommend React at all.

Out of curiosity, what would you recommend?

I mostly use SolidJS. It's super lightweight - in many ways, it's just a wrapper around `document.createElement` and a signals library - so you've got a lot of flexibility to use it how you want. It works well for complex web applications, but the library part of it is small enough that you could probably use it for individual widgets on a page and not have too much overhead. The UX is React-like (hooks and JSX), but honestly feels simpler - JSX gets compiled directly to DOM nodes rather than a VDOM abstraction, and there's no "rules of hooks" to learn.

That said, it's kind of niche, which means you need to be more willing to write stuff yourself, so a good mainstream alternative is Vue. Vue is also signals-based and relatively lightweight, but still has a lot of batteries included and a wider ecosystem that is fairly strong. They're also great at taking the parts of other frameworks that work best and implementing them in Vue, but in a fairly considered way. I understand there's also some fairly battle-tested full-stack frameworks in the Vue ecosystem, although I've not had much personal experience of that.

Both libraries are signals-based, which is a completely different reactivity concept to React, which will take a bit of getting used to. But I suspect Vue will make that transition a bit easier - despite SolidJS's more superficial similarities to React, it behaves quite differently.

You were doing ok up until this comment.

yeah idk either I didn't read it carefully enough or it was edited at roughly the same time, because I thought I was responding to something very different.

One place to store it is in a data attribute.

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.

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.

The solution to not using a framework is... building your own framework? What problem does that solve?

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.

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.

Encapsulated - yes.

Interoperable - can you expand on this?

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.