Roadmap to becoming a web developer in 2019(github.com)
github.com
Roadmap to becoming a web developer in 2019
https://github.com/kamranahmedse/developer-roadmap
140 comments
> 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.
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.
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?
It strongly depends on the company you [want to] work for - also depends on what you actually enjoy.
At a smaller companies go for breadth; there's only a few of you. Larger companies prefer depth - but! at larger companies there can be more projects for you to have your fingers in.
Depending on specialisation, work can be rare but more rewarding - but you can also paint yourself into a corner with things moving out of vogue. Silverlight/flash, Ruby, VB, etc.
I've been at it since the 90s. I'm a generalist, mastered a few areas, and worked in. It gives me choices - I where to go for a web-based job, I'd call myself a web developer and not boast no much about my C knowledge.
At my current job, most the skills I provide aren't necessarily rare, but the combination of them is - where it could take 2+ people to replace me (excluding productivity).
The balance is to specialise enough in a few areas, but not be a "jack of all trades; master of none"
At a smaller companies go for breadth; there's only a few of you. Larger companies prefer depth - but! at larger companies there can be more projects for you to have your fingers in.
Depending on specialisation, work can be rare but more rewarding - but you can also paint yourself into a corner with things moving out of vogue. Silverlight/flash, Ruby, VB, etc.
I've been at it since the 90s. I'm a generalist, mastered a few areas, and worked in. It gives me choices - I where to go for a web-based job, I'd call myself a web developer and not boast no much about my C knowledge.
At my current job, most the skills I provide aren't necessarily rare, but the combination of them is - where it could take 2+ people to replace me (excluding productivity).
The balance is to specialise enough in a few areas, but not be a "jack of all trades; master of none"
I am an avowed generalist, and I will die on that hill. Because being a generalist programmer is the greatest! :)
Like I said above, code is code. Code is just syntactic sugar around concepts, and concepts transcend languages and environments. Understand the concepts and you can pretty easily jump around just about any programming environment, from front end to back end to desktop to mobile.
It's kinda weird to me how many people think these things are so different when really they're not. Yes, every language will have its quirks and every context will have domain specific knowledge and tooling. But they are more similar than they are different, and once you grok the similarities, the differences become easy to recognize.
I've seen so many things (languages, toolkits, environments, etc) come and go over the years that I refuse to be pigeonholed into one specialty because they always change, often without warning. Ask a Flash developer how they feel about that today - in one day (the day the iPhone was released) that whole industry collapsed. The great thing about being a generalist is that you can move on, jump in and do the work that needs to be done, no matter what that work is or where it is.
Every so often something genuinely new will come along, that requires some learning and understanding. The container ecosystem are a good fairly recent example of that. But as a generalist, it doesn't look hard or magical to you because it's just something you haven't learned yet. You're prepared for that and you have the understanding to know what you need to know. You also know your limits, and the things that do (or don't) interest you and can adjust the arc of your career appropriately.
I routinely work back and forth between front and backend every day. That is a normal day for me, I love it and and I would not change it. Occasionally I'll lend a hand on an iOS app (that we're about to migrate to React Native as it happens) and maintain some internal Mac apps as well as writing my own Mac apps for fun. I've also run a side consulting business for several years to keep my skills fresh where I tackle everything from DevOps/server maintenance/cloud migrations to frontend/backend to desktop and mobile development. Basically whatever itch I'm feeling at the time.
Concepts translate pretty easily and, where they are different, as a generalist you accumulate enough experience to know what those differences are. And if companies want to divide their jobs into "front end" and "back end," that's fine, because you have the knowledge to apply for either. :)
A lot of people in this thread are really selling themselves short. They know more than they realize and the "other side" of the stack is not some mysterious magic that requires years of intense specialization. It's just programming. Same thing we've all been doing for years.
"Specialization is for insects." - Heinlein
Like I said above, code is code. Code is just syntactic sugar around concepts, and concepts transcend languages and environments. Understand the concepts and you can pretty easily jump around just about any programming environment, from front end to back end to desktop to mobile.
It's kinda weird to me how many people think these things are so different when really they're not. Yes, every language will have its quirks and every context will have domain specific knowledge and tooling. But they are more similar than they are different, and once you grok the similarities, the differences become easy to recognize.
I've seen so many things (languages, toolkits, environments, etc) come and go over the years that I refuse to be pigeonholed into one specialty because they always change, often without warning. Ask a Flash developer how they feel about that today - in one day (the day the iPhone was released) that whole industry collapsed. The great thing about being a generalist is that you can move on, jump in and do the work that needs to be done, no matter what that work is or where it is.
Every so often something genuinely new will come along, that requires some learning and understanding. The container ecosystem are a good fairly recent example of that. But as a generalist, it doesn't look hard or magical to you because it's just something you haven't learned yet. You're prepared for that and you have the understanding to know what you need to know. You also know your limits, and the things that do (or don't) interest you and can adjust the arc of your career appropriately.
I routinely work back and forth between front and backend every day. That is a normal day for me, I love it and and I would not change it. Occasionally I'll lend a hand on an iOS app (that we're about to migrate to React Native as it happens) and maintain some internal Mac apps as well as writing my own Mac apps for fun. I've also run a side consulting business for several years to keep my skills fresh where I tackle everything from DevOps/server maintenance/cloud migrations to frontend/backend to desktop and mobile development. Basically whatever itch I'm feeling at the time.
Concepts translate pretty easily and, where they are different, as a generalist you accumulate enough experience to know what those differences are. And if companies want to divide their jobs into "front end" and "back end," that's fine, because you have the knowledge to apply for either. :)
A lot of people in this thread are really selling themselves short. They know more than they realize and the "other side" of the stack is not some mysterious magic that requires years of intense specialization. It's just programming. Same thing we've all been doing for years.
"Specialization is for insects." - Heinlein
I wish HN would notify me of answers for my comment. Yes, I totally share that mindset with you.
I actually use pretty much the same thing when helping people starting their programming journey.
'There is so many things to learn I started with Python but there is this and this and that'
A language is just a language, the principles and your ability to translate problems to code is what is making you a programmer.
'There is so many things to learn I started with Python but there is this and this and that'
A language is just a language, the principles and your ability to translate problems to code is what is making you a programmer.
You can get notifications using http://www.hnreplies.com/
But will you see this comment given that you don't get notifications?
But will you see this comment given that you don't get notifications?
I did! And signed up for hnreplies. Thanks!
In addition, as someone used to working on small teams, specialization seems inefficient.
If you only have 3 developers, it doesn't make much sense to have one backend, one frontend, and one dev-ops. Are you always going to have exactly equal amounts of work for all three to do each day?
But apart from that, it also seems so much easier to divide up work by feature without stepping on anyone's toes. Like, you code search, I'll code chat. Not you code search backend, I'll code search frontend. That increases overhead and coordination.
And then, if your frontend is heavy on JavaScript, there's often a lot of similar code between frontend and backend. Validation is a classic example. A more extreme example might be a browser game using WebSockets and lockstep simulation. The browser and server might share most of their code. It would be absurd to split all the developers into frontend and backend in this case.
If you only have 3 developers, it doesn't make much sense to have one backend, one frontend, and one dev-ops. Are you always going to have exactly equal amounts of work for all three to do each day?
But apart from that, it also seems so much easier to divide up work by feature without stepping on anyone's toes. Like, you code search, I'll code chat. Not you code search backend, I'll code search frontend. That increases overhead and coordination.
And then, if your frontend is heavy on JavaScript, there's often a lot of similar code between frontend and backend. Validation is a classic example. A more extreme example might be a browser game using WebSockets and lockstep simulation. The browser and server might share most of their code. It would be absurd to split all the developers into frontend and backend in this case.
Maybe it's time to put our old "webmaster" hats back on.
Generalist or polyglot developer still doesn't fully capture the broad scope of knowledge you can call on beyond cutting code and may have lost any of its negative connotations over the last 23 years.
Generalist or polyglot developer still doesn't fully capture the broad scope of knowledge you can call on beyond cutting code and may have lost any of its negative connotations over the last 23 years.
Yeah, one of my favorite things is to pull something from a domain that has parallels in another. What appears like magic is just having a broader exposure to various concepts and domains.
>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.
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.
Bullshit. No way you are telling me backend folks want to spend their day writing front end css code and compiling modejs. Certainly, if and when you are ‘full stack’ you can and may do both.....but that implies both exist to begin with.
> No way you are telling me backend folks want to spend their day writing front end css code and compiling modejs.
I said nothing about want to. Want to and capable of are two different things. If somebody wants to just be a back end dev (or front end, or iOS, or...), by all means, go right ahead. I won't stop them. I don't want to do Android development, but I could if I needed to (after some spin-up time).
But I disagree with the idea that they are so wildly divergent that no mere mortal can grasp them. People in this thread are really selling themselves short with their knowledge, which is more transferable than they realize.
> Certainly, if and when you are ‘full stack’ you can and may do both.....but that implies both exist to begin with.
Not too long ago, both didn't exist and everyone was a web developer. And before that we were just programmers. It's a fairly recent idea.
I said nothing about want to. Want to and capable of are two different things. If somebody wants to just be a back end dev (or front end, or iOS, or...), by all means, go right ahead. I won't stop them. I don't want to do Android development, but I could if I needed to (after some spin-up time).
But I disagree with the idea that they are so wildly divergent that no mere mortal can grasp them. People in this thread are really selling themselves short with their knowledge, which is more transferable than they realize.
> Certainly, if and when you are ‘full stack’ you can and may do both.....but that implies both exist to begin with.
Not too long ago, both didn't exist and everyone was a web developer. And before that we were just programmers. It's a fairly recent idea.
>
The whole "front end"/"back end" thing is an incredibly unrealistic and unnecessary division
Ever since server side javascript turned serious with node.js and "full stack developer" became a thing I have been stupefied by this. The concerns are almost orthogonal: front end gets some data which needs to be presented in a browser. Chief concerns are proper placement and appearance. Back end needs to persist data and retrieve data at speed. They absolutely have nothing to do with each other. How is this an "unnecessary division"?
Ever since server side javascript turned serious with node.js and "full stack developer" became a thing I have been stupefied by this. The concerns are almost orthogonal: front end gets some data which needs to be presented in a browser. Chief concerns are proper placement and appearance. Back end needs to persist data and retrieve data at speed. They absolutely have nothing to do with each other. How is this an "unnecessary division"?
Given the trajectory of front-end frameworks like React, I'm pretty sure front-end and back-end are going to be two very separate tracks about 5 years from now. Front end is just getting too complicated to be a complete expert in while also being an expert in writing microservices too.
Yes, the axiom fits pretty nicely here: "Jack of all trades, master of none." It's extremely rare to find someone who is a master of all, can keep on top of current tech (in all domains), etc. Web development is becoming like the medical profession, where every single subfield is specialized. Yes, there are people who can do that, but they are far and few between. Most back end devs are typically not visually creative types like are typically needed for the front end, and vice versa. How many good back end devs are also good graphic artists and at layout (beyond adding a background image to bootstrap)? How many front end devs are good with SQL?
If you want an example, search a job listing aggregator for the job titles. I just ran the numbers for my area, and 41% of total software development related job posts are exclusively looking for backend, frontend or mobile engineers.
> The whole "front end"/"back end" thing is an incredibly unrealistic and unnecessary division.
Well, one is client development and the other is server application development.
Pretty big differences there even though there may be some overlap, like the server being able to render HTML which is a unique feature of web clients. I'd cluster "web client development" with iOS and Android development, not with server application development.
Too many people dump on front-end development without realizing that client development isn't easy on any platform, and they all require credentialization in apis or design patterns with major warts.
Well, one is client development and the other is server application development.
Pretty big differences there even though there may be some overlap, like the server being able to render HTML which is a unique feature of web clients. I'd cluster "web client development" with iOS and Android development, not with server application development.
Too many people dump on front-end development without realizing that client development isn't easy on any platform, and they all require credentialization in apis or design patterns with major warts.
The division of labor depends on how tickets are split up and that’s an organizational specific thing.
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.
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.
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.
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.
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.
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.
This is real nice as a philosophy, and I fundamentally agree.
But I want to get stuff made. I have ideas, I have a thing I want to make. Would I like to really deeply properly fundamentally understand JavaScript? Sure! Do I have time, with my actual real job and friends and life and other hobbies? Nope. Thank goodness, then, for React. It's a godsend.
(Also, I have no desire to "work" as a developer for someone else as my salaried job. Perhaps that affects my outlook.)
But I want to get stuff made. I have ideas, I have a thing I want to make. Would I like to really deeply properly fundamentally understand JavaScript? Sure! Do I have time, with my actual real job and friends and life and other hobbies? Nope. Thank goodness, then, for React. It's a godsend.
(Also, I have no desire to "work" as a developer for someone else as my salaried job. Perhaps that affects my outlook.)
Keep in mind I'm not recommending that you don't use React. I'm using it for a hobby project right now. I just mean that you should understand all the concepts behind it so that if you need to move to another tool for a particular job or if it's superceded by something in the future, you can make the jump across much easier.
My usual measuring stick is "if this thing disappeared tomorrow, would I be able to recreate it from scratch myself with no documentation?" (obviously not up to the same performance standards).
My usual measuring stick is "if this thing disappeared tomorrow, would I be able to recreate it from scratch myself with no documentation?" (obviously not up to the same performance standards).
jQuery is still worth knowing and is a handy library for managing cross-browser compatibility outside of a SPA framework. Same as using something like normalize.css to baseline your CSS.
It's still a long way off disappearing and in many high security environments might be the only approved library.
https://trends.builtwith.com/javascript/jQuery
It's still a long way off disappearing and in many high security environments might be the only approved library.
https://trends.builtwith.com/javascript/jQuery
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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Btw that is some sweet looking graphs, but I think they would be even nicer if they where SVG instead of binary png's.
Have you considered how, say, a recruiter might view your CV differently from someone just getting started?
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.
> 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.
idontgetit12(1)
I'm currently teaching my brother web development and I guarantee if I were to show him this, he'd just quit. This is way too much information.
All a beginner needs to know is JS and the basics of HTML/CSS/SQL. If they have a mentor, the mentor should draw out and explain how frontend, backend and databases relate, and the general lifecycle of a request to a webpage.
That's all you really need to start building stuff. The next thing will probably be a basic understanding of DNS and how requests get routed.
Anything much more than that is overkill.
All a beginner needs to know is JS and the basics of HTML/CSS/SQL. If they have a mentor, the mentor should draw out and explain how frontend, backend and databases relate, and the general lifecycle of a request to a webpage.
That's all you really need to start building stuff. The next thing will probably be a basic understanding of DNS and how requests get routed.
Anything much more than that is overkill.
I don't think the author is suggesting that you need to 100% complete this entire prescriptive road map to start working as a web developer. This is more an illustration of the journey that a developer might take from zero knowledge to roughly mid-level. If you look at the key, you'll see that a lot of boxes are actually just his 'suggested options', not mandatory requirements.
> All a beginner needs to know is JS and the basics of HTML/CSS/SQL.
If they're going to dabble on their own stuff for fun sure, that's all you need. If you're trying to get a job that won't cut it.
If they're going to dabble on their own stuff for fun sure, that's all you need. If you're trying to get a job that won't cut it.
This is the crux of it. In my experience, the roadmap in the OP accurately reflects the topology and expectations of today's hiring landscape.
It's a good reference resource to have. It's great to see what X technology is, and how it relates to everything else.
I would agree that handing this to a beginner would be over kill.
This is probably best suited for people who are in the 'I know the basics, but want to know what this technology-of-the-month is and how it fits in to what I already know' stage.
I would agree that handing this to a beginner would be over kill.
This is probably best suited for people who are in the 'I know the basics, but want to know what this technology-of-the-month is and how it fits in to what I already know' stage.
I would posit that it's a valuable skill at this point in time to intentionally not seek out the flavor-of-the-month web technology. I'm of the opinion it's good to wait a year or two before adopting any new framework or technique, because it seems almost all of them are passé within that timeframe. (Case in point: BOY am I glad I never bothered to learn Angular 1!)
Ya, I've got a CS degree and I'm slowly learning web dev. Learning JS is really nice, but I feel like I need to know so many frameworks and other things, not to mention algorithms, to land an actually decent job. Idk how accurate this is but most requirements on job sites seem fairly thorough.
Maybe your brother needs to learn how to take things one step at a time if this would make him quit at first glance. I don't understand why it's a bad thing to have a consolidated source of information like this, I would have loved to have a detailed roadmap as a beginner. These graphics lays things out very clearly and obviously you don't need to rush through the steps.
You're right, it is valuable to have a resource like this. I guess I was taking issue with the title of the submission. I think something like this is great to introduce to someone who already has begun to get their bearings straight. But if a beginner followed this and spent time learning about "required" skills upfront, like Licenses, or Encodings, or Algorithms, it's just going to blow them off track.
Once they are reasonably experienced and have started to get the lay of the land, something like this can serve as a good mind map.
Once they are reasonably experienced and have started to get the lay of the land, something like this can serve as a good mind map.
Agreed, the "required" skills isn't in a great spot and isn't properly labeled. And beyond "learn a language" (looking at the back-end part), it's really not for beginners. That being said, if you have some familiarity with programming but not the state of tooling/environment/etc in modern web dev this should be invaluable.
Mentioning SQL means backend which implies they need to understand that a network connection is incoming to a server bound on a port with a method, URL, list of cookies/headers, etc. with the purpose of serving a request with a response
CORS potentially might be worth mentioning to get a beginner familiar with security (why can't I just scrape Facebook cookies from my personal website), yada yada.
I think that's kind of still high level to hold limited attention spans without overwhelming but deep enough to prove that there's a bit more going on beneath the scenes.
I feel most new web developers in those jumpstart "become a programmer in 60 days" classes probably know a bit too much about React and probably not enough about the sockets/IPs/networking serving the static assets. Probably not a requirement on day one, but I bet it might make their first "I have to debug this all the way through the stack" problem less painful.
All hypothetical, at least.
CORS potentially might be worth mentioning to get a beginner familiar with security (why can't I just scrape Facebook cookies from my personal website), yada yada.
I think that's kind of still high level to hold limited attention spans without overwhelming but deep enough to prove that there's a bit more going on beneath the scenes.
I feel most new web developers in those jumpstart "become a programmer in 60 days" classes probably know a bit too much about React and probably not enough about the sockets/IPs/networking serving the static assets. Probably not a requirement on day one, but I bet it might make their first "I have to debug this all the way through the stack" problem less painful.
All hypothetical, at least.
I completely agree. The basics of networking, sockets, and the like are probably better taught before frameworks even come into the picture.
To me, the idea is to get a shallow understanding of everything involved from hitting a page, submitting some data, and having it be displayed back to you. Once you have that picture in your mind, adding things like frameworks, git, docker, etc, will be easier for the person to grasp.
To me, the idea is to get a shallow understanding of everything involved from hitting a page, submitting some data, and having it be displayed back to you. Once you have that picture in your mind, adding things like frameworks, git, docker, etc, will be easier for the person to grasp.
While I agree that knowledge of what's below those abstractions is important, you also need to cater to your audience. Getting something working on the screen in front of you is exciting for new folks; lining up little victories with increasing complexity feels like a path that would be more enjoyable to follow. As long as the person maintains a curiosity about the underlying technology, they can work down into the lower layers as their interest dictates.
I think they might be overstimulated.
Hello, world from a compiler in a terminal is a good start.
You should show them how many lines of code a web browser is and say "here is what it takes to get <p>Hello!</p> on the page" lol
Scare everybody away :)
Hello, world from a compiler in a terminal is a good start.
You should show them how many lines of code a web browser is and say "here is what it takes to get <p>Hello!</p> on the page" lol
Scare everybody away :)
> Mentioning SQL means backend which implies they need to understand that a network connection is incoming to a server bound on a port with a method, URL, list of cookies/headers, etc. with the purpose of serving a request with a response
HTML pages will be served over HTTP too, so that's already necessary to understand how web works.
HTML pages will be served over HTTP too, so that's already necessary to understand how web works.
I think there hardly is any field out there where once the roadmap is mapped, the roadmap doesn't look long and convoluted. Overcoming being overwhelmed is something your relative should get a grip of from the get go, or atleast be aware of the expectation that one will likely be overwhelmed at every step. That and mapping out of minimal reqs to get started. Of course I understand the person is a beginner but the advice applies to every field
I would also add a few unix commands. Just enough to get a server running to deploy a website.
Since the early 2000s, I'd been working with HTML/CSS, with a touch of JS and making visually rich, pixel perfect websites. Then a few years later, I taught myself Python and came to understand how programming works and my skills transferred over to JS as well.
It wasn't until many years after that I finally learned some unix command lines that I was able to bring together my skills to make any use out of them.
Since the early 2000s, I'd been working with HTML/CSS, with a touch of JS and making visually rich, pixel perfect websites. Then a few years later, I taught myself Python and came to understand how programming works and my skills transferred over to JS as well.
It wasn't until many years after that I finally learned some unix command lines that I was able to bring together my skills to make any use out of them.
Agreed. I should say installing Ubuntu way back in 2007 really helped me discover a whole world of CLIs that I never knew to exist in my Windows / Notepad++ comfort zone back then
These roadmaps are always hilarious to me. The real roadmap to becoming a web developer is "write code and convince someone to pay you." I suppose you could even leave the paying part off, if you are contributing to open source or writing code for yourself.
Of course, you should do a great job, dedicate regular time to learning, and explore things that interest you. These maxims are probably true for success in many other careers.
I suppose that charts like this could be useful to find new things to learn? But you certainly don't need to know all of this to get a job. Trying to tick every box on a learning list like this amounts to procrastinating the real tasks of finding work and writing code.
Of course, you should do a great job, dedicate regular time to learning, and explore things that interest you. These maxims are probably true for success in many other careers.
I suppose that charts like this could be useful to find new things to learn? But you certainly don't need to know all of this to get a job. Trying to tick every box on a learning list like this amounts to procrastinating the real tasks of finding work and writing code.
[deleted]
I guess that’s why it’s a path. As you walk it, you learn it.
I've worked as a web developer for about half of the last fifteen years, and work as a senior front-end developer at a large web-focused company (Shopify). So I guess I'm fairly good at it?
Here's a list of things I have never even heard of just from the "Front-end Roadmap" section: BEM, OOCSS, SMACSS, Bulma, JSCS, ngrx, Vuex, Ava, Protractor, Cypress, Emotion, Radium, Glamorous, After.js, Universal, Nuxt.js, Carlo.
That's only the ones I've never even heard of until today. There's a bunch more I've heard of but never used.
This page is completely the wrong way of thinking about how to become a web developer.
Here's a list of things I have never even heard of just from the "Front-end Roadmap" section: BEM, OOCSS, SMACSS, Bulma, JSCS, ngrx, Vuex, Ava, Protractor, Cypress, Emotion, Radium, Glamorous, After.js, Universal, Nuxt.js, Carlo.
That's only the ones I've never even heard of until today. There's a bunch more I've heard of but never used.
This page is completely the wrong way of thinking about how to become a web developer.
I don't think it's purpose is for you to learn it all, but get the general concept of what to do/where to go next.
Kinda like in css frameworks, you probably know what bootstrap is, so Bulma is basically alternative to that, but you don't actually need to know/learn them all
Kinda like in css frameworks, you probably know what bootstrap is, so Bulma is basically alternative to that, but you don't actually need to know/learn them all
I haven't heard of any of those except BEM. Which you are using at Shopify, you just might not know it's called that. And it's not really a tech, it's just the style of naming css classes, "block element modifier" like on your home page: "marketing-form__fallback-cta" - marketing-form is the block, "__fallback-cta" is the element (only has meaning within the block), and if you had something like "--purplesmoke" that would be the modifier. Super simple, link here: http://getbem.com/naming/
Ah, thanks! Yes, in that case I have actually heard of BEM before then because I've followed that convention on a few projects.
Charts like these are guaranteed to scare anyone trying to enter the web development field. A junior position requires much less than is shown there.
And as you get truly senior you've picked out the stack you like best out of the ones you've tried, the stack that lets you do anything you want to do with the least friction for your own personal style. And you realize there's little value to always being on the treadmill of replacing skills to swap their various pros and cons while your overall capabilities don't grow.
As I interpret it, it mostly is a graphical representation of what's related to what. I don't see anything wrong with that goal. If you mean the sheer quantity of the possibilities will scare people away, then that may not be a bad thing. Software is growing into a messy conglomerate of technologies where each org selects what to put on their own stack(s). One must be aware of that nature of the biz because it's not growing simpler.
In the old days, the big vendors gave you a tool-set and you mastered whatever that gizmo was. Those days are probably dead. Most modern programmers are multi-sub-gizmo gluers.
As a sales tool for STEM, yes it's bad, but it's good as a reality-check about the industry.
In the old days, the big vendors gave you a tool-set and you mastered whatever that gizmo was. Those days are probably dead. Most modern programmers are multi-sub-gizmo gluers.
As a sales tool for STEM, yes it's bad, but it's good as a reality-check about the industry.
True, but it's helpful for a junior to know the lay of the land even if they don't know how to use every one of these technologies. It does a junior no good to keep their head down and focus entirely on PHP, then when they look for their first job they find all the listings want React (not saying there aren't PHP jobs)
[deleted]
Following this chart would be the anti-pattern to KISS.
Instead, learn how to ask people "what sucks the most?" and then go and build solutions.
I've been doing that for more than 20 years for CxO's, product owners, developers themselves and consumers. One thing that has been constant is the solution is always different and the technology and tools come and go.
I would also add understanding the underlying protocols will help you immensely in any front/back/ops/busdev roles. They stick around a whole lot longer than tooling or frameworks/abstractions.
Instead, learn how to ask people "what sucks the most?" and then go and build solutions.
I've been doing that for more than 20 years for CxO's, product owners, developers themselves and consumers. One thing that has been constant is the solution is always different and the technology and tools come and go.
I would also add understanding the underlying protocols will help you immensely in any front/back/ops/busdev roles. They stick around a whole lot longer than tooling or frameworks/abstractions.
Even if treating this not as a roadmap to becoming a web developer, but more as a map of what an expert-level web developer might be familiar with, it's still scary.
Why does modern web development have to be so convoluted? Here is a wishlist of what I want from ONE language:
- A package manager like nix so that each project folder doesn't have to be hundreds of megabytes
- Static typing with minimally expressive (i.e. ADTs) type system, type inference
- Built in immutable data by default, so you don't have to pile on 3 different immutable data libraries
- A better alternative to HTML+CSS like Elm UI [0]
- One very high quality backend framework (exactly like Phoenix)
- One very high quality frontend framework like Elm but with better component reusability, that makes fewer allocations, and that compiles to efficient WASM
The benefits of a "one language to rule them all approach" should be extremely obvious to JavaScript developers who are following this approach with Node.js, React, etc. This huge mess of tools that they use now is a hairball of workarounds for JavaScript's many deficiencies. We essentially just need a better JavaScript.
[0]: https://github.com/mdgriffith/elm-ui
Why does modern web development have to be so convoluted? Here is a wishlist of what I want from ONE language:
- A package manager like nix so that each project folder doesn't have to be hundreds of megabytes
- Static typing with minimally expressive (i.e. ADTs) type system, type inference
- Built in immutable data by default, so you don't have to pile on 3 different immutable data libraries
- A better alternative to HTML+CSS like Elm UI [0]
- One very high quality backend framework (exactly like Phoenix)
- One very high quality frontend framework like Elm but with better component reusability, that makes fewer allocations, and that compiles to efficient WASM
The benefits of a "one language to rule them all approach" should be extremely obvious to JavaScript developers who are following this approach with Node.js, React, etc. This huge mess of tools that they use now is a hairball of workarounds for JavaScript's many deficiencies. We essentially just need a better JavaScript.
[0]: https://github.com/mdgriffith/elm-ui
Seems quite comprehensive, perhaps more than any web developer needs to know, but a good resource nonetheless.
For FE, I'm glad DOM manipulation is in there somewhere. These days with modern frameworks becoming a big thing an all, I feel DOM manipulation as a skill is falling by the wayside.
For FE, I'm glad DOM manipulation is in there somewhere. These days with modern frameworks becoming a big thing an all, I feel DOM manipulation as a skill is falling by the wayside.
Agreed about DOM manipulation. I feel like they should emphasize that a bit more in this roadmap. Also, apparently you only need to learn about HTTP/S is you are doing DevOps...
I still recommend http://domenlightenment.com/ to ppl to get a nice base line of what you can do with the browser (a 2013 book but the browser APIs don't change much, they mostly keep adding stuff).
https://hpbn.co/ is a good resource for the networking side of things, if maybe a bit advanced, not sure what would be a more gentle resource to start with.
With regard to CSS, I don't really have any good book recommendation, maybe someone can chime in.
I still recommend http://domenlightenment.com/ to ppl to get a nice base line of what you can do with the browser (a 2013 book but the browser APIs don't change much, they mostly keep adding stuff).
https://hpbn.co/ is a good resource for the networking side of things, if maybe a bit advanced, not sure what would be a more gentle resource to start with.
With regard to CSS, I don't really have any good book recommendation, maybe someone can chime in.
[deleted]
Notably even the frontend path omits anything on how websites should function―even though it's in a different field if you're for strict ultra-specialization, it's still recommended to learn how to not accidentally make sites that are hostile to users. Arguably, it should be learned before the programming part, so it's ingrained from the start.
E.g. for me the defining text is Jakob Nielsen's “Designing Web Usability: The Practice of Simplicity,” which probably didn't lose any value in the time since publication, because humans don't change so fast.
P.S. I'm also of firm belief that the proximity principle is by far the most important tool of graphic design and that everyone should learn to see and use it. To, ahem, not make diagrams where everything is lumped together.
(I'm a backend coder, by the way.)
E.g. for me the defining text is Jakob Nielsen's “Designing Web Usability: The Practice of Simplicity,” which probably didn't lose any value in the time since publication, because humans don't change so fast.
P.S. I'm also of firm belief that the proximity principle is by far the most important tool of graphic design and that everyone should learn to see and use it. To, ahem, not make diagrams where everything is lumped together.
(I'm a backend coder, by the way.)
This feels overwelming. While I realize Rails isn't the cool thing in the web space anymore, I'm still convinced the best way to get someone into web development is to sit them down with Michael Hartl's Ruby on Rails tutorial and have them go through it any number of times. I've turned several zero-experience friends and/or interns into career web developers this way.
agreed. i find it odd that node and php are called out as the easy way to get into backend. ruby seems more intuitive and friendly than either javascript or php (not so much that they're hard, but they have more non-intuitive quirks and weirdnesses).
i like rails a lot, but i can somewhat sympathize with the view that the magic underlying it might hinder learning for a beginner. but having learned other languages/frameworks first, rails seemed much cleaner (and welcome) in comparison.
i like rails a lot, but i can somewhat sympathize with the view that the magic underlying it might hinder learning for a beginner. but having learned other languages/frameworks first, rails seemed much cleaner (and welcome) in comparison.
Is Why's The Lucky Stiff not the thing anymore? Or was that just for Ruby...
No, _why disappeared from the internet a while ago...
https://en.wikipedia.org/wiki/Why_the_lucky_stiff
In fact, we're coming up on ten years now! Holy shit I feel old now.
https://en.wikipedia.org/wiki/Why_the_lucky_stiff
In fact, we're coming up on ten years now! Holy shit I feel old now.
In my opinion, "top-down" learning based on one's needs and wants works better.
I want to write some text and show it on my browser. (Learn some basic HTML)
I want to add some styling to the text I just wrote. (Learn some basic CSS and understand how it relates to the HTML you wrote previously.)
OK, now I want to publish what I wrote so I can show off to my friends. (Learn basics of static hosting and uploading files to a web server.)
I want to add a timestamp to the page that automatically updates when the page loads. (Learn what JavaScript is and how it relates to web pages.)
And so on. Travel down the rabbit hole and pick up new concepts and tools as you need them. This will keep you motivated, unlike "bottom-up" learning where you learn concepts first without a clear idea of when and why you might need them (if ever).
I want to write some text and show it on my browser. (Learn some basic HTML)
I want to add some styling to the text I just wrote. (Learn some basic CSS and understand how it relates to the HTML you wrote previously.)
OK, now I want to publish what I wrote so I can show off to my friends. (Learn basics of static hosting and uploading files to a web server.)
I want to add a timestamp to the page that automatically updates when the page loads. (Learn what JavaScript is and how it relates to web pages.)
And so on. Travel down the rabbit hole and pick up new concepts and tools as you need them. This will keep you motivated, unlike "bottom-up" learning where you learn concepts first without a clear idea of when and why you might need them (if ever).
Yeah the approach you mentioned is very effective, it’s a deductive learning approach.
The front-end dev chart is only mislabeled, that's the amount of knowledge one needs to become a senior front-end dev.
I'm in my seventh year of this career, and recently obtained a senior front-end role. I've worked my way through the front-end chart and it's not wrong. To write really solid web applications that work for you, other devs, users and users of limited ability, you should know all that stuff. Only lately have I gotten my skills up to the point where I can write high quality JS, CSS, HTML, and test it fully, automation test it, organize my CSS effectively, make sure it's accessible and make sure I am at least aware of possible security issues. It's a lot of work that requires a lot of knowledge that takes years to develop, but it's not wrong.
I'm in my seventh year of this career, and recently obtained a senior front-end role. I've worked my way through the front-end chart and it's not wrong. To write really solid web applications that work for you, other devs, users and users of limited ability, you should know all that stuff. Only lately have I gotten my skills up to the point where I can write high quality JS, CSS, HTML, and test it fully, automation test it, organize my CSS effectively, make sure it's accessible and make sure I am at least aware of possible security issues. It's a lot of work that requires a lot of knowledge that takes years to develop, but it's not wrong.
I remember back in the day when I was referred to as a "web master" - and I didn't even know how tables worked in HTML at the time.
I still have to google how they work
15 years later...
15 years later...
I am too young to have ever used tables for anything else than table data. I am almost 30 years old today and have worked as a dev my whole career.
We sure have made some progress!
We sure have made some progress!
I'd say you started too late, I'm only 2 years older and when I took my first steps, tables were still a layout tool ;)
I take it, that you've never had to work with html emails then? groans You lucky soul!
Creating HTML emails for Outlook is what I imagine the entire web was like several decades ago.
Not so much as you didn't end up trying stuff only to find it didn't work for some client and you could get away with just targeting Netscape and IE on an 800x600 screen.
My first website in '96 had a repeatable background image with text over the top. That's still problematic in email templates and easiest to avoid.
My first website in '96 had a repeatable background image with text over the top. That's still problematic in email templates and easiest to avoid.
I have, but I have always used normal html+css?
That works for simple emails, but when you start creating more complex designs tables are an essential tool to ensuring that every element behaves as you would expect:
https://templates.mailchimp.com/getting-started/html-email-b...
Building these types of emails without tables is doable, but you are going to get a lot of inconsistency depending on the device/client/browser.
https://templates.mailchimp.com/getting-started/html-email-b...
Building these types of emails without tables is doable, but you are going to get a lot of inconsistency depending on the device/client/browser.
I had worked on a project in 2010. It was a service that let you pick email stationary, customize it, and had a Outlook add-in and a bookmarklet.
It "worked" in Outlook (2003, 2007, 2010), Yahoo, Hotmail, and Gmail. And had to display correctly to the recipient in each of those clients.
It was by far the biggest pain in the ass I've ever worked on. Tables weren't enough to make it work outright. Outlook 2007+ couldn't do background images on a table cell, gmail would collapse empty cells, hotmail would remove certain inline styles, and yahoo was actually pretty nice.
The company I worked for took the project on for an equity split + payment plan, we saw a few hundred dollars from it before they went out of business.
It "worked" in Outlook (2003, 2007, 2010), Yahoo, Hotmail, and Gmail. And had to display correctly to the recipient in each of those clients.
It was by far the biggest pain in the ass I've ever worked on. Tables weren't enough to make it work outright. Outlook 2007+ couldn't do background images on a table cell, gmail would collapse empty cells, hotmail would remove certain inline styles, and yahoo was actually pretty nice.
The company I worked for took the project on for an equity split + payment plan, we saw a few hundred dollars from it before they went out of business.
Count yourself as lucky for not having to build designs/layouts in tables! Oh what a travesty that was.
For those who would like to have a solid understanding of how Web works, I would definitely recommend David J. Malan's CS75 lecture 0. (the first lecture). He has a positive vibe and the pace is optimal, so you will really enjoy the lecture. I also would like to thank him and Harvard Uni. for making this available to everyone for free. I sure would not be able to afford studying there, but these lectures helped me a lot.
https://www.youtube.com/watch?v=8KuO4r5CHjM
I think it is important to understand how basics work before jumping into details. You will not enjoy the best tools available if you don't know how to use them either.
https://www.youtube.com/watch?v=8KuO4r5CHjM
I think it is important to understand how basics work before jumping into details. You will not enjoy the best tools available if you don't know how to use them either.
What's the best path from a career perspective?
I spent 3 years in front end, largely because I didn't have a CS degree and didn't want to study for those "invert a binary tree" style Google interview questions (I don't have a problem with theory, I just prefer working on real-world problems than studying for interviews).
I was making a good six-figure salary before taking a sabbatical, but may be re-entering the workforce in the not too distant future. I need to decide whether to pursue front-end/full-stack jobs again, or to specialize in something else.
Although front-end would seem to be the most logical since it was my specialty (specifically React), I'm afraid that the influx of bootcamp grads pumping out React devs will saturate the front end talent pool and make jobs more competitive and limit salaries. That and front end still seems to have this stigma of being "easier" than backend, and I don't see that changing. I don't want to invest my career in a field that doesn't garner any respect or have any long-term job security.
Is there any truth to this, or am I being overly pessimistic?
I spent 3 years in front end, largely because I didn't have a CS degree and didn't want to study for those "invert a binary tree" style Google interview questions (I don't have a problem with theory, I just prefer working on real-world problems than studying for interviews).
I was making a good six-figure salary before taking a sabbatical, but may be re-entering the workforce in the not too distant future. I need to decide whether to pursue front-end/full-stack jobs again, or to specialize in something else.
Although front-end would seem to be the most logical since it was my specialty (specifically React), I'm afraid that the influx of bootcamp grads pumping out React devs will saturate the front end talent pool and make jobs more competitive and limit salaries. That and front end still seems to have this stigma of being "easier" than backend, and I don't see that changing. I don't want to invest my career in a field that doesn't garner any respect or have any long-term job security.
Is there any truth to this, or am I being overly pessimistic?
It is relatively easy to spot someone with Bootcamp experience versus those with practical experience. The market demand in any relatively large city for React/JavaScriptFramework is quite high at the moment. I've seen salaries in Atlanta normalize without favoring one side over the other. The only exception is mid-senior DevOps which currently pays 25% more than either 'specialty' track mentioned.
Maybe an experienced senior front-end dev would know most of that. But lets be real here. Most of us started out by learning how to get notepad.exe to save .html files and trying out a tag or two.
It's a good resource but I'd be looking more at using this to stay up to date with modern web dev work flows (which seems to have become insane over the past few years.)
It's a good resource but I'd be looking more at using this to stay up to date with modern web dev work flows (which seems to have become insane over the past few years.)
Very thorough with a nice visual design.
The major issue with this roadmap is that many of the listed items are not necessary for a junior web developer, can be learned later on, or not at all, etc. I don't see any distinction between these different categories of topics.
You only need to master the fundamentals of a small subset of the graphic to get your first job as a web developer.
The major issue with this roadmap is that many of the listed items are not necessary for a junior web developer, can be learned later on, or not at all, etc. I don't see any distinction between these different categories of topics.
You only need to master the fundamentals of a small subset of the graphic to get your first job as a web developer.
Roadmap to becoming a web developer in 2019:
Learn HTML, CSS, JS, and work from there.
Learn HTML, CSS, JS, and work from there.
Be aware that if you want to follow this roadmap, everything in it will be different when you're half way through.
If you want to be a web dev startup hipster, this list is for you!
The ironic thing is that your average JS toolbox has the power to sink a startup. You need to be able to iterate fast by utilizing the basics. When you're brand new and facing 30 competitors you're going to get rolled by the 2-man team that doesn't waste all their time burdening themselves with all this bullshit. Meanwhile the other 28 are probably busy reading these flowcharts, doing resume driven design, and speaking at low tier JS conferences.
In case anyone is as acronym-deficient as I am, and was confused by the supposedly-essential skills of "SOLID/KISS/YAGNI":
SOLID (https://en.wikipedia.org/wiki/SOLID):
- Single Repository Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
KISS (https://en.wikipedia.org/wiki/KISS_principle):
- Keep
- It
- Simple
- Stupid
YAGNI (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it):
- You
- Aren't
- Gonna
- Need
- It
SOLID (https://en.wikipedia.org/wiki/SOLID):
- Single Repository Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
KISS (https://en.wikipedia.org/wiki/KISS_principle):
- Keep
- It
- Simple
- Stupid
YAGNI (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it):
- You
- Aren't
- Gonna
- Need
- It
S in SOLID should be single responsibility principle.
There are some basics you need to know: css/html/sql/php (or python)
Depending on your goal, the thing is that none of these you need to know as an expert, but need to know the knowledge to collaborate with other people on it.
But yes, the times that you could make “top notch” websites on your own: doing a photoshop design, doing the css/html and code it in bare php are over :)
This diagram is scrary and gives a feeling of overkill.
Depending on your goal, the thing is that none of these you need to know as an expert, but need to know the knowledge to collaborate with other people on it.
But yes, the times that you could make “top notch” websites on your own: doing a photoshop design, doing the css/html and code it in bare php are over :)
This diagram is scrary and gives a feeling of overkill.
Analyse the problem then find the correct tools to solve it. There is no need to frontload all of this knowledge.
Nice to see relational DBs before NoSQL (learning the old and tried before the new). To follow that same pattern, SOAP should be earlier than REST. Taking a WSDL and running it through a client code generator is a fast and type-safe way to develop.
I'm roughly right around or after "pick a framework" in the front-end guide (and can do some android stuff too). What level of a front-end dev am I?
(I actually transitioned to product/project management at that point, just wondered)
(I actually transitioned to product/project management at that point, just wondered)
[deleted]
[deleted]
If you know everything on the chart and have done this shit for Fortune 500 companies over the span of a 10 year career
How much money should you command
How much money should you command
If you know 10% of the chart and have much more soft skills you can earn more than than someone who knows 100% and neglects people skills. Most of that stuff will be legacy tech in a few years.
200k minimum would be my estimate.
Depends on where. Location, can increase your salary by 50% or more and increase your cost of living by 200% to 600% or more.
Since nowadays everything is connected to the web somehow, should we not look for a better term than "web developer"?
This infographic reminded me that I need to make the transition to management before I become even more irrelevant.
I think this is perfect for people that have experience and just don't know the path forward.
Also I enjoy seeing cross overs that you can compare such as you could make a transition into dev ops if you choose an appropriate back end, scripting language.
Everyone here is too critical, I think it's a lot of information, but it's very useful to see the goal and steps in front of you.
Also I enjoy seeing cross overs that you can compare such as you could make a transition into dev ops if you choose an appropriate back end, scripting language.
Everyone here is too critical, I think it's a lot of information, but it's very useful to see the goal and steps in front of you.
PostCSS should be a recommendation.
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!