- 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).
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!
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.
Someone who knows modern JS inside and out will see lodash as yet another unnecessary dependency.
> Someone who doesn't know the purpose of Redux
Knowing the purpose of Redux has nothing to do with knowing or using Redux. Write a couple medium-size apps in React. Congratulations, you now know the problems that Redux aims to solve.
If your team doesn't have the discipline and experience to write a maintainable app without Redux, dropping Redux in isn't going to make it better and probably will make it worse.
The main problem with modern Web dev is that we think it's necessary to solve every problem by layering on ever more and more shiny crap on top, rather than focusing on a small set of inescapable tools and mastering them.
Want to be a React developer? Master HTTP, HTML, CSS, JS, and React. Then you'll know if you need lodash (nope) or a CSS framework (maybe) or Redux (probably not) and you'll be well equipped to make those decisions according to the project and team.
Of course, if this wisdom were commonly heeded, we wouldn't have this:
$ create-react-app foo && find foo/node_modules -type f | wc -l
20444
And we probably wouldn't have "awesome" lists of only the 2000 most important things you need to know to be a modern web dev, either.
This seems to be my biggest pet peeve with the JS ecosystem as a whole; people chase things that are easy to learn rather than simple to reason about once learned and the result is almost always a convoluted mess of a codebase, regardless of the project.
I used jQuery, then Underscore, and later lodash; now I'm using ClojureScript and wondering why I ever could enjoy any of those crippled FP alternatives in the past.
"Someone who doesn't know about X will create its own worse version" is true, but it also applies to you and everyone else :) We don't know what we don't know (thats meta-ignorance) and we tend to assume what we do know is the state of the art, it quite usually is very far from it!
I don’t know the last time I needed to use a lodash function was - the point is, JS abstractions have been solidifying and advancing, and now if you use TS, you really don’t need much else.
It’s not because those tools and techs aren’t useful - it’s because the higher level blocks of the language have advanced.
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.
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".
Redux, react-router, design patterns are gluing third party components together. The number of people who blindly run create-react-app without a hint of real understanding of what boilerplate it installs, or how many dependencies it pulls in, what those components do, is overwhelming.
You're right: the prevailing opinion is that you can just fake it; drop in redux, follow a nice straightforward guide on creating some actions and reducers step by step without having to make any real architectural decisions about application state or even fully understand the mechanics of dispatch lifecycle.
(Note: not a criticism of Redux, Redux is fine, rather a criticism of any ecosystem where hordes of relative beginners run automated boilerplate generators and slap together convention-over-configuration apps run on the most populist trending paradigm with no attempt to understand the—possibly very good—reasons these patterns became fashionable)
tptacek is pointing out that one can focus on learning your individual components (general definition of the word, not React.Component) properly, rather than learning the "way" to put all the recommended bits together at a high level and not understand each deeply. e.g. learn React, rather than trying to learn React+Redux+router; it will give you a much more professional understanding of the boundaries between these dependencies too.
> If you do not consistently produce work of professional quality you just might not be a professional.
I'm sorry but this sentence comes across a little conceited. If you are unable to grok the composition of your own product how can you even begin to ascertain its quality?
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’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).
If you're not willing to at least think about making things accessible to screen readers, you're not being "professional".
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?
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.
(I'm not sure if you mean "design patterns" in the general naming of abstractions sense, or if you mean Gang of Four specifically. If the latter, I'll point out that many of the GoF patterns really aren't relevant to Javascript unless you're writing it in a very OO style)
This might be true but is probably not causal. That's one of the fundamental problems with design patterns as a thing-you-ought-to-learn. They're not that useful or elucidating when you don't understand what they're for and when you understand what they are and what they are for, there's not all that much to be gained from someone cataloguing and naming them for you.
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).
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.
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
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.
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.
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'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.
I saved a few brain cells by not bothering with GWT, CoffeeScript, mootools, YUI, prototype...
It's OK to have skipped CoffeeScript, but you don't want to skip TypeScript in 2018. The past couple of years have been good as it has increasingly harmonized with ES6.
GWT was a solid platform for quite a large number of years, and is still used in quite a large number of enterprises. Also, there are a lot of good ideas in there that the JS community is only just catching up to, like dead code elimination.
A lot of modern javascript/typescript syntax is inspired by CoffeeScript. And CS is so trivially easy to learn that "saved a few brain cells" sounds like intellectual laziness.
There's a fair argument to be made for not jumping on the bleeding edge. But your examples are all mature technologies that had good solid lifespans during which people used them to build successful products. If those are fads to you, I'm guessing you must still do most of your work in C?
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.
Knowing how a technology works is important. Knowing technologies needed to accomplish tasks to be done is important. Knowing seven different technologies that accomplish the same thing is at best a marginal benefit.
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!
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?
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?
The fascination with 1 codebase doing multiple things is funny.
OP's roadmap should include some information about why each tool is useful. Without that, it's like someone telling you how to become a mechanic by giving you a list of tools to buy.
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!
... But it is absolutely necessary to maintain a good product in the context of a team. Trust me on that one.
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.
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.
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.
I feel like this is a more compelling tech tree (not mine): https://github.com/kamranahmedse/developer-roadmap
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.
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.
Selling yourself as a "React Developer" has connotations to me; subtlety in all aspects of life has repercussions.
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?"
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?
But having had several years of experience building web applications in Rails, handing data carefully between templates and controller code and managing the leaky abstractions for those places I actually had to use Javascript, I do not miss that experience at all. I'm not a front-end developer (I do it when I have to) and I am 3-5X more productive in React than I ever was at Rails front-end. If that's the return a nonspecialist gets from the React stack, I can only assume someone who specializes in it does even better.
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
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.
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.
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.
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.
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
- 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?
Time to move to custom middleware(s)
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...
That said, yes, you should always feel free to write custom middleware to solve your own use cases.
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.
- 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.
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!
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.
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.
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.
https://www.youtube.com/watch?v=kEitFAY7Gc8 ( yes, it's Elm )