I understand this is opinionated and "personal", but on the off chance that this might make React less intimidating, let me chime in and say that you can do professional work (and build pretty much any reasonable application) without:
- really understanding "semantic HTML" (if you know what div's and span's are, you're ready to get to work),
- understanding flexbox (you can, and many pro developers do, just use a CSS framework, and they're especially nice in React because they're delivered as components, so all you really need is the documentation for the layout components of the framework you pick),
- design patterns --- in fact, I might argue that you're better off not reading about design patterns, which are kind of an architectural blind alley,
- CSS preprocessors, which are neat but inessential,
- CSS architecture,
- Redux --- more nascent React developers have been derailed by the suggestion that they need to grok Redux than by anything else in the ecosystem; you don't even need to know what Redux is to build perfectly good React applications,
- async actions, which are another aspect of Flux, which again you don't need to grok,
- react-router, which is a disaster of an API that abstracts something you can build in just a hundred lines of code or so, and can in fact do without altogether,
- lodash and moment (this is nitpicking, since neither of these demand more than a couple of minutes to pick up, but just to be clear: you don't need them, especially in ES6).
I have no idea what "professional work" could possibly mean in that sentence. The things that you have deemed superfluous are the tools of the trade. We don't use every tool on every job, but when we do use them, its because they make our work easier!
Someone who doesn't know that lodash exists will reinvent lodash, and do it poorly because JS has crazy edge cases.
Someone who hasn't experienced Bootstrap's crazy, nested selector hierarchies and pseudo-selectors will end up creating their own CSS hell.
Someone who doesn't know about flexbox will end up writing who knows what instead of 'justify-content: flex-end' (or even vertical align).
react-router has been a disaster, but that doesn't mean that rewriting it yourself will be great.
Someone who doesn't know the purpose of Redux will eventually end up with spaghetti callbacks or a building a much worse clone.
Every single project I've seen that uses Redux without Immutable ends up creating a worse Immutable.
Could someone build something without any of this knowledge/experience and throw it on the Internet? Sure! Would I be happy inheriting (or even using) that "reasonable application"? No!
That's really stretching the definition of "professional work". If you're just gluing third party components and libraries together you're going to end up with a bloated mess.
This is why javascript/front-end developers get so much flak - there is a prevailing opinion that you can just fake it and not bother to learn best practices, not bother to test, and not bother to care about performance. If you do not consistently produce work of professional quality you just might not be a professional.
As someone who's pretty far down the rabbit hole on a bunch of these fronts, I think this is wonderful advice. Many of these are tools to solve very specific problems, and you should make sure you have those problems first.
The only thing I'd differ on is the semantic HTML advice. What you're saying is true modulo accessibility, but accessibility is (well, should be) table stakes for professional work. And while the community has come up with some really nice individual abstractions around tricky a11y concerns, I haven't seen a way to get good results without at least some knowledge of HTML semantics. I'm not implying you don't care about a11y -- it's totally possible I've missed some better ways of doing things.
I agree fully. I think a lot of people who claim that someone needs to know those things to be employable are just elitist. It’s no different those who claim one needs a Ph. D. in math/statistics to grok machine learning.
I’ve found that the best way to learn is top-down: identify the problem and then start learning the bits and pieces you need to solve it and go as deep as necessary (but no more).
I've still not found the time to really look at reason+react - but I strongly suspect that the "return" on learning reasonml is much better than lodash+js+react+redux.
As for loads in a post es5 (never mind es6) world - I agree. I briefly contemplated adding lodash to a legacy project (jquery, not spa) - but found that es5 without any transpiling/shim gave me enough to do some functional refactoring without adding an additional dependency.
Anyone have experience with reasonml in a real, greenfield project?
>- design patterns --- in fact, I might argue that you're better off not reading about design patterns, which are kind of an architectural blind alley,
I have to disagree with this one. People who don't know design patterns are doomed to reinvent them anyways... badly. Even worse, without a common language to describe code structure, communication with team members is harder than it needs to be. Design patterns often get a bad rap because some people get really excited when they learn them and they try to use them inappropriately. But the correct usage of design patterns is the difference between inexperienced devs and experienced devs.
If you are building a small webapp where the difficulty is in WebSocket, updating a small user interface, etc... then maybe. But some sites require different things. You can't run a large eCommerce site with hundreds of sections/styles and not use CSS preprocessors or CSS architecture.
CSS could get more sophisticated than any React work. You can fix yourself with small patches but if you have thousands of pages this can't happen. It becomes suicidal and unfixable (you'll need to rework the whole CSS to SCSS and have a CSS architecture).
I've noticed this spirit of "learn everything" all over the React and JavaScript community, and I don't think it's a good thing.
Learning happens contextually as you figure things out. I see no use to learning half of the things on here that you'll never use. You do risk, however, in the confusing and complex JavaScript landscape, getting paralyzed by choice and never getting off the ground. I shutter thinking about how large some peoples' `package.json` files are.
There will always be a better way to build and some better technology. Build based on what you know and know how to pick tools when you run into a wall. When you need to refactor, you'll have a much stronger appreciation for /why/ you need some tool anyway.
This exact ideology hindered me when I first started learning to program. If I had decided to learn Just Enough To Get Crap Done I would've fared much better and joined the industry much sooner.
Thankfully I found a good mentor who helped steer me away from all the terrible specifics and trying to learn the full stack and only learning what I needed
It's not bad to offer suggestions on what to learn if you're looking to solve some particular problems. It's a cheat sheet. But cheat sheets like the one OP linked to scare people like me away! It shows everything all at once without any context as to why you would want to use each part over its alternatives (including none).
If I made a chart like this one, I would take out CSS preprocessor section completely, replace the whole Build Tools section with "create-react-app", remove PropTypes and Flow in favor of TypeScript, move the State Management into a separate de-emphasized chart, and a bunch more.
Once a deadline hits, it's a little late to START learning (some percentage of learning will always have to happen, but its a bit rough if it's a big piece, ESPECIALLY if other people around you don't have to. If this happens all the time, it starts looking bad on your performance).
Then you add the fact that learning something similar to what you already know is much easier than going from scratch (eg: learning a state management pattern/library if you already know another is much easier than if you have no experience with them).
You're totally right that learning everything up front is a waste of time, but you do need SOME foundation, especially as more and more people enter the market and you start competing with candidates (the days of infinite entry level positions are coming to an end, if they ever existed). That map looks like it's a lot, but it really isn't, especially if you think of it as "things you should have cursory knowledge of" rather than "things you should be expert in". Eg: I've never built a production app with the CSS libraries mentioned (even Bootstrap I've only used in throwaway projects for a few hours), but I've taken a peek at the doc of most of them, so I at least know where to start if it's ever necessary.
Very true, in the end everyone has limited time and it's impossible to learn everything. However, I do personally like roadmaps/guides like this since, as a beginner, it's hard to figure out what you dont know. So being able to see a list of what's considered some of the most important/relevant topics is useful in that regard.
Still I totally agree that getting paralyzed is a big problem, it's way better to program something "the wrong/inefficient/bad way" rather than to program nothing. A big part of my learning and growth as a programmer has come from coding something terribly, realizing "hey, this kinda sucks, I bet there is a better way to do this.." and googling a bit until I learn a new/better method of doing X.
> I've noticed this spirit of "learn everything" all over the React and JavaScript community, and I don't think it's a good thing.
I strongly disagree there. The only way for an engineer to make good decisions as to what tools / framework to pick from is to know and understand as much tech as possible.
It is fundamental for an engineer to do this job of tech-watching in order to not become religious and blinded by the tool it's currently using.
React is good , but it has it's own issues. If you don't do the effort of learning other tech ( Angular , Vue ) you have absolutely no idea what those issues are, and you will just learn how to work with them ( Atomized ecosystem , Heavy Boilerpate ) and basically accept them as a normal thing.
They aren't.
Learning other tech makes you more encline to try new things and to criticize the tool you are working with and how to improve them.
I’m on your side, but the “why” is simple: a lot of people hiring will want someone to know these things. Not all or even half, but there’s a disconnect between people learning for fun vs people that want a job ASAP.
I only have time for a quick brain dump, but I hope my observations are useful to someone:
- It needs a "happy path" with the very minimum you need to learn to get started. Something like create-react-app and what you'd need to learn after that. This diagram is too scary for beginners. Bury the full diagram further down in the README.
- Each of the tools listed relieves a real pain point in large applications. You need to know what that pain point is and if you even need that relief. Understanding when you need each of those tools is important but missing info from the roadmap.
- It does represent most the types of tools you would be using for a very big app on a large team. Frontend is just as complex as backend these days, and complex in a good way not a bad way. The tools aren't there to look cool. You need them in a huge app.
- It is super helpful to understand which tools solve the same problem. But this should be explained better for beginners looking to use the road map. "Oh, I don't need to learn Jest, Mocha, Sinon, Enzyme, and Chai, they all scratch the same itch" (mostly, let's not get pedantic).
- The other comments that say none of this is necessary, just use React, are great comments. It's true of a one person team for a small app. More of this kind of thinking should go into the minimal "happy path" roadmap.
I'm torn. I don't think the aim should be "become a ${framework} developer" but just become a solid programmer with specialization in front-end technologies. If I needed to bounce out of front-end and into another tech role, I wouldn't have too hard of a time because I'm familiar with more than Javascript (I started learning programming with Ruby and Rails, but got my first professional gig doing analytics/seo).
Heck, I feel like once you are a programmer, you are a programmer.
Even after a decade of programming, it still takes me a few days to learn new concepts/libraries.
My thing is, if you already know it, copy paste and edit. If you dont know it, build the code for the first time. I feel like this is the difference between a 10 year programmer and 2 year programmer.
I have the foundation for sql databases, so it would take me mere moments to write a new full stack if I already had the code.
I am a professional developer who primarily uses React and I actively avoid most of this. I keep up with the community so know (or at least know about) almost all of this, but choose not to use it all.
The direction I have seen react go is exactly the opposite of the reason I liked it in the first place. It was simple and JUST A VIEW LAYER. How it became all of this is just typical software devs over complicating things for themselves IMO.
I'm not a react dev per se, I've used it some, not a 'master', I prefer Vue, but I wanted to chime in for newbie devs, take this roadmap with a grain of salt, you don't need to be an expert at using all the tooling and all topics mentioned in this diagram to get started and build stuff.
A topical understanding of each thing will suffice, then dive in deeper as you need it for whatever project you're working on.
If you're between projects on your job, or between clients if freelancing - by all means pick a weak subject and level up on, but don't let the complexity get you discouraged from learning in the first place.
Crazy to me how far we’ve come from HTML and some script tags. Part of me is really sad that the web is big and complicated and ugly now. I just don’t have the patience to read some new framework author’s long winded and grandiose tutorial and ode to themselves. Why is it so hard to do seemingly simple things? I can remember 10 years ago training up someone with no programming experience at all to competency in a few weeks, on the job. They had to learn HTML, some CSS, Perl, and JavaScript was left for extra credit.
Something is very, very wrong if you now need to master dozens of technologies to add the same value to the world you used to be able to 10 years ago without so much effort. And before someone says it the applications were of similar complexity and scope to today’s SPA behomths.
This chart is over complicated and I feel like it's meant to throw you off and make you feel like React programming is over complicated, which it isn't.
Don't let this scare you away from React. React is simple.
Remember, React is just the view layer. You can do whatever you want outside of React. You don't have to buy into anything else. And if you want to, you can buy into them piecemeal. You're not locked into anything, don't worry!
Here's a short cheat sheet:
- Use create-react-app. It does every single boilerplate thing perfectly for you. You don't need to worry about gulp or weback for a single second.
- Don't worry about yarn. Don't even worry about npx. Just use npm. There are binaries inside ./node-modules/.bin/ if you need them.
- You absolutely do NOT need a CSS preprocessor with React. When you make reusable components, you can just add style={...} to them and you have good old fashion encapsulation.
- Want Types? Just add TypeScript, you have nothing to lose, it's battle tested and very easy to integrate lately. It won out over Flow. Don't want types? Skip this! You don't need them! Skip PropTypes, it's falling out of use and if you're using TypeScript then it's not even a little helpful.
- Want Routing? Use React-Router 4. They ditched the old imperative API. Now <Route> is honestly just shorthand for "if location.href matches this pattern, then render this given thing in my place" and if you think of it like that then you never have trouble with it again.
- Want to react to events imperatively, maybe from Socket.io? Use Kefir. At the mouth of the stream you create a function that takes events in, and pass it to a component that gives it a handler that takes incoming events and handles them. Think of it like Unix pipes except you get to create both ends and pass them around your app. Still too complicated? Just write your own function that does exactly this for you, BAM suddenly it's demystified and you can delete it and install Kefir now.
- Want to manage your state? Just pass things as props and use setState! You really don't need to learn Redux or Mobx, they are overkill for 90% of apps. People only seem to adopt them because they think they need them, because of pages like OP's.
- Don't worry about GraphQL! fetch works great, there is a built in polyfill in create-react-app, and Express.js makes it really easy to pass JSON around.
- Worried about testing frameworks? Don't even worry about testing if you don't want to! Test driven development is great if your manager or client wants it, but it's absolutely not necessary to writing a good product. Anyone who says otherwise either belongs to or leads a cult. Software development is a job, not a religion! There is more than one way to skin a cat ;) If you still want tests, create-react-app has some stuff built in for that. I've never used it but I hear it's good.
I strongly believe React is the future. We do have some problems with bundle sizes but if the community pulls together and React gets enough love and attention, we'll keep fixing these things like we consistently have been. And don't worry about all the extras, none of them are necessary to learn and get productive!
You are my hero for having the courage to say front-end unit testing is optional. Functional testing has served me well for over a decade. Just put your app through its paces and watch what happens. I've copied your post into Vim and will save it in my ~/wisdom folder :)
Isn't testing important even if you're not doing TDD? It's really helpful to be able to modify something and know whether you borked it automatically instead of hand-testing your whole big app.
Absolutely. There are so few places where you actually need an SPA. And now with form_with doing remote forms by default and getting inline responses from the server it is a real stretch for someone to say they absolutely need some of these JS frameworks to get some simple non page load functionality.
I've been using plain css for my React stuff so far but I do miss a lot of the syntactic sugar Sass allows, like nested selectors, BEM extrapolation, colour utilities etc. What is the norm for people these days when it comes to CSS and React? is css-in-js very popular at all?
I feel like this does a disservice to a prospective React developer in that, the hard part isn't finding what all the options are for each of these areas, its finding the one to start with. I'd love to see an _opinionated_ roadmap that tells you what to learn and in what order, and then informs you of other options at your disposal.
1) I'm surprised CSS preprocessors made it as a must, and CSS in JS as only recommended. I figured that would be switched, isn't the current golden path CSS in JS?
2) Is webpack a must these days? Can we not just throw everything in typescript? Maybe that's only personal preferences!
Babel and TypeScript compete. WebPack is orthogonal.
WebPack can take your PNG image and inline it into base64-data if it's small enough, or return a hashed filename from your import to be cache friendly but without the caching bugs.
I don't know if this roadmap really is useful - most developers only work with a subset of the things listed there. This seems especially aimed at more junior developers in general, but looks like it would just overwhelm/confuse them.
I don't really understand the point of these sort of posts. They're very popular but they basically boil down to knowing basic web development (html css js), adding the productivity tools as applicable (scss, typescript) and understanding the react documentation.
The reason it's always going to be this way is that it's a library for web developers. So all you need are basics.
Also this is wrong in the sense that one usually learns a single style of css naming. Even though you need to be aware of say BEM vs the rest, highlighting it is wrong.
As far as npm et all goes, if people stopped using web IDE rubbish to learn the basics they will set it up out of necessity.
I'll probably get down-voted to oblivion for suggesting this, but is there a C#/.Net developer roadmap? I can only find quite generic front/back end developer roadmaps online.
I wonder why "General Development Skills" comes after basic HTML/CSS/JS. I guess the barrier-to-entry feels lower if you dive right in, but it feels odd that extremely basic things like "Learn to search for solutions" would proceed HTML. Wouldn't you need to be good at that in order to help you learn even basic HTML when you get stuck?
Or use a proper programming language, that gives you all that React/Redux/Webpack/Typescript/Immutable.js has, in a more consistent and bug-free package.
[+] [-] tptacek|7 years ago|reply
- really understanding "semantic HTML" (if you know what div's and span's are, you're ready to get to work),
- understanding flexbox (you can, and many pro developers do, just use a CSS framework, and they're especially nice in React because they're delivered as components, so all you really need is the documentation for the layout components of the framework you pick),
- design patterns --- in fact, I might argue that you're better off not reading about design patterns, which are kind of an architectural blind alley,
- CSS preprocessors, which are neat but inessential,
- CSS architecture,
- Redux --- more nascent React developers have been derailed by the suggestion that they need to grok Redux than by anything else in the ecosystem; you don't even need to know what Redux is to build perfectly good React applications,
- async actions, which are another aspect of Flux, which again you don't need to grok,
- react-router, which is a disaster of an API that abstracts something you can build in just a hundred lines of code or so, and can in fact do without altogether,
- lodash and moment (this is nitpicking, since neither of these demand more than a couple of minutes to pick up, but just to be clear: you don't need them, especially in ES6).
[+] [-] kansface|7 years ago|reply
Someone who doesn't know that lodash exists will reinvent lodash, and do it poorly because JS has crazy edge cases.
Someone who hasn't experienced Bootstrap's crazy, nested selector hierarchies and pseudo-selectors will end up creating their own CSS hell.
Someone who doesn't know about flexbox will end up writing who knows what instead of 'justify-content: flex-end' (or even vertical align).
react-router has been a disaster, but that doesn't mean that rewriting it yourself will be great.
Someone who doesn't know the purpose of Redux will eventually end up with spaghetti callbacks or a building a much worse clone.
Every single project I've seen that uses Redux without Immutable ends up creating a worse Immutable.
Could someone build something without any of this knowledge/experience and throw it on the Internet? Sure! Would I be happy inheriting (or even using) that "reasonable application"? No!
[+] [-] tmpz22|7 years ago|reply
This is why javascript/front-end developers get so much flak - there is a prevailing opinion that you can just fake it and not bother to learn best practices, not bother to test, and not bother to care about performance. If you do not consistently produce work of professional quality you just might not be a professional.
[+] [-] danielmason|7 years ago|reply
The only thing I'd differ on is the semantic HTML advice. What you're saying is true modulo accessibility, but accessibility is (well, should be) table stakes for professional work. And while the community has come up with some really nice individual abstractions around tricky a11y concerns, I haven't seen a way to get good results without at least some knowledge of HTML semantics. I'm not implying you don't care about a11y -- it's totally possible I've missed some better ways of doing things.
[+] [-] enraged_camel|7 years ago|reply
I’ve found that the best way to learn is top-down: identify the problem and then start learning the bits and pieces you need to solve it and go as deep as necessary (but no more).
[+] [-] crooked-v|7 years ago|reply
If you're not willing to at least think about making things accessible to screen readers, you're not being "professional".
[+] [-] e12e|7 years ago|reply
As for loads in a post es5 (never mind es6) world - I agree. I briefly contemplated adding lodash to a legacy project (jquery, not spa) - but found that es5 without any transpiling/shim gave me enough to do some functional refactoring without adding an additional dependency.
Anyone have experience with reasonml in a real, greenfield project?
[+] [-] tynpeddler|7 years ago|reply
I have to disagree with this one. People who don't know design patterns are doomed to reinvent them anyways... badly. Even worse, without a common language to describe code structure, communication with team members is harder than it needs to be. Design patterns often get a bad rap because some people get really excited when they learn them and they try to use them inappropriately. But the correct usage of design patterns is the difference between inexperienced devs and experienced devs.
[+] [-] csomar|7 years ago|reply
CSS could get more sophisticated than any React work. You can fix yourself with small patches but if you have thousands of pages this can't happen. It becomes suicidal and unfixable (you'll need to rework the whole CSS to SCSS and have a CSS architecture).
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] balls187|7 years ago|reply
[+] [-] Kaiv|7 years ago|reply
[+] [-] SirensOfTitan|7 years ago|reply
Learning happens contextually as you figure things out. I see no use to learning half of the things on here that you'll never use. You do risk, however, in the confusing and complex JavaScript landscape, getting paralyzed by choice and never getting off the ground. I shutter thinking about how large some peoples' `package.json` files are.
There will always be a better way to build and some better technology. Build based on what you know and know how to pick tools when you run into a wall. When you need to refactor, you'll have a much stronger appreciation for /why/ you need some tool anyway.
[+] [-] igneo676|7 years ago|reply
Thankfully I found a good mentor who helped steer me away from all the terrible specifics and trying to learn the full stack and only learning what I needed
[+] [-] sbjs|7 years ago|reply
If I made a chart like this one, I would take out CSS preprocessor section completely, replace the whole Build Tools section with "create-react-app", remove PropTypes and Flow in favor of TypeScript, move the State Management into a separate de-emphasized chart, and a bunch more.
[+] [-] shados|7 years ago|reply
Then you add the fact that learning something similar to what you already know is much easier than going from scratch (eg: learning a state management pattern/library if you already know another is much easier than if you have no experience with them).
You're totally right that learning everything up front is a waste of time, but you do need SOME foundation, especially as more and more people enter the market and you start competing with candidates (the days of infinite entry level positions are coming to an end, if they ever existed). That map looks like it's a lot, but it really isn't, especially if you think of it as "things you should have cursory knowledge of" rather than "things you should be expert in". Eg: I've never built a production app with the CSS libraries mentioned (even Bootstrap I've only used in throwaway projects for a few hours), but I've taken a peek at the doc of most of them, so I at least know where to start if it's ever necessary.
[+] [-] fiveoak|7 years ago|reply
Still I totally agree that getting paralyzed is a big problem, it's way better to program something "the wrong/inefficient/bad way" rather than to program nothing. A big part of my learning and growth as a programmer has come from coding something terribly, realizing "hey, this kinda sucks, I bet there is a better way to do this.." and googling a bit until I learn a new/better method of doing X.
[+] [-] pjmlp|7 years ago|reply
I saved a few brain cells by not bothering with GWT, CoffeeScript, mootools, YUI, prototype...
[+] [-] cmjqol|7 years ago|reply
I strongly disagree there. The only way for an engineer to make good decisions as to what tools / framework to pick from is to know and understand as much tech as possible.
It is fundamental for an engineer to do this job of tech-watching in order to not become religious and blinded by the tool it's currently using.
React is good , but it has it's own issues. If you don't do the effort of learning other tech ( Angular , Vue ) you have absolutely no idea what those issues are, and you will just learn how to work with them ( Atomized ecosystem , Heavy Boilerpate ) and basically accept them as a normal thing.
They aren't.
Learning other tech makes you more encline to try new things and to criticize the tool you are working with and how to improve them.
[+] [-] sotojuan|7 years ago|reply
[+] [-] tchaffee|7 years ago|reply
- It needs a "happy path" with the very minimum you need to learn to get started. Something like create-react-app and what you'd need to learn after that. This diagram is too scary for beginners. Bury the full diagram further down in the README.
- Each of the tools listed relieves a real pain point in large applications. You need to know what that pain point is and if you even need that relief. Understanding when you need each of those tools is important but missing info from the roadmap.
- It does represent most the types of tools you would be using for a very big app on a large team. Frontend is just as complex as backend these days, and complex in a good way not a bad way. The tools aren't there to look cool. You need them in a huge app.
- It is super helpful to understand which tools solve the same problem. But this should be explained better for beginners looking to use the road map. "Oh, I don't need to learn Jest, Mocha, Sinon, Enzyme, and Chai, they all scratch the same itch" (mostly, let's not get pedantic).
- The other comments that say none of this is necessary, just use React, are great comments. It's true of a one person team for a small app. More of this kind of thinking should go into the minimal "happy path" roadmap.
[+] [-] robertAngst|7 years ago|reply
6 months later, back end is done, front end is RN and is almost done.
This roadmap gave me a shot of excitement because I'm at APIs.
I finally can see the light at the end of the tunnel!
[+] [-] swoongoonz|7 years ago|reply
I feel like this is a more compelling tech tree (not mine): https://github.com/kamranahmedse/developer-roadmap
[+] [-] robertAngst|7 years ago|reply
Even after a decade of programming, it still takes me a few days to learn new concepts/libraries.
My thing is, if you already know it, copy paste and edit. If you dont know it, build the code for the first time. I feel like this is the difference between a 10 year programmer and 2 year programmer.
I have the foundation for sql databases, so it would take me mere moments to write a new full stack if I already had the code.
[+] [-] reificator|7 years ago|reply
Sure. In this case I would write that as "Software Developer with experience in Javascript, HTML, CSS, and React".
Well... You could probably replace that with "Frontend Developer with experience in React".
Except that React is a frontend framework, so you might as well simplify that as "React Developer". And now we're back where we started.
[+] [-] wesleytodd|7 years ago|reply
The direction I have seen react go is exactly the opposite of the reason I liked it in the first place. It was simple and JUST A VIEW LAYER. How it became all of this is just typical software devs over complicating things for themselves IMO.
[+] [-] gremlinsinc|7 years ago|reply
A topical understanding of each thing will suffice, then dive in deeper as you need it for whatever project you're working on.
If you're between projects on your job, or between clients if freelancing - by all means pick a weak subject and level up on, but don't let the complexity get you discouraged from learning in the first place.
[+] [-] iamleppert|7 years ago|reply
Something is very, very wrong if you now need to master dozens of technologies to add the same value to the world you used to be able to 10 years ago without so much effort. And before someone says it the applications were of similar complexity and scope to today’s SPA behomths.
Too many cooks in the kitchen!
[+] [-] sbjs|7 years ago|reply
Don't let this scare you away from React. React is simple.
Remember, React is just the view layer. You can do whatever you want outside of React. You don't have to buy into anything else. And if you want to, you can buy into them piecemeal. You're not locked into anything, don't worry!
Here's a short cheat sheet:
- Use create-react-app. It does every single boilerplate thing perfectly for you. You don't need to worry about gulp or weback for a single second.
- Don't worry about yarn. Don't even worry about npx. Just use npm. There are binaries inside ./node-modules/.bin/ if you need them.
- You absolutely do NOT need a CSS preprocessor with React. When you make reusable components, you can just add style={...} to them and you have good old fashion encapsulation.
- Want Types? Just add TypeScript, you have nothing to lose, it's battle tested and very easy to integrate lately. It won out over Flow. Don't want types? Skip this! You don't need them! Skip PropTypes, it's falling out of use and if you're using TypeScript then it's not even a little helpful.
- Want Routing? Use React-Router 4. They ditched the old imperative API. Now <Route> is honestly just shorthand for "if location.href matches this pattern, then render this given thing in my place" and if you think of it like that then you never have trouble with it again.
- Want to react to events imperatively, maybe from Socket.io? Use Kefir. At the mouth of the stream you create a function that takes events in, and pass it to a component that gives it a handler that takes incoming events and handles them. Think of it like Unix pipes except you get to create both ends and pass them around your app. Still too complicated? Just write your own function that does exactly this for you, BAM suddenly it's demystified and you can delete it and install Kefir now.
- Want to manage your state? Just pass things as props and use setState! You really don't need to learn Redux or Mobx, they are overkill for 90% of apps. People only seem to adopt them because they think they need them, because of pages like OP's.
- Don't worry about GraphQL! fetch works great, there is a built in polyfill in create-react-app, and Express.js makes it really easy to pass JSON around.
- Worried about testing frameworks? Don't even worry about testing if you don't want to! Test driven development is great if your manager or client wants it, but it's absolutely not necessary to writing a good product. Anyone who says otherwise either belongs to or leads a cult. Software development is a job, not a religion! There is more than one way to skin a cat ;) If you still want tests, create-react-app has some stuff built in for that. I've never used it but I hear it's good.
I strongly believe React is the future. We do have some problems with bundle sizes but if the community pulls together and React gets enough love and attention, we'll keep fixing these things like we consistently have been. And don't worry about all the extras, none of them are necessary to learn and get productive!
[+] [-] cutler|7 years ago|reply
[+] [-] crubier|7 years ago|reply
... But it is absolutely necessary to maintain a good product in the context of a team. Trust me on that one.
[+] [-] drngdds|7 years ago|reply
[+] [-] avip|7 years ago|reply
[+] [-] cutler|7 years ago|reply
[+] [-] tomc1985|7 years ago|reply
I am amazed that nobody seems to look at that chart and say, "holy shit, how much of this is necessary? how much of this is good?"
[+] [-] amalag|7 years ago|reply
[+] [-] danesparza|7 years ago|reply
A few suggestions: I would argue that Redux isn't required (but suggested), and instead a Flux implementation is required.
I would also argue that SASS (or LESS) preprocessor experience isn't required but also just suggested.
[+] [-] have_faith|7 years ago|reply
[+] [-] zampano|7 years ago|reply
[+] [-] jastanton|7 years ago|reply
1) I'm surprised CSS preprocessors made it as a must, and CSS in JS as only recommended. I figured that would be switched, isn't the current golden path CSS in JS?
2) Is webpack a must these days? Can we not just throw everything in typescript? Maybe that's only personal preferences!
3) No one ever needs to know jQuery anymore ;)
Glad to see lodash made it though
[+] [-] sbjs|7 years ago|reply
WebPack can take your PNG image and inline it into base64-data if it's small enough, or return a hashed filename from your import to be cache friendly but without the caching bugs.
[+] [-] wolco|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] Bahamut|7 years ago|reply
[+] [-] HaoZeke|7 years ago|reply
The reason it's always going to be this way is that it's a library for web developers. So all you need are basics.
Also this is wrong in the sense that one usually learns a single style of css naming. Even though you need to be aware of say BEM vs the rest, highlighting it is wrong.
As far as npm et all goes, if people stopped using web IDE rubbish to learn the basics they will set it up out of necessity.
[+] [-] suaveybloke|7 years ago|reply
[+] [-] Murkin|7 years ago|reply
Time to move to custom middleware(s)
[+] [-] acconrad|7 years ago|reply
[+] [-] antouank|7 years ago|reply
https://www.youtube.com/watch?v=kEitFAY7Gc8 ( yes, it's Elm )
[+] [-] pleasecalllater|7 years ago|reply