19078235235

You also have to figure out how you are going to deal with debugging access to the state. Sometimes you don't even know who is modifying the state. Add in asynchronous programming, and you have all kinds of modifications going all in all kinds of orders from all over the place and you have to figure out:

the order of the modifications

who performed them

how they modified them

So the state manager adds that in as well. You can add getters and setters and enforce synchronous programming in certain methods, but then you are 90% towards a state manager.

I agree. I have written large applications with client-side rendering and they do get very complex. I am still just trying to debate the topic rather than claim to know the answer.

My choice for vue over react was:

I hate that facebook has basically made a new version of javascript.

I don't like facebook as a company and prefer software that is made by people who aren't told "go make this" by their boss.

Facebook has thrown out all of the previous approaches and just started again. This is good for things like the virtual dom, as the alternatives never worked to begin with, but bad for things like html templates, which have worked fine.

The problem with combining javascript and html (JSX) is that the javascript gets in the way and you can't really see what the component looks.

I am evaluating whether or not to use one of these state managers (vuex in my case) at the moment. I looked over the original facebook talk about flux and I am kind of getting the feeling that this is one of those solutions to a problem I don't want to ever have. It isn't about how complex your app is, but rather, how complex your organisation is.

A lot of these solutions, like static typing in non-performance areas, and so on, are about "how do we get this new engineer to start working on code that he has no idea about quickly". This problem only exists in large organisations and I personally don't think large organisations are very good at anything so don't care about those set of problems.

Basically it comes across as another "how do we hire large numbers of average programmers" problem and the facebook talk said exactly that. State managers, like dependency injection, just add another level of indirection that make your application harder to debug. You can no longer just follow a simple chain of methods, because everything disappears into the magic land of the state manager as soon as you start using (as the vuex example) store.commit("increment", 10); instead of actual methods and so on.