6 ms·

I was convinced for a while there as I scrolled down that this was a joke. "Good parody!" I thought to myself. Then I realized to my horror this is actually ser

I was convinced for a while there as I scrolled down that this was a joke. "Good parody!" I thought to myself. Then I realized to my horror this is actually serious. As a web developer since 1997, currently working in both the Rails & JAMstack spaces, I can assure any and all beginners out there you don't need to know anything about at least 50% of this stuff, probably closer to 70%. I also deeply resent the notion that you have to "choose a path." Depending on the task at hand and what I'm trying to accomplish, I'm working on the backend, the frontend, and/or the devops side. I jump between all of those daily. If your stack, website, or web app is so complicated that you simply have no ability to understand how it's built bottom-to-top, back-to-front, and how to deploy it easily, then either (a) you're in a massive team at a gigantic software company, or (b) you're doing it wrong!

abrahamepton 8y ago
I had a slightly different perspective, as someone who's been a web-ish developer for the last ~8-10 years: I've picked up a lot of this as I've gone, and it's fun to see it all listed out this way and think about it holistically. I think it could be intimidating for a beginner to think, "Damn, I've gotta learn all these things" and you totally, totally don't. But as you work in this space for a while, you'll encounter a lot of this, and the more you learn about the different pieces, the better code you'll write everywhere.
- ergothus 8y ago
  Agreed - what I like about these is that they give a scope - you can hear a term, check it here and say "oh, I'm way not ready for this" or "oh, it's in this scope that I already understand, I can go look it up without frying my brain".
- darepublic 8y ago
  Yea, I don't quite agree with those saying this is all baloney. It can be daunting though, but you can do a lot just on the power of html, css and vanilla js + text editor, so take heart beginners.
imhoguy 8y ago
Although I respect the author's effort but using that as a learning roadmap is a recipe for coding-monkey - the more buzzwords the better. Stop, not that way guys. The big missing part of these fancy charts are: fundamentals and soft-skills. Focus on learning social skills and you won't have to bang your head with all that tech which may not be what a client needs. If you want to learn - start small.
com2kid 8y ago
I'll argue that over 6 months or so, a new web developer will pick most of this up. e.g. webpack, I ended up getting it setup because 90% of the tutorials out there use it. Same thing for NPM scripts, use NPM, you figure out 'npm run' pretty quick. It isn't learned per se, it is just sort of acquired. Same thing for eslint, most tutorials start off with "ok now install eslint and use these rules" If you use react, you'll learn redux or mobx because that is what all the tutorials teach you to use. It'll just happen, and maybe after a month or so of use (or some independent research), the new developer will understand the code they are using. Learning a test framework, hopefully, comes naturally after the code base grows large enough that a quick manual pass through no longer suffices. I think going out and purposefully learning these technologies one by one is sort of silly, thinks make a lot more sense in situ. Go build something, after it is mostly done, figure out what gaps in knowledge exist, fill those gaps in.
- jen729w 8y ago
  As someone who started learning JS in October ‘17 and is now reasonably good at React, this resonates with me. Yeah sure, I know a bunch of stuff on that list. SemVer? Yeah, I get what the numbers mean. I google the ^x.x.x syntax, whatever. ESLint, Prettier, yep, install and drop a .config file somewhere. Copy someone else’s. It’s hardly rocket science. Webpack, I know that it exists and as soon as the defaults installed by create-react-app break, I’ll figure it out. This is a big list but let’s not pretend that you need to be an expert in any great amount of it to get something made. And the purpose is right there at the top: “The purpose of these roadmaps is to give you an idea about the landscape and to guide you if you are confused about what to learn next and not to encourage you to pick what is hip and trendy.” I think it does that pretty well. Settle down a bit, everyone.
  - BigJono 8y ago
    I don't think this does that well at all. 70% of the stuff on there is textbook "hip and trendy". If you want to know what to learn, learn web fundamentals. Learn the Web APIs and everything that's been standardized in HTML, CSS and JS. Learn relational databases. Etc. Learn how to build your graphics using SVG. Learn how to do your animations with CSS. Hell, if that's too boring learn WebGL and WebAssembly. They may not be ready, tested or in vogue, but they'll be here for the long haul. Screw libraries that abstract over this stuff. If you don't learn from the ground up you're putting your future career in the hands of things that may end up being ephemeral. Stuff like React, Sass, D3 etc might seem like safe bets, but so did jQuery at one stage. Just, be aware that your goals as a developer are sometimes at odds with the goals of your employer or even the community as a whole. There's a lot of pressure to get up to speed and be productive as quick as possible. You can see this in things like the React docs, which encourage you to ignore language features and just memorise patterns.
