Thank you for your response, you seem very knowledgeable on the subject.

I’m sorry if I failed to frame the argument correctly, that’s on me, but all my issues with Vue are primarily opinion based, not “objective”. I have no figures to back up my assertions.

I’ll respond to a few points, in-exhaustively.

> There isn’t a single piece of Vue that would be classified as magic. A Vue template is pretty much a dumbed down version of JSX.

I guess “Magic” is a bit of a strong term but I’ll try and explain in a bit more detail. In a Vue template, what is the scope? What object does it point to? Vue creates a kind of proxy object (at least semantically) to communicate with the javascript portion of your component. You can see this in the way that Vue handles the “this” keyword. In React, “this” is just your component class, as you would expect (principle of least astonishment). In Vue however “this” is an amalgamation of your data function, your computed properties and your methods. I’m not saying this is some huge inconvenience but it’s just unnecessary. In React, it’s just a class or a function, there’s no interference with your component.

Another example of this, what goes in a “click” event handler? In React, it is a function that is called with the same signature as the event (slightly different in practice to account for browser differences). In Vue it can be a function but it can also be a statement with the special $event keyword.

Again, I’m not saying that this would dramatically impede the development of a website in Vue. Many great websites have been made in Vue, but I would rather it were least abstruse.

> You do not have to return global variables from computed properties. You can include them in your data function.

The data function is for reactive state, not constants. Vue doesn’t really have a place for constants. I understand that you can just put it in the data function but I’d argue that the computed object makes more sense for constants (not much more sense, but it’s better than putting it in state)

> Why does everyone automatically attribute immutability with being good? Is it because it’s a large complicated word?

Ignoring your insult a bit, Immutability is good. Immutability is an excellent way to reduce bugs. No side effects, no concurrency issues (less an issue in JS), easier to reason about for testing.

> If I had to equate Redux with Vuex I would say that the Vuex mutations object is the Redux reducer.

I know that this was a hypothetical, but my problem with Vuex is that this isn’t true. A Redux reducer is a literal reducer function that takes an old state, an action and returns a whole new state. This makes Redux highly composable because it’s functional at it’s core.

Vuex requires that you mutate the state which means that a traditional reducer cannot be used. (I have done a quick google to see if an immutable Vuex store is possible and the answer seems to be no).

Bottom line, if you prefer functional style and immutability, React/Redux IMO seems like a better fit.

Productivity expert, CTO of Coaching Culture and Founder of Aika. https://www.aikahq.com

Productivity expert, CTO of Coaching Culture and Founder of Aika. https://www.aikahq.com