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.
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.
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.