peckrob 8y ago
> I also deeply resent the notion that you have to "choose a path." Yup. Been doing this since 1999. The whole "front end"/"back end" thing is an incredibly unrealistic and unnecessary division. Real life work is much more complicated and nuanced than that. I don't know of anyone, maybe outside of (as you said) huge companies, who works that way, having "picked a path" and entirely focusing on one side of the stack. Even if you are a "front end" developer, you are going to need at least passing familiarity with the other side, and vice versa. Right now, I have back end code open in one split, front end JS in another, HTML in another, an ORM model for reference, and Paw with some API calls. All of these things go together, and I would have a hard time understanding any single part without being familiar with the others. After you've been doing this for a few years you realize that code is code, whether it's running on a server, or in a browser, or on a desktop or mobile device. It's just code. Once you understand how to "think" like a developer (which in my experience is the biggest hurdle people face), the differences between any of them aren't nearly as large as they seem, and almost all of those things in that graphic are just abstractions over code.
- idontgetit12 8y ago
  >After you've been doing this for a few years you realize that code is code, whether it's running on a server, or in a browser, or on a desktop or mobile device. It's just code. Except, it's not "just code". Front-end/back-end/ops, whatever, all have vastly different contexts. Hence the separate learning paths. You should know all three, but that doesn't mean you have to learn them at the same time or the same pace. You people are taking this chart way too literally.
- jrm2k6 8y ago
  This is interesting. The whole having to specialize thing has been scaring me a bit lately as I really do like the fact I can be jumping back and forth between the paths when working. I have been told that I should find something to specialize in as most of the companies require you to be specialized and there is no place for generalists anymore, which sounds weird to me. So are you a specialist in anything? It seems you have close to a 20-years career so I was either lied/misguided or you have expertise in one of those domains?
idontgetit12 8y ago
A) Why are you assuming the entirety of the roadmaps are for beginners only? Obviously you have a beginning and an end. As you approach the end you are moving out of beginner territory. B) You don't have to literally "choose a path" and only do that, these are different aspects of web development and they are roadmaps for each that lay out a path that the author found useful from start to finish. You can hop between them as you wish, but front-end work is distinct from back-end work and naturally they wouldn't be in the same progression. Are you purposely being dense? Serious question, because I found this resource to be informative. EDIT: Adding the disclaimer from the page since apparently everyone wants to interpret this as a be all end all resource due to a bad HN submission title: The purpose of these roadmaps is to give you an idea about the landscape and to guide you if you are confused about what to learn next and not to encourage you to pick what is hip and trendy. You should grow some understanding of why one tool would better suited for some cases than the other and remember hip and trendy never means best suited for the job
- ChrisSD 8y ago
  > Are you purposely being dense? Your response has merit but it would be better if you assumed good faith. Even if you don't understand their thinking.
  - idontgetit12 8y ago
    You're right, it shouldn't be necessary, but their first sentence... >I was convinced for a while there as I scrolled down that this was a joke. "Good parody!" I thought to myself. Then I realized to my horror this is actually serious. ...is pompous and holier than thou. Being unable to see the value in this infographic doesn't mean it's trash, and I think it's unnecessary to comment with such an arrogant attitude like that, especially when it's obvious they're just either not the intended audience or they're misinterpreting the goal of the graphic.
    - master-litty 8y ago
      >pompous and holier than thou That's not a good faith interpretation.
