3 ms·
Highly oppose the recommendation of create-react-app for first-comers. You're much better of learning one thing at a time. Like you said: Javascript -> React ->
by mullsork 10y ago
Highly oppose the recommendation of create-react-app for first-comers. You're much better of learning one thing at a time. Like you said: Javascript -> React -> ES6 -> State management.
create-react-app throws a ridiculous amount of crap in your face that you might end up not liking anyhow. If anything should overwhelm you then that project is it.
We have two working students at our company that were told to start their projects with CRA and they were clueless after two months. Learn one thing at a time.
- acemarke 10y agoErm... no. I'll paste a comment I wrote on Reddit yesterday ( https://www.reddit.com/r/reactjs/comments/60vurv/is_using_create_react_app_bad_practice/ https://www.reddit.com/r/reactjs/comments/60vurv/is_using_cr... ): > There's a few different thoughts here. > First, you can generally divide learners into two categories. There's a smaller group of people who feel the need to understand every abstraction and bit of tooling that they're using before they feel comfortable using all of those to build something. The larger group just wants to learn the actual tool or library at hand. > The reason create-react-app exists in the first place is because "set up Webpack and Babel" was basically being viewed as a prerequisite for even the simplest React tutorial (even though you can use React without any build tooling whatsoever). That presented a large barrier for learning. By providing a one-command project creation tool with sensible (and even opinionated) defaults, CRA lowers the barrier for learning React, and allows experimentation while still having all the "nice" aspects like JSX, class properties syntax, and even hot reloading. > So, no, it's definitely not a bad practice to use CRA!!! It's a fantastic tool to help you start learning and/or get right into building an application without hassle. > If you want to learn more about the various aspects of configuring Webpack and other build tooling, there's several resources. If you look at the actual config files included in the react-scripts dependency (which contains the actual CRA configuration and build setup), you can see the heavily-commented list of options that CRA provides. Also, my React/Redux links list has a large section of Webpack tutorials, including some that start from the simplest possible Webpack config and add more options from there. To emphasize this: what CRA gives you is just a preconfigured project that builds properly out of the box. It doesn't force a state management lib on you. It doesn't force a router. It DEFINITELY does NOT "throw a bunch of stuff" at you. Maybe you have CRA confused with some other tool?
- scrollaway 10y ago"Set up webpack and babel" shouldn't just be a step, it should be something you learn: You need to understand why you need Webpack, why you need babel, what problems they solve, the reason they're now part of your toolchain. It doesn't take long to understand that, and that's not to say C-R-A isn't useful, but I personally find it to be a gap if I have these massive tools as part of my pipeline and don't understand why and how they're separate from the rest of my libraries.
- acemarke 10y agoWhich is exactly the point I just made :) You don't _need_ those to learn React. Yes, you probably should use them for a production app, but you don't need them _just_ to learn React. (And it's still possible to use React in prod without Webpack and Babel. We're adding a couple new features to an existing ES5/Backbone app which still uses Require.js, so no Webpack or Babel there. We don't get to use JSX syntax, but the react-hyperscript-helpers lib keeps things reasonably readable.) CRA serves three primary purposes: it allows React learners to set up an environment without having to learn Webpack and Babel first; it allows experienced React devs to spin up a project without having to do all the configuration work (or copy and paste it from somewhere); and it also provides a common starting point for instructions and tutorials. For example, my recent blog post on using the Cesium.js 3D globe library with Webpack and React ( http://blog.isquaredsoftware.com/2017/03/declarative-earth-part-1-cesium-webpack/ http://blog.isquaredsoftware.com/2017/03/declarative-earth-p...) was able to start by just saying "Create a CRA project, eject, and modify these two config values". So yes, knowing what all the tools are used for and how to configure them is a good thing. But that should NOT be a barrier or prerequisite for someone who just wants to learn how to use React.
- jowiar 10y agoShould it be something you learn? Sure. Should it be the first thing you learn in the stack, or something that blocks you from shipping? Shrug. Some people feel the need to depth-first-search their stack as part of the learning process. But at some point you have to say "This is as deep in the stack as I'm going to care about today" -- otherwise you end up sitting down to make a web app and studying particle physics. I think 2 years ago, you absolutely needed to go that deep, mostly because when you sat down to work in the React ecosystem, you were almost certainly going to end up debugging something in a webpack config. I don't think that's the case today. It's a nice-to-have, and certainly will bring value eventually, but at this point I'm hoping to pull my non-C-R-A apps onto C-R-A so that managing the tooling isn't my job. Plenty of devs ship plenty of business value in Rails without understanding the full stack, and that's fine. It's worth taking a deep dive when needed, or when specific concerns make themselves known, but saying "you need to learn everything now!" is a huge barrier to entry -- getting those out of the way is a good thing.