13 ms·
Roadmap to becoming a React developer in 2018
- danesparza 8y agoI'm always fascinated by these -- it puts hard earned skills (that I would otherwise take for granted) in perspective. Thanks! 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 8y agoI'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?
- postcss 8y agoPostCSS is probably the standard. Many plugins to get all the same stuff as sass, but faster and cleaner.
- d3sandoval 8y agoStyled-components has been a godsend, especially in apps that I'm working on with others. You really don't need nested selectors in most cases, since you're rarely thinking about the page context when dealing with a single react component. Styled components does namespacing for you and it's easy to share styles, colors, etc. across components for reusability (a la mix-ins) and portability via the props abstraction.
- qudat 8y agoI'm going to echo styled-components being a godsend. I've built a ton of front-end applications, both pre- and post-react. I've tried a ton of implementations of CSS, including just using PostCSS. After all my time investigating the best way to approach CSS, I think style-components is the best solution to use with React.
- aggronn 8y agostyled-components is what got me to switch from LESS to css-in-js, and I'm so grateful. Anyone interested learning about css-in-js for the first time would benefit from understanding the styled-components model, but there's already churn in that category, and new libraries inspired by styled-components that take it further. Here's an interesting perspective on the history of CSS-in-JS: https://github.com/streamich/freestyler/blob/master/docs/en/generations.md https://github.com/streamich/freestyler/blob/master/docs/en/... Currently i'm working with Emotion (https://github.com/emotion-js/emotion https://github.com/emotion-js/emotion) and enjoying it
- mosdl 8y ago5 generations to make something that is less efficient (slow build times, caching not always possible) that straight up css processors. Its kinda sad really (but hey my css is in my js file now, so useful).
- cutler 8y agoYes, notice the trend: web develeoper > Javascript developer > React developer. Soon we'll have CSS developer as a career in itself.
- jen729w 8y agoGiven that I, as a n00b, find JS – hell, even React – way simpler to master than CSS, that wouldn’t surprise me at all. I don’t mean the syntax, of course. The syntax is trivially simple. Translating that to something that looks good and is laid out just as you want, oh boy. CSS is by far the element of front-end development that I’m enjoying the least.
- nicoburns 8y agoI'm happily using SASS with React. If you're using webpack it's very easy to integrate (just add the SASS loader on top of the CSS loader and you can `import styles from './styles.scss'` in your JS files. Optionally, you can also integrate with the CSS modules option from the CSS loader. I think CSS in JS is moderately popular. But I would hazard a guess that there are still at least as many people using SASS.
- magicbuzz 8y agoEveryone quotes “the standard” as what they do. CSS is probably the one area where there is no consistency in how it is handled in React.
- acconrad 8y agoI 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?
- ianstormtaylor 8y agoIf you look at the career trajectory of frontend developers, I'd bet that more of them learned HTML, CSS or JS before they learned many (if not all) of the things listed under "General Development Skills". Not that those skills aren't important, but they're not entry points for learning.
- gremlinsinc 8y agoI'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.
- deleted 8y ago[deleted]
- SirensOfTitan 8y agoI'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.
- fiveoak 8y agoVery 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.
- mathgeek 8y ago> 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. I'd argue that this depends on the situation. If you're writing code that needs to meet a deadline but also needs to be supported months/years from now, there are considerations and the possibility that you'd have been better off not writing the code before learning about at least the reasonining behind the existing alternative Still, I'm with you on GTD being my personal preference in most situations.
- fiveoak 8y ago
- jastanton 8y agoCouple of nits & questions: 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
- wolco 8y agoDon't throw away jQuery just yet.
- plopz 8y agoEspecially with the way Safari is being developed, I'm guessing we're going to go back to needing a jQuery library to handle all the browser inconsistencies.
- sbjs 8y agojQuery does a whole lot more than just handle browser inconsistencies. I feel like a shim to the standard DOM API would be better suited for solving that problem. The DOM API has grown a lot.
- adzm 8y agowebpack can handle a ton of things that you can't simply do with tsc
- sbjs 8y agoBabel 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.
- suaveybloke 8y agoI'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.
- pjmlp 8y agoNot really, because there is a wide spectrum of stuff you might do. - Do you want full stack? - Native frontend (which one Forms, WPF, UWP)? - Web frontend (Forms, MVC, .NET Core MVC, Sharepoint, Sitecore) - Distributed computing (WCF, Akka.NET, Orleans, SignalR) - Database access (ADO.NET, Dapper, EF, EF Core) - Game development (Unity, MonoGame, CocosSharp, Xenko) There are many other possible groupings, so it depends a lot in what you want to focus. Have you had a look at MVA videos? https://mva.microsoft.com/#developers https://mva.microsoft.com/#developers
- mattferderer 8y agoYou might find Pluralsight's "Paths" of value - https://www.pluralsight.com/product/paths https://www.pluralsight.com/product/paths They have a few C# & .Net related paths. They offer free trials as well. Here's a 10 day affiliate link one. Not sure if there are better ones out there. https://pluralsight.pxf.io/c/1197267/424552/7490 https://pluralsight.pxf.io/c/1197267/424552/7490
- swoongoonz 8y agoI'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). I feel like this is a more compelling tech tree (not mine): https://github.com/kamranahmedse/developer-roadmap https://github.com/kamranahmedse/developer-roadmap
- reificator 8y ago> become a solid programmer with specialization in front-end technologies. 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.
- andrewmcwatters 8y agoNope, no, nah you really can't. I know React developers who do not know fundamental Web APIs. Selling yourself as a "React Developer" has connotations to me; subtlety in all aspects of life has repercussions.
- robertAngst 8y agoHeck, 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.
- RussianCow 8y ago
- drinchev 8y agoI've never learned any programming language / framework with a step-by-step component learning. I usually grab a simple task ( make a todo app, make a hello world, etc. ) and do it. Funny enough I've worked with and know almost all of the yellow circles on this diagram only because I needed them at some point.
- stephengillie 8y agoTherein lies the best [/s/career/life] advice I could possibly dispense: just DO things. Chase after the things that interest you and make you happy. Stop acting like you have a set path, because you don't. No one does. You shouldn't be trying to check off the boxes of life; they aren't real and they were created by other people, not you. There is no explicit path I'm following, and I'm not walking in anyone else's footsteps. I'm making it up as I go. - Charlie Hoehn
- sbjs 8y agoThis 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!
- ausjke 8y agowhat's used to generate a png of this kind, pretty impressive and better than freemind
- aigen001 8y agohttps://www.draw.io/ https://www.draw.io/ Source was at the bottom of link.
- cutler 8y agoI'll take Rails + turbolinks over this tangled mess any day.
- tomc1985 8y agoA thousand times yes! 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?"
- cutler 8y agoI'd love to see a contest between a bunch of devs using Rails + turbolinks pitted against a team using React + Redux + Express measuring how many working apps they could produce in a weekend. I know which team I'd be betting on. Server-side rendering has to be the biggest joke. I mean you spend half a lifetime mastering the art of pushing everything onto the client and then realise it borks your SEO because it breaks what the WWW is based on - hypertext. So you now have to go back and duplicate everything on the server. That's progress?
- deleted 8y ago[deleted]
- amalag 8y agoExactly what Sam Stephenson talked about here: https://youtu.be/SWEts0rlezA?t=6m36s https://youtu.be/SWEts0rlezA?t=6m36s
- ravenstine 8y agoIt's a complicated issue because it of course depends on how reliant a product is on SEO. Maybe certain pages that bring in views from search engines shouldn't be part of the same client-side application in the first place, but if it must be then the developers have to decide if they're building a SPA to actually hand off workload to the client or because they want to use React. :) But to the point of the person you were replying to, we definitely overcomplicate web development these days. There are some good reasons for this, like the fact that there's so much competition to contend with(so we all feel like we have to be rockstars), but it's good to remind ourselves that the end goal shouldn't be focused around the tools.
- evo_9 8y agoIt would be cool to see the same thing for VueJS just to get a sense of how much work one is versus the other.
- pleasecalllater 8y agoThere is missing just one point: prepare that in 2019 most of the things will be different, the rest will be obsolete.
- magicbuzz 8y agoActually, no. I started working in React about two years ago and if anything, I think the ecosystem in the OP map has stabilised somewhat. I think that SASS use is starting to fade and grid layout is now a thing but not like the whole gulp to grunt to webpack thing. Plus create-react-app makes starting easier. What frustrated me is that management had no idea of all the bases you needed to cover and expected me to be a backend dev and performant in Java, Spring, Elasticsearch and a whole variety of other things in Java land.
- tchaffee 8y agoReact has been around for five years now. JS ecosystem change fatigue articles and comments are what's really going out of style. ;-)
- iamleppert 8y agoCrazy 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. Too many cooks in the kitchen!
- fastball 8y agoAre you implying that the websites being built in 2008 were as sophisticated and complex as the sites in 2018? Have you considered technologies like React Native which mean you don't need to maintain 4 different entirely separate codebases for your 4 different frontends?
- mosdl 8y agoAnd instead we have a 1 bloated codebase that is slow on 3 platforms and doesn't provide native features? The fascination with 1 codebase doing multiple things is funny.
- fastball 8y agoYou're acting as if React makes it impossible to do anything else. As needs to be iterated every time we have one of these threads: you're still free to do it the "old way" -- writing your backend in X lang, your iPhone app in Swift, your Desktop apps in C++, your Android app in Java, and your web frontend in HTML/SASS/JS/jQuery. Nobody is stopping you. The truth is that people want their apps on multiple devices these days, and many apps wouldn't exist without react, at least not a port for your platform of choice. Yes, React sacrifices convenience for performance, but that has always been a trade-off. You'll notice very few people writing apps in C these days. That being said: What native features are you lacking? What apps are you using that are noticeably slower than native alternatives? My main complaint with React Native is the memory usage, but that is getting better and better and my computer has tons of RAM these days.
- tptacek 8y agoI 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).
- tmpz22 8y agoThat'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.
- tptacek 8y agoIf you've invested the time to derive a first-principles understanding of why every element in a React environment works the way it does, and what the alternatives are, and why you're going to use any given alternative, I can understand being irritated with the idea that there's a happy path that people can traverse to get to your level of productivity with 1/50th the amount of effort. What I don't really get is the reason why their work is going to be less professional and effective than yours will be; among other things, they're much less likely to pointlessly reinvent wheels. Really, the critique you're delivering applies only to a couple of the points I'm making, and, subtextually, it really applies primarily to the use of CSS/React frameworks like Bootstrap and Material and Foundation and Grommet. I think an ordinary developer can throw a dart to pick any of those frameworks and end up with better, less-janky, more usable UI than they would get by DIY'ing it first (and, inevitably, adopting a framework anyways). It's a weird quirk of web development, not shared by any of the other kinds of front end development I've been exposed to in the ~22 years I've been shipping code, that "pro" UI has to be done from scratch. WinAPI and OSX developers get UI toolkits from the platform vendor, and while you might work outside those toolkits for some custom stuff, eschewing it entirely will get you looked at funny. But use a decent UI toolkit on the web and you're "just gluing third party components together".
- cryptozeus 8y agoI like the way this is structured. I get it.
- wesleytodd 8y agoI 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.
- wetpaws 8y agoThis. You don't even have to use react if you understand one way binding flow, entire dom update logic can be written in 100-200 lines of code.
- RussianCow 8y agoThis is too dismissive of the reasons the ecosystem is the way it is. Sure, there is definitely some amount of over-engineering and NIH going on in the community, but every solution exists for a reason, and if a lot of people are using something (e.g. Redux), chances are that it solves a very real problem for those people. There are times this backfires (AngularJS, react-router), but to say that all these tools popping up "is just typical software devs over complicating things" is a bit short-sighted. If they didn't solve problems, they wouldn't be as popular as they are.
- mathgeek 8y agoI think the problem many developers see is the expectation that a "react developer" needs to know most of these things to call themselves such. It's a very similar issue to what many have with the term "full stack developer". It's a big leap between "I can get the job done if you want me to write some react code" and "I can write you an enterprise app in react", but both of those can be inferred as react development.
- zampano 8y agoI 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.
- tchaffee 8y agoI 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.
- robertAngst 8y agoIm building my first(or maybe technically second) full stack app. 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!
- Bahamut 8y agoI 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.
- hotcrossbunny 8y agoPerhaps it's less useful as a roadmap, and more as a React centered map of the frontend tech landscape. Some crossover with Thoughworks Tech Radar perhaps?
- Murkin 8y agoSurprised that redux-thunk is still alive in 2018, the cause of much of the most complicated and "ugly" code in Redux. Time to move to custom middleware(s)
- fineng123 8y agoYou can use saga if it feeds your ego, sure. Redux is a simple tool and thunk is a simple library, and they both do their job.
- acemarke 8y agoWhy do you say that thunks are "the cause of complicated and ugly code" ? I'm a Redux maintainer, and I recommend thunks as the default choice for async logic. Most people just need to make some AJAX calls and dispatch an action when it returns, or maybe grab a value from the store state and work with it. Thunks are perfect for that kind of use case - complex synchronous logic, and simple async. In fact, with `async/await` syntax, I would be a bit more comfortable doing somewhat more complicated async logic in a thunk as well. I wrote a post a while back discussing some common objections to using thunks (and sagas), and why I feel thunks and sagas are still good choices for handling logic in Redux apps: https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-th... That said, yes, you should always feel free to write custom middleware to solve your own use cases.
- abcdqwerty 8y agoworking with react makes me feel like working with PHP. mix everything on the same page/component
- hmans 8y agoWeb development has jumped the shark. I feel sorry for this industry.
- HaoZeke 8y agoI 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.
- antouank 8y agoOr 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. https://www.youtube.com/watch?v=kEitFAY7Gc8 https://www.youtube.com/watch?v=kEitFAY7Gc8 ( yes, it's Elm )