4 ms·

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

by 19078235235 9y ago

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.

shadowmint 9y ago
I'm not going to continue repeat the arguments which have been made exhaustively about the benefits vs. draw backs of these approaches by other people. There are plenty of articles which cover this topic... all I can say is please read them. If you still don't see any value in these tools, don't use them. All I'll say is this: In my experience, people tend to consider their applications to be simple enough that a simple solution is sufficient. However, in reality, that seldom seems to be the case. UI is hard to get right, and has a tendency to drift towards complexity over time as more features are added: I can think of several people who have picked the naive simple solution and regretted it later; to the point of rewrite in some cases. People who picked the complicated solution sometimes regretted the extra burden of complexity, but I don't think I've ever seen this as a cause for large scale failure or rewrite.
- 19078235235 9y ago
  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.

shadowmint 9y ago

I'm not going to continue repeat the arguments which have been made exhaustively about the benefits vs. draw backs of these approaches by other people. There are plenty of articles which cover this topic... all I can say is please read them. If you still don't see any value in these tools, don't use them. All I'll say is this: In my experience, people tend to consider their applications to be simple enough that a simple solution is sufficient. However, in reality, that seldom seems to be the case. UI is hard to get right, and has a tendency to drift towards complexity over time as more features are added: I can think of several people who have picked the naive simple solution and regretted it later; to the point of rewrite in some cases. People who picked the complicated solution sometimes regretted the extra burden of complexity, but I don't think I've ever seen this as a cause for large scale failure or rewrite.

19078235235 9y ago
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.