ergothus 8y ago
Webdev since '95, so we likely have moderately similar backgrounds. Let me offer a different take: > If your stack...so complicated that you simply have no ability to understand ... and how to deploy it easily You are correct. That said I don't share your reaction at all. You don't need to understand all of these things to understand how one stack is built, or how to deploy, but you DO need to start understanding these things when it comes to making decisions. I mean, look at the list. Sure, you don't need to know Bootstrap, BEM, etc to work on a website. But if you're a webdev, soon you should know what Bootstrap is, and a few of the competitors. You should understand what the pros/cons are. If your shop uses BEM, that's all you need to know...but once you're no longer new and are starting to make decisions, you need to understand WHY BEM is the way it is, that it's basically trying to NOT cascade, and thus why random CSS advice you read may or may not apply. (and then begin to decide what BEM is good/not good at, and what the alternatives are). Continue this for discussion for more than 30 seconds and you enter into territory where any realistic human has a path. I've been full stack, backend, frontend...but I always have a "current" path, because that defines what I'm keeping up with, because I can't keep up with it all. So yeah, you have to choose a path, by definition of human limitations. If you don't choose one consciously, you're still choosing one. Starting webdev? Understand the very very basics of HTTP, add HTML, and realistically add CSS. Read/Write from DOM with JS. Add some templating framework on the backend or frontend. CSS preprocessors show up quick if you're doing anything of any real size or complexity. Front end quickly hits bundlers and transpilers and minifiers...After a year in the biz the list gets pretty long. 5 years? 10 years? 20 years? The list of topics I can barely mumble about is huge, but that still leaves a big list of items. OAuth? OIDC? Web Services? CORS? SOP? cookies, localstorage? IndexedDB? The field is vast and any individual may only cut one path through each roadmap, how do you know what path is appropriate? Someone might have a path on any number of the roadmaps listed, or just one: They appear to just be a separation between domains, not a declaration that you must have only one (and they're pretty fair IMNSHO - You can definitely focus on just one roadmap fairly naturally). Where do you feel you must "choose a path"? Why do have such "deep resentment" when I don't see that being said at all? This just shows the topics at different scopes of knowledge, separated by domains that may or may not apply to you, but are natural domain boundaries anyway.
johnmarcus 8y ago
You don’t have to chose a path, but if you do chose a path these are the tools you would need to learn to call yourself competent in that discipline/area of work - because these roles definitely exist once your no longer a dev team of 3 or less.
CM30 8y ago
Yep. It will also surprise people here how few companies and organisations are 'with the times' when it comes to web development or tech stacks. Many don't use containers, package managers or Sass/Less type languages. Even more don't use the likes of React/Vue/Angular, let alone automated testing or webpack type setups. And heck, a depressing number likely don't even use version control. The picture of what's 'normal' in this field (via blogs, Reddit, Hacker News, etc) is as distorted as a picture of what a 'normal' life would be like is on social media sites. If you're at a tech savvy startup or planning to get started as a web developer in Silicon Valley, you'll probably want to know a decent amount of what's on this list. If you're outside of that situation or working contract/freelance/whatever, then you'll only need to know about 50% or so of it.
TheRealWatson 8y ago
Hello fellow class of 97 mate. I agree with you completely. It's a common trait of new professionals, especially in programming, and even more in web development, to pursue encyclopedic knowledge of all the buzzwords and brand new frameworks or tools. It's useful to learn about these things but never lose sight of the big picture. Frameworks, tools, languages, trends, all go in and out of fashion very quickly, for various reasons. On the other hand, practices, patterns, soft skills and a good understanding of how things really work will be valuable for an entire career. Put your energy into understanding which problems are being solved by the above things, not into becoming masters of any particular set of tools. You'll still be very good at those tools because you'll know the role they play and what to expect from them.
diminoten 8y ago
Need? No. Could reasonably be better at development if they did? Yes. Nobody "needs" anything, so it's not a fair standard to set. I'd say if you're a developer and you don't know about something on this list, you should probably learn about it. Master? Nah. Know what it is/means? Yeah.
z3t4 8y ago
I think if you spend like 2000 hours in a narrow field, that is enough to become an expert. Given 20 years of experience you will of course be an "expert" on many things. Btw that is some sweet looking graphs, but I think they would be even nicer if they where SVG instead of binary png's.
toomanybeersies 8y ago
I've been doing web development for around 3 years now. I probably don't know 50% of what's on this roadmap. Unless you're working as a sole developer on a project, you can get away with not knowing a whole lot of stuff. I couldn't set up webpack for a project if my life depended on it. To be fair, I spend a lot more time doing back end development. But even for the back end development pathway, I don't know anything about web sockets, GraphQL, message brokers, ElasticSearch et al, NoSQL, or caching with Memcached/Redis. It's not that I couldn't learn how to use all of the above, but rather that it's just something I don't have to use at my job. Most employers don't/shouldn't require you to know these things in order to get a job, they are skills you can learn on the job. The ability to learn is the most important skill an employee can have. The rest is just decoration.
rue 8y ago
Have you considered how, say, a recruiter might view your CV differently from someone just getting started?

abrahamepton 8y ago

I had a slightly different perspective, as someone who's been a web-ish developer for the last ~8-10 years: I've picked up a lot of this as I've gone, and it's fun to see it all listed out this way and think about it holistically. I think it could be intimidating for a beginner to think, "Damn, I've gotta learn all these things" and you totally, totally don't. But as you work in this space for a while, you'll encounter a lot of this, and the more you learn about the different pieces, the better code you'll write everywhere.

ergothus 8y ago
Agreed - what I like about these is that they give a scope - you can hear a term, check it here and say "oh, I'm way not ready for this" or "oh, it's in this scope that I already understand, I can go look it up without frying my brain".
darepublic 8y ago
Yea, I don't quite agree with those saying this is all baloney. It can be daunting though, but you can do a lot just on the power of html, css and vanilla js + text editor, so take heart beginners.

imhoguy 8y ago

Although I respect the author's effort but using that as a learning roadmap is a recipe for coding-monkey - the more buzzwords the better. Stop, not that way guys. The big missing part of these fancy charts are: fundamentals and soft-skills. Focus on learning social skills and you won't have to bang your head with all that tech which may not be what a client needs. If you want to learn - start small.

com2kid 8y ago

I'll argue that over 6 months or so, a new web developer will pick most of this up. e.g. webpack, I ended up getting it setup because 90% of the tutorials out there use it. Same thing for NPM scripts, use NPM, you figure out 'npm run' pretty quick. It isn't learned per se, it is just sort of acquired. Same thing for eslint, most tutorials start off with "ok now install eslint and use these rules" If you use react, you'll learn redux or mobx because that is what all the tutorials teach you to use. It'll just happen, and maybe after a month or so of use (or some independent research), the new developer will understand the code they are using. Learning a test framework, hopefully, comes naturally after the code base grows large enough that a quick manual pass through no longer suffices. I think going out and purposefully learning these technologies one by one is sort of silly, thinks make a lot more sense in situ. Go build something, after it is mostly done, figure out what gaps in knowledge exist, fill those gaps in.

jen729w 8y ago
As someone who started learning JS in October ‘17 and is now reasonably good at React, this resonates with me. Yeah sure, I know a bunch of stuff on that list. SemVer? Yeah, I get what the numbers mean. I google the ^x.x.x syntax, whatever. ESLint, Prettier, yep, install and drop a .config file somewhere. Copy someone else’s. It’s hardly rocket science. Webpack, I know that it exists and as soon as the defaults installed by create-react-app break, I’ll figure it out. This is a big list but let’s not pretend that you need to be an expert in any great amount of it to get something made. And the purpose is right there at the top: “The purpose of these roadmaps is to give you an idea about the landscape and to guide you if you are confused about what to learn next and not to encourage you to pick what is hip and trendy.” I think it does that pretty well. Settle down a bit, everyone.
- BigJono 8y ago
  I don't think this does that well at all. 70% of the stuff on there is textbook "hip and trendy". If you want to know what to learn, learn web fundamentals. Learn the Web APIs and everything that's been standardized in HTML, CSS and JS. Learn relational databases. Etc. Learn how to build your graphics using SVG. Learn how to do your animations with CSS. Hell, if that's too boring learn WebGL and WebAssembly. They may not be ready, tested or in vogue, but they'll be here for the long haul. Screw libraries that abstract over this stuff. If you don't learn from the ground up you're putting your future career in the hands of things that may end up being ephemeral. Stuff like React, Sass, D3 etc might seem like safe bets, but so did jQuery at one stage. Just, be aware that your goals as a developer are sometimes at odds with the goals of your employer or even the community as a whole. There's a lot of pressure to get up to speed and be productive as quick as possible. You can see this in things like the React docs, which encourage you to ignore language features and just memorise patterns.

peckrob 8y ago

> I also deeply resent the notion that you have to "choose a path." Yup. Been doing this since 1999. The whole "front end"/"back end" thing is an incredibly unrealistic and unnecessary division. Real life work is much more complicated and nuanced than that. I don't know of anyone, maybe outside of (as you said) huge companies, who works that way, having "picked a path" and entirely focusing on one side of the stack. Even if you are a "front end" developer, you are going to need at least passing familiarity with the other side, and vice versa. Right now, I have back end code open in one split, front end JS in another, HTML in another, an ORM model for reference, and Paw with some API calls. All of these things go together, and I would have a hard time understanding any single part without being familiar with the others. After you've been doing this for a few years you realize that code is code, whether it's running on a server, or in a browser, or on a desktop or mobile device. It's just code. Once you understand how to "think" like a developer (which in my experience is the biggest hurdle people face), the differences between any of them aren't nearly as large as they seem, and almost all of those things in that graphic are just abstractions over code.

idontgetit12 8y ago
>After you've been doing this for a few years you realize that code is code, whether it's running on a server, or in a browser, or on a desktop or mobile device. It's just code. Except, it's not "just code". Front-end/back-end/ops, whatever, all have vastly different contexts. Hence the separate learning paths. You should know all three, but that doesn't mean you have to learn them at the same time or the same pace. You people are taking this chart way too literally.
jrm2k6 8y ago
This is interesting. The whole having to specialize thing has been scaring me a bit lately as I really do like the fact I can be jumping back and forth between the paths when working. I have been told that I should find something to specialize in as most of the companies require you to be specialized and there is no place for generalists anymore, which sounds weird to me. So are you a specialist in anything? It seems you have close to a 20-years career so I was either lied/misguided or you have expertise in one of those domains?

idontgetit12 8y ago

A) Why are you assuming the entirety of the roadmaps are for beginners only? Obviously you have a beginning and an end. As you approach the end you are moving out of beginner territory. B) You don't have to literally "choose a path" and only do that, these are different aspects of web development and they are roadmaps for each that lay out a path that the author found useful from start to finish. You can hop between them as you wish, but front-end work is distinct from back-end work and naturally they wouldn't be in the same progression. Are you purposely being dense? Serious question, because I found this resource to be informative. EDIT: Adding the disclaimer from the page since apparently everyone wants to interpret this as a be all end all resource due to a bad HN submission title: The purpose of these roadmaps is to give you an idea about the landscape and to guide you if you are confused about what to learn next and not to encourage you to pick what is hip and trendy. You should grow some understanding of why one tool would better suited for some cases than the other and remember hip and trendy never means best suited for the job

