Roadmap to becoming a web developer in 2019

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.

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.

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.

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

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.

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.

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.

Btw that is some sweet looking graphs, but I think they would be even nicer if they where SVG instead of binary png's.

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

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.

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.

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.

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

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.

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

15 years later...

We sure have made some progress!