I've been learning React lately, and many tutorials, even those targeted at beginners, include Redux. Many seem to be a sort-of cargo cult without any understanding of why they're using Redux, and in many cases, there's no reason to introduce Redux into the mix. I've also noticed a lot of tutorials are content marketing from companies wanting to sell bolt-on services and tools, which is pretty weird; I've never used a language/ecosystem that had so many hangers-on before. And, it leads to the same situation: "Learn React (plus these other complicated things that we want to sell you)!"
I mean, it's necessary, at some point, to see a full system that uses all the tools for delivering a real application. But, it is definitely a lot of concepts to grok at once. I actually found it most useful to see tutorials that started without even using React, and built up from first principles to what React does (given that React is conceptually very simple, this isn't so crazy...a toy version of React can be built in an hour or so, so it's perfect for a video or article; much of the complexity in React is in making it fast rather than in making it work). But, that may not be a necessary first step for people who have more frontend or reactive programming experience than I have.
There is a big problem with the commercialisation of React. More and more companies are using learning resources as marketing material. And now one popular JS developer has started beginning his GitHub readmes with advertisements for a paid JS course. It's a far cry from the open, guileless sharing culture of webdev 10 years ago.
I'm somehow less bothered by the latter. Folks gotta make a living, somehow, and sometimes people have to make choices between doing OSS development or having a real job and doing a lot less of the OSS work.
But, the learning materials and marketing are the ones that bug me...especially the ones that neglect to mention that the materials cover React+product, and only mention React in the title. You might not even know it's marketing until you've read half the darned thing and the crux of the thing turns out to be "now create an account here and use this service to outsource the specific thing you googled to learn how to implement yourself". GraphQL has a lot of the same thing going on. It's like "how to draw an owl", only instead of "now draw the rest of the fucking owl", it's "now send us money every month for the rest of your app's life and we'll draw an owl for you".
I'm a Redux maintainer, and I spend most of my free time answering questions about React and Redux.
Yes, since probably early 2016, many tutorials have basically said "you need to learn React and Redux together", and that's the message that a lot of junior devs have been taught.
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.
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.
> 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.
The majority of complaints I hear (either at work or online) about React are actually about the React ecosystem -- they have trouble with Webpack or Redux and throw the baby out with the bathwater. I think very few people learn React by writing a pure app (e.g. hand-compiled, no state library).
React itself is an incredibly simple library: you can explain the entire thing in a few sentences. In my experience it has an undeserved reputation for being more complex than Vue.
The thing is, even if you want to hold yourself to a simple React-only app, the moment you want to leverage someone else's work, you are thrown into the shark-infested waters of the React ecosystem.
I think React is very cool, and I haven't tried Vue, but everything on this thread points to it being a much better learning experience, and might be better for small or middle-sized projects.
While I personally avoided this pitfall and learnt React alone before Redux, I have not meet anyone else who did the same. Literally everyone I've talked to about learning React did so (or tried, and failed to do so) with both, up front.
Wow, I wonder where people are getting the idea that they need to learn Redux. If you start a new job at a company that uses React, then you probably need to learn React + Redux simultaneously. But if you're just picking up React, Redux isn't useful whatsoever.
> Wow, I wonder where people are getting the idea that they need to learn Redux
Because everyone with a React job or substantial React project uses Redux (or a similar library). It is common for junior devs to rush through learning libraries in hopes of being employable or a "real developer" as soon as possible.
If you are working with React in a professional setting, Redux is practically the default choice for state management. If you are building something in a professional setting with React, there's a pretty good chance it's complex enough that it needs a state management library like Redux to do well.
Almost everyone I know learning React in a professional capacity ends up having to learn Redux at much the same time, my experience is very much the opposite.
I mean, it's necessary, at some point, to see a full system that uses all the tools for delivering a real application. But, it is definitely a lot of concepts to grok at once. I actually found it most useful to see tutorials that started without even using React, and built up from first principles to what React does (given that React is conceptually very simple, this isn't so crazy...a toy version of React can be built in an hour or so, so it's perfect for a video or article; much of the complexity in React is in making it fast rather than in making it work). But, that may not be a necessary first step for people who have more frontend or reactive programming experience than I have.