ChrisSD 8y ago
> Are you purposely being dense? Your response has merit but it would be better if you assumed good faith. Even if you don't understand their thinking.
- idontgetit12 8y ago
  You're right, it shouldn't be necessary, but their first sentence... >I was convinced for a while there as I scrolled down that this was a joke. "Good parody!" I thought to myself. Then I realized to my horror this is actually serious. ...is pompous and holier than thou. Being unable to see the value in this infographic doesn't mean it's trash, and I think it's unnecessary to comment with such an arrogant attitude like that, especially when it's obvious they're just either not the intended audience or they're misinterpreting the goal of the graphic.
  - master-litty 8y ago
    >pompous and holier than thou That's not a good faith interpretation.

ergothus 8y ago

Webdev since '95, so we likely have moderately similar backgrounds. Let me offer a different take: > If your stack...so complicated that you simply have no ability to understand ... and how to deploy it easily You are correct. That said I don't share your reaction at all. You don't need to understand all of these things to understand how one stack is built, or how to deploy, but you DO need to start understanding these things when it comes to making decisions. I mean, look at the list. Sure, you don't need to know Bootstrap, BEM, etc to work on a website. But if you're a webdev, soon you should know what Bootstrap is, and a few of the competitors. You should understand what the pros/cons are. If your shop uses BEM, that's all you need to know...but once you're no longer new and are starting to make decisions, you need to understand WHY BEM is the way it is, that it's basically trying to NOT cascade, and thus why random CSS advice you read may or may not apply. (and then begin to decide what BEM is good/not good at, and what the alternatives are). Continue this for discussion for more than 30 seconds and you enter into territory where any realistic human has a path. I've been full stack, backend, frontend...but I always have a "current" path, because that defines what I'm keeping up with, because I can't keep up with it all. So yeah, you have to choose a path, by definition of human limitations. If you don't choose one consciously, you're still choosing one. Starting webdev? Understand the very very basics of HTTP, add HTML, and realistically add CSS. Read/Write from DOM with JS. Add some templating framework on the backend or frontend. CSS preprocessors show up quick if you're doing anything of any real size or complexity. Front end quickly hits bundlers and transpilers and minifiers...After a year in the biz the list gets pretty long. 5 years? 10 years? 20 years? The list of topics I can barely mumble about is huge, but that still leaves a big list of items. OAuth? OIDC? Web Services? CORS? SOP? cookies, localstorage? IndexedDB? The field is vast and any individual may only cut one path through each roadmap, how do you know what path is appropriate? Someone might have a path on any number of the roadmaps listed, or just one: They appear to just be a separation between domains, not a declaration that you must have only one (and they're pretty fair IMNSHO - You can definitely focus on just one roadmap fairly naturally). Where do you feel you must "choose a path"? Why do have such "deep resentment" when I don't see that being said at all? This just shows the topics at different scopes of knowledge, separated by domains that may or may not apply to you, but are natural domain boundaries anyway.

johnmarcus 8y ago

You don’t have to chose a path, but if you do chose a path these are the tools you would need to learn to call yourself competent in that discipline/area of work - because these roles definitely exist once your no longer a dev team of 3 or less.

CM30 8y ago

Yep. It will also surprise people here how few companies and organisations are 'with the times' when it comes to web development or tech stacks. Many don't use containers, package managers or Sass/Less type languages. Even more don't use the likes of React/Vue/Angular, let alone automated testing or webpack type setups. And heck, a depressing number likely don't even use version control. The picture of what's 'normal' in this field (via blogs, Reddit, Hacker News, etc) is as distorted as a picture of what a 'normal' life would be like is on social media sites. If you're at a tech savvy startup or planning to get started as a web developer in Silicon Valley, you'll probably want to know a decent amount of what's on this list. If you're outside of that situation or working contract/freelance/whatever, then you'll only need to know about 50% or so of it.

TheRealWatson 8y ago

Hello fellow class of 97 mate. I agree with you completely. It's a common trait of new professionals, especially in programming, and even more in web development, to pursue encyclopedic knowledge of all the buzzwords and brand new frameworks or tools. It's useful to learn about these things but never lose sight of the big picture. Frameworks, tools, languages, trends, all go in and out of fashion very quickly, for various reasons. On the other hand, practices, patterns, soft skills and a good understanding of how things really work will be valuable for an entire career. Put your energy into understanding which problems are being solved by the above things, not into becoming masters of any particular set of tools. You'll still be very good at those tools because you'll know the role they play and what to expect from them.

diminoten 8y ago

Need? No. Could reasonably be better at development if they did? Yes. Nobody "needs" anything, so it's not a fair standard to set. I'd say if you're a developer and you don't know about something on this list, you should probably learn about it. Master? Nah. Know what it is/means? Yeah.

z3t4 8y ago

I think if you spend like 2000 hours in a narrow field, that is enough to become an expert. Given 20 years of experience you will of course be an "expert" on many things. Btw that is some sweet looking graphs, but I think they would be even nicer if they where SVG instead of binary png's.

toomanybeersies 8y ago

I've been doing web development for around 3 years now. I probably don't know 50% of what's on this roadmap. Unless you're working as a sole developer on a project, you can get away with not knowing a whole lot of stuff. I couldn't set up webpack for a project if my life depended on it. To be fair, I spend a lot more time doing back end development. But even for the back end development pathway, I don't know anything about web sockets, GraphQL, message brokers, ElasticSearch et al, NoSQL, or caching with Memcached/Redis. It's not that I couldn't learn how to use all of the above, but rather that it's just something I don't have to use at my job. Most employers don't/shouldn't require you to know these things in order to get a job, they are skills you can learn on the job. The ability to learn is the most important skill an employee can have. The rest is just decoration.

rue 8y ago

Have you considered how, say, a recruiter might view your CV differently from someone just getting started?