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!
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.
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:
Which shows that in a modern "hello world" React app there are 20k files of dependencies installed out-of-the-box, with 900+ packages pulled from NPM. Good luck doing a security audit on that.
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’m a professional react dev, currently using it with TypeScript.
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.
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.
If 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".
The problem is that (if there really is such a happy path) it’s different for every person, dependent on that person’s previous experience, and impossible to determine until you know all the other stuff. You don’t know what you don’t know, and somebody who’s advising you ALSO doesn’t know what you don’t know.
I’ve tried, over and over again, to “just do it” instead of taking things slowly and deliberately (especially because I always have a boss breathing down my neck to “get it done already”) and I always run into completely inexplicable stack traces that Google and StackOverflow can’t help me with. (Or is it just me?). However, when I finally bite the bullet and take the “hit” for the lost productivity spent reading the documentation, working through smaller, simpler examples before building up to the “real” production application, everything is clear, the stack traces make sense, and the application works like it should. The only problem is having to account to the merciless time tracking system for the week or two that I “wasted” on something as trivial as “learning”.
Its not so much about re-inventing the wheel but more about understanding how the underlying system actually works.
So yes, go ahead and use a framework if that helps but when your UI Designer gives you something that doesnt neatly fit into a framework component you need to know enough to implement it yourself right?
Also - understanding how it actually works also helps when the JS community rallies around the next big thing 6 months down the road. I still find a lot of devs who cant do basic DOM manipulation without pulling in a jquery dependency.
I’m by no means a full time UI/front end dev - I do it when I have to.
Over the years as css has improved and my understanding has improved I find myself less inclined to use a framework because doing it yourself isnt difficult and you’re not stuck fixing bugs and issues in the underlying framework and fighting against it to do whatever weird thing your design requires.
I don't know if "difficult" is the word I would use. Is a mail merge in Microsoft Word "difficult"? I think probably not. But it would still take me longer to get a mail merge working in Office than it would for me to implement and test a topological sort or a breadth-first graph traversal. That's approximately how I feel about the level of difficulty involved in DIY-ing CSS and layout. I could get really good at it, I'm sure --- but why would I? Other people got these details right already, and did a better job of it than I would (it was, at the time, the most important thing they worked on, and a perfectly laid-out button or sidebar is always going to be very far down the list of most important thing I work on).
Honestly --- and this isn't fair but I am just being candid about my impressions --- the pushback I see to relying on frameworks reads to me as a combination of specialist front-end people feeling threatened and of dilettante developers being irritated that something might be invented somewhere other than here. But if you're using React at all, hasn't that ship sailed? Oh, wait, there are like 10 bespoke vdom JS frameworks now, so I guess it hasn't.
Buttons, sidebar, grid systems, and vdom libraries are commodities to me. I think they are and should be commodities to 80-90+% of all applications that get built anywhere. Build an online pharmacy or trading position and inventory tracker or continuous integration system or CDN console and I guarantee you that nobody who pays money for it will give a shit whether your buttons came from Foundation or you lovingly handcrafted them yourself.
In my experience consulting for basically every kind of company that ever makes software, most front-end development follows the former pattern, not the latter.
I agree preemptively that you aren't going to get a job on the front-end team at Square without an intimate knowledge of how modern HTML layout works. But that's not the problem we're trying to solve with posts like these; rather, it's "where do I start". Here's where to start.
> 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.
Back in the 2004-2008 these frameworks were not well maintained and their coverage (the amount of elements/styles) they have was very small. They also were, uh, pretty ugly. I think that what made my opinion about them at the time.
But things have changed. Bootstrap now is well used, maintained and you can purchase professional styles for it.
For (on a limb here) ~80% of all applications built professionally, making it look better or even just different from the default Bootstrap look-and-feel is a waste of time and money. Users don't care.
There are applications where they do care. The pathology is, people who talk about UI development online act as if the ratio were reversed, and that not looking like stock Bootstrap should be a top-of-mind concern for people building random business applications.
Interesting perspective: I think the precise opposite is true.
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?
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.
This might be broadly true. But I think in the context of what tptatek is talking about -- that is, getting low-ceremony mileage out of React -- it's not. The reason is React's main abstractions of declarative components and one-way data flow are already well-suited to describe most of the UI problems you'll face.
(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)
But the correct usage of design patterns is the difference between inexperienced devs and experienced devs.
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.
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
or advice on what to focus on then? when ur a beginner its tough to know how much is just enough to get done. and its not easy finding a mentor either!
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.
Who cares about face. The best time to learn is when you have to. That's not to say be lazy, it's to say continuously challenge yourself so you frequently "have to".
It's not about face. It's about being able to effectively deliver stuff without needing to blow all estimates because you have to learn everything.
My family doctor constantly has to learn about new things, but he needs to have a basic foundation so he doesn't have to learn everything every time a new patient comes in the door. If he did, I'd go see someone else.
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.
> 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.
Definitely agree with that, it's a tough balance between code quality and efficiency. But at least as a beginner that is trying to learn new things, you usually don't have to worry much about things being supported later on compared to just getting something out there/working and improving as you go along.
Now is a good time to learn front-end tech. Skipping YUI was good, but you should learn at least one of Mithril, React, Preact, Inferno. I recommend Mithril for learning and React for job opportunities.
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.
I'm perfectly happy in ClojureScript to be skipping TypeScript and most of the JS ecosystem :)
Not everything on the web has to use the normal stacks. I used TypeScript in the past but didn't enjoy the complexity of most JS libs, even with typings. Clojure was a breath of fresh air, and still is.
mithril should be the default choice for everyone. no compiler, no file format, no commandline tools, comes with its own router and request functions, and is 8kb.
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?
Honestly, have you ever stumbled upon a job offer requiring any of those while looking for a job?
I'm not saying that job offers requiring e.g. coffeescript don't exist, I'm asking how much more likely you are to find a job that suits you because you know coffeescript?
I think job postings hide those requirements by not advertising them on purpose. They just kind of spring them on you in the first day and if you don't know it you will pick it up. Which is mildly ironic because they advertise all the technologies which you must have 5 years experience in or you won't be considered. I kinda don't buy it anymore.
Today? Not many coffeescript projects getting started today since ES6+ adopted much of the syntax. But there were tons of GWT and CS jobs before... actually, there still are plenty of GWT jobs.
> 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'd much rather work with a developer proficient with C, Java, JS, React, DDD and a deep knowledge of Unix than someone who has spent the majority of their time on JS, Backbone/Knockout/Angular/Ember/React/Vue/Mithril, Redux/MobX/Vuex and Grunt/Gulp/Brunch/Webpack.
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.
Strong disagree to your strong disagree. I understand right tool for the right job, but for the job of"front end framework" React vs Angular isn't hammer vs screwdriver, or even sledge vs ball peen - it's like Dewalt vs Milwaukee, claw hammers both.
For a given class of problem, your comfort with the technology will outweigh the edge cases you hit with one choice vs another. So pick your favorite hammer, screwdriver, saw, and tape-measure. If someone else hands you theirs sure, use it, but the time you spent learning the ins and out of everything is _way_ more than any time you will save.
React is a view library that doesn't even provide a way to do XHR requests. Angular is a complete framework. They are very much hammer and screwdriver, completely different and incomparable tools.
There seem to be a lot of people thinking front-end is just a mess of different options all doing the same thing. And the same people show little understanding of the complexities and nuances of front-end solutions.
OK, to be explicit: React ecosystem vs Angular. The difference between to two is how to separate the concerns - inside on large package or into an ecosystem.
I work primarily in Django. I could have given the same comparison of Django vs Flask. The pedant would say flask doesn't have an ORM, and would be correct.
Given the context of this article and HN in general I thought the shorthand referring to React generally would be understood.
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.
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.
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.
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.
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.
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.
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.
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?
The assembly people were cranks even in the 90s whereas this complaint, even when put inartfully or outright inaccurately is not completely nuts. In 20 years, people will hopefully wonder how it was that every runtime (or even framework) came with its own set (or multiple sets) of dependency management, build, test and god-knows-what-else toolchains that that do almost but not entirely the same thing as every other one.
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.
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.
Are 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?
You'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.
React (or vdom in general) has high memory costs and won't be close to native performance anytime soon (or ever). As long as you are cognizant about the trade offs it can be the right choice, but never blind. People forget the old applet days.
It's really not that complex when you understand the reason for these tools, and you don't need to know all or even most of them. You learn them as you encounter the problems they were built to solve (or once the problem becomes too burdensome to manage with a simpler solution). Until then, you don't need to learn anything.
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.
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.
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?
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.
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.
There's something to this complaint, in that I actually rarely want an SPA either --- I usually want something that behaves like a damn web page.
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.
Similar datapoint here. I was never a Rails guy, my server-side comfort zone was always on the JVM, but React makes me so much more productive than I ever was before. I'm definitely not a frontend developer; I keep up with it because as a devops consultant I sometimes have to care, but my primary interests are server-side. When I have to slam out a web frontend to something, nothing I've ever used is faster than React, and nothing I've ever used feels as good when I'm actually using the application.
SEO? Sure, that's a problem...for web sites. I mostly make applications, though, and people who want it are the people who are looking for it.
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?
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.
I'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.
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:
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).
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.
I'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.
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.
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.
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.
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.
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?
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.
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
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 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?
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.
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.
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.
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.
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
- 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).