However, my own advice is the same as Dan Abramov's: you should focus on learning React first. Once you understand React thoroughly, then you'll better understand why a state management lib like Redux _may_ be helpful for your situation.
That's not really a fair position to take. It basically allows you to believe that React and Redux don't need to be learned together.
Put yourself in the shoes of a CTO at a new startup. They need to decide whether to build their company on top of React or Vue. They need to make this decision quickly.
Is it really fair to say they don't need to learn Redux? And that maybe Redux won't apply to their situation?
Of course Redux will apply, because Redux is for all intents and purposes how you manage state at scale. And everyone who's entering the field who isn't a junior dev is thinking "We need to come up with a way to manage state at scale. Does Vue help us do that, or are we stuck with React+Redux?"
It really doesn't help matters when you look into big players like airbnb and discover that they wrote their own state management framework rather than use Redux. They even have a two week onboarding process for new devs that teach them how to write features using their blend of tech. It's a bit... Eh... The whole thing just feels like WPF, a dead technology that few people here have probably heard of. There must be a simpler way.
> Put yourself in the shoes of a CTO at a new startup
My first step is to hire someone that knows how to build a FE app. We'll use the tool that someone is familiar with.
If you're a CTO of an incubator startup with 2 people straight out of college who learnt Python and basic JavaScript and you're trying to build a serious web app from there, well, it doesn't really matter what you pick, you'll have to rewrite it in a few months anyway (that's a pretty common scenario).
If you're the CTO of a new startup, don't pick a technology to build your startup in without building something with that technology first.
Build something small. Learn React. When you're comfortable, and your small app grows in to something a bit bigger that might merit it, learn Redux.
Then, build something small. Learn Vue. Repeat.
Now you understand both options enough to make an educated decision. Feel confident building your big, gotta-get-it-right-off-the-bat startup project in whatever works best for you.
Certainly, and that's the way to do it. My point is, you end up converging on learning Redux. You really do learn Redux no matter what, so it's kind of a myth that you "don't need to learn Redux."
Theoretically, you can get by without learning it. In practice, the moment you try to build a real company, you need it. That necessitates learning Redux.
I think this is an uncomfortable thought because it implies that Vue is way easier for devs to get into, and that's step one to displacing React+Redux. But that seems like an uncomfortable truth.
Whoever is in charge of React needs to give Vue the Snapchat treatment. Take them seriously as competitors. There's still time.
I don't understand your argument -- wouldn't it follow then that Vue devs converge on learning VueX? VueX is very similar to Redux, I don't see how that's a point in Vue's favor if our metric is time spent learning.
It's roughly a bajillion times easier to learn. And that counts for a lot.
You have to take yourself out of the "experienced React+Redux dev" mindset and put yourself in the shoes of "Experienced dev looking to invest in one of two ecosystems" mindset. Which one is the path of least resistance?
The point is, React+Redux people would love to believe that it's "Vue+VueX." But in reality, it feels like "just vue." A sword is stronger as a single piece, and Vue+VueX feels like a single piece.
It's up to people to learn both and decide for themselves, but my argument is simply this: it's a mistake to underestimate the traction Vue is gaining.
There's a strong temptation to blame the dev: They're not smart enough, they should have been able to pick up Redux easier, Vue+VueX is the same as React+Redux. But all I can do is report my experiences, and an honest survey of the ecosystem would lead us to conclude that Vue+VueX is far easier to learn without sacrificing any flexibility for your company in the long run.
I think you've made several assertions about Vue which reflect an inherent bias. VueX and Redux are _remarkably_ similar libraries and I think your assertion that VueX is easier to learn (egregious hyperbole aside) is a pretty weak argument.
To be clear: I like both React and Vue and am fundamentally skeptical of arguments that one is significantly better/worse/different than the other.
> Put yourself in the shoes of a CTO at a new startup
Okay, how big is our web application? A few pages with a form? We'll avoid Redux for now. We might even avoid React.
It's like anything else: should you set up a Spark cluster if you're only processing Gb's of data? Probably not, but you might need it some day -- so make your best guess.
That's not really a fair position to take. It basically allows you to believe that React and Redux don't need to be learned together.
Put yourself in the shoes of a CTO at a new startup. They need to decide whether to build their company on top of React or Vue. They need to make this decision quickly.
Is it really fair to say they don't need to learn Redux? And that maybe Redux won't apply to their situation?
Of course Redux will apply, because Redux is for all intents and purposes how you manage state at scale. And everyone who's entering the field who isn't a junior dev is thinking "We need to come up with a way to manage state at scale. Does Vue help us do that, or are we stuck with React+Redux?"
It really doesn't help matters when you look into big players like airbnb and discover that they wrote their own state management framework rather than use Redux. They even have a two week onboarding process for new devs that teach them how to write features using their blend of tech. It's a bit... Eh... The whole thing just feels like WPF, a dead technology that few people here have probably heard of. There must be a simpler way.