
Roadmap to becoming a React developer in 2018 - onra87
https://github.com/adam-golab/react-developer-roadmap
======
tptacek
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).

~~~
kansface
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!

~~~
tptacek
I used to feel like underscore was an absolute requirement to do anything
serious in Javascript, but I'm not sure I've used it even once since switching
to ES6. If you want to say lodash is ultra-important, fine; like I said, it
was a nitpick, since "learning lodash" basically means "reading the
documentation for a utility library".

I don't know what you mean about Bootstrap, since Bootstrap (or something like
it) is one of the things I _do_ think new React developers should learn.

If you're using a CSS framework like Bootstrap or Foundation, I'm not
convinced that an intuition for flexbox is at all important.

I think you'd do a better job than react-router just implementing it yourself.
It's a couple of functions worth of browser glue to handle navigation events,
and then a loop; there's even a utility library (path-to-regexp) that does the
only "interesting" thing that react-router does. My point in calling out
react-router is that it is a nightmare to work with and is an actual obstacle
people have to working in React, and that obstacle is pointless; just skip it.

I strongly disagree with you about Redux, and someone else who disagrees with
you is Dan Abramov.

------
SirensOfTitan
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.

~~~
igneo676
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

~~~
tfolbrecht
Any advice on finding a mentor?

~~~
iKSv2
This might sound bullshit but I found one via "LinkedIn Career suggestion" and
he's given me some great perspectives.

Not "perfect" but sure its good

~~~
tfolbrecht
Appreciate the reply. No need for perfect :^)

------
tchaffee
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.

~~~
robertAngst
Im 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!

------
swoongoonz
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).

I feel like this is a more compelling tech tree (not mine):
[https://github.com/kamranahmedse/developer-
roadmap](https://github.com/kamranahmedse/developer-roadmap)

~~~
robertAngst
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.

~~~
RussianCow
This is true to some extent, but sometimes you really do need a specialist.
Some fields, such as databases and machine learning, are deep enough that
there _is_ a huge difference between someone learning it on the job and
someone who has been doing it for 10 years.

~~~
amorphid
I think it also might be easier to get interviews and job offers for
specialist positions where there's less demand. I'm not prepared to make a
strong case for that, but I did feel like selling myself as a Ruby on Rails
developer made certain portions of technical interviewing a lot more straight
forward than when I was interviewing for "I'm a software engineer" roles. Just
a feeling.

------
wesleytodd
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.

~~~
RussianCow
This 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
I 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.

------
gremlinsinc
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.

------
iamleppert
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.

Too many cooks in the kitchen!

~~~
tptacek
Modern programming languages are a lot more featureful and sophisticated than
assembly language, and they change a lot more than instruction set
architectures do. How is your lament different than that of an assembly
language programmer, who might complain "crazy how far we've come from
conditional jumps and some stack manipulation"?

I'm 41 and got started in the 1990s, and those assembly advocates really did
exist. What makes you think that 20 years from now people won't have a hard
time believing that anyone could have advocated "just HTML and some script
tags" over modern development practices?

~~~
tedunangst
There was a time when compiled languages compiled into a somewhat predictable
finite sequence of machine instruction, and thus one might use them but still
understand everything happening. I think that is less true of modern web
frameworks.

~~~
pvg
You probably didn't reach for disassembly dumps of some half-assed mid-90s C++
compiler to figure out why it's spewing 37 screens of error messages on some
innocent-looking STL thing. Or maybe you did! But I'm not convinced 'rate of
encounter with annoyingly incomprehensible magic' has really changed all that
much since then.

------
sbjs
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!

~~~
avip
Now convert that into a blog and post it to HN. The fight vs. bloatelitists
has just begun!

~~~
sbjs
Good idea! What's a good free easy to use blogging platform for software devs?

~~~
animesh
Jekyll + github pages OR jekyll + gitlab pages should do. I would love to read
that post.

------
cutler
I'll take Rails + turbolinks over this tangled mess any day.

~~~
tomc1985
A 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
I'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?

~~~
ravenstine
It'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.

------
danesparza
I'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
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?

~~~
d3sandoval
Styled-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.

~~~
aggronn
styled-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/...](https://github.com/streamich/freestyler/blob/master/docs/en/generations.md)

Currently i'm working with Emotion ([https://github.com/emotion-
js/emotion](https://github.com/emotion-js/emotion)) and enjoying it

~~~
mosdl
5 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
Yes, notice the trend: web develeoper > Javascript developer > React
developer. Soon we'll have CSS developer as a career in itself.

~~~
jen729w
Given 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.

------
zampano
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.

------
jastanton
Couple 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
Don't throw away jQuery just yet.

~~~
plopz
Especially 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
jQuery 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.

------
Bahamut
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.

~~~
hotcrossbunny
Perhaps 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?

------
HaoZeke
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.

------
suaveybloke
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.

~~~
mattferderer
You 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)

------
Murkin
Surprised 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)

~~~
acemarke
Why 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-
th...](https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-
thunks-sagas-abstraction-and-reusability/)

That said, yes, you should always feel free to write custom middleware to
solve your own use cases.

------
acconrad
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?

~~~
ianstormtaylor
If 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.

------
antouank
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.

[https://www.youtube.com/watch?v=kEitFAY7Gc8](https://www.youtube.com/watch?v=kEitFAY7Gc8)
( yes, it's Elm )

------
pleasecalllater
There is missing just one point: prepare that in 2019 most of the things will
be different, the rest will be obsolete.

~~~
magicbuzz
Actually, 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.

------
drinchev
I'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
_Therein 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

------
evo_9
It would be cool to see the same thing for VueJS just to get a sense of how
much work one is versus the other.

------
cryptozeus
I like the way this is structured. I get it.

------
abcdqwerty
working with react makes me feel like working with PHP. mix everything on the
same page/component

------
ausjke
what's used to generate a png of this kind, pretty impressive and better than
freemind

~~~
aigen001
[https://www.draw.io/](https://www.draw.io/) Source was at the bottom of link.

