[throwaway0asd]

I just use vanilla JS on the front-end just like I do with Node.

I have never understood why people find state management challenging. I suppose its because they are stuck in a framework or MVC mindset where everything is a separate component and each must have separate state models that must be referenced frequently and independently. I just put all my state data in one object, save it on each user interaction, and use it only on page refresh. I have an entire OS GUI working like this and the state management part is only a few dozen lines of code.

Frameworks are like being locked in an insane asylum. You may not be crazy, but everybody else is and you have to follow all these extra rules you would never follow with freedom in the real world. But, the insane asylum provides you meals and bedding and many people can't be bothered to figure that stuff out without necessary hand holding.

[kristopolous]

I wish I could understand the appeal of react and other frameworks but everytime I interact with them I find them so terrible opaque and frustrating. I've built plenty of things with various frameworks including react[1], maintained, been in team-based development doing it, have github projects that use them with thousands of stars but I think they are brain-damaged terrible ways of doing things that shouldn't exist.

I've given it a fair shake and I wish I could change this opinion. I'm trying not to rant so I'll stop here.

I do a cathartic exercise every time this stuff gets to me at a themed twitter account. It's pure vitriol: https://twitter.com/sisnode

[1] oftentimes I see the anti-react argument as "react sucks which is why I use Y framework". I'm saying they are all(?) a toxic trend that leads to terrible products; more complicated, harder to maintain, aggressively encouraging a glossary of programming antipatterns passing it off as elegance.

[ebiester]

Frameworks enable ecosystems. Ecosystems enable reusable components.

The more you deviate from one of the set of common conventions, often enforced by frameworks, the more you have to build on your own.

The larger your project gets, and the more developers who need to understand your code, and the more developers you need to hire and get onboarded quickly, the more that those extra rules start to make sense.

And once you've learned and internalized the patterns necessary to build larger systems, it becomes force of habit to just use it wherever, even if it's nominally easier without them. For most developers, a go-to pattern will be faster than working from first principles on every project.

[ux-app]

I'll take Libraries over Frameworks every time.

[daveguy]

> I suppose its because they are stuck in a framework or MVC mindset where everything is a separate component and each must have separate state models that must be referenced frequently and independently. I just put all my...

Then you exactly describe MVC...

> state data in one object,

This is your model.

> save it on each user interaction,

This is your controller.

> and use it only on page refresh.

This is your view.

MVC is a relatively simple concept, and it works well.

[rukuu001]

Yes I was confused by this. It’s MVC, but without React’s benefit of having the GUI update without a page refresh.

edit - fwiw I too am another heartbroken React dev

[stevage]

I introduced Vue to a plain JS project once and reduced the amount of front end code by almost half, and vastly simplified the state management.

We must work on very different kinds of projects. I really can't imagine plain JS being a viable or appealing solution compared to Vue, which gives me very little grief at all.

[rurp]

While I don't doubt your specific experience, I'm wary about drawing firm conclusions from a single project. Vanilla JS projects can vary wildly in how verbose and complicated they are. I would bet that there are plenty of examples of both types: those that would be much more concise with a framework and those that wouldn't.

[adamerose]

> and use it only on page refresh

Doesn't that mean you can never reflect state updates in the DOM without refreshing the whole page?

> I have never understood why people find state management challenging

Automatically determining what DOM objects need to be updated in response to a change in state and updating them without a page refresh adds a lot of complexity, if you completely ignore that requirement then state management would be simple like you said.