
Roadmap to becoming a web developer in 2017 - mpweiher
https://github.com/kamranahmedse/developer-roadmap
======
chrisabrams
What I find most interesting is that the majority of these technologies did
not exist or were in their infancy ~7 years ago when I first moved to Silicon
Valley. Looking at this chart must be much more intimidating for a young
developer today.

I remember a decade ago when a front-end developer meant you handled
HTML/CSS/JavaScript/Apache/PHP/MySQL. Today, there are 15 forks in the road
all leading to different paths as a front-end developer.

~~~
scriptkiddie95
As a young developer, it really is intimidating. Hard to know where to even
start these days, it's overwhelming.

~~~
marknadal
I highly agree, and have strongly voiced "keeping things simple" with:

1\. HTML4 (no special/new tags) Edit: CSS, of course (unfortunately, CSS is a
pain to learn though, so get a lot of experience/experimenting)

2\. Pure ES5 JavaScript (don't waste time with build-steps/compiling JS, that
defeats the point/purpose - or if you want to, learn a language like
ClojureScript or Elm/Haskell)

3\. jQuery to manipulate the DOM (skip frameworks and stick to libraries, this
will force you to actually understand JS rather than being a copy-paster. Once
you have this down, build your own personalized framework to abstract things
away, only then should you try experimenting with Angular/React, etc. others)

4\. Notepad++ or Sublime (avoid using any terminal tools, including NodeJS,
until you are comfortable with having a browser and an editor open side by
side, and refreshing when making changes. Keep it simple: just files!)

5\. NodeJS or PHP, GitHub for Desktop (learn basic command line use, but if
something takes you more than 20 minutes to figure out, seek out a
community/forum/help that is friendly and encouraging to newbs. Don't waste
time on channels that make fun of you for not knowing command line.)

6\. Heroku (for deploying, and having your page live to show your mom what you
built)

I wrote a beginner's tutorial for the first 3 items, it takes between 5
minutes to 30 minutes for people who have only played with a little bit of
HTML. It teaches you how to build a ToDo app:
[http://gun.js.org/think.html](http://gun.js.org/think.html) , let me know if
there is anything I can do to improve it.

~~~
et-al
CSS needs to be included. CSS is the polish that changes a proof of concept
into a presentable product.

There's a number of _Show HN_ projects that I'm hesitant to invest much time
in because they look like the author won't bother maintaining them months down
the line. Even your nicely made tutorial has CSS. ;)

btw feedback:

* For some reason it wasn't evident to me that the left black box was editable and I actually interacted with the right-side wondering why nothing was happening. Perhaps use something that doesn't have an interaction so I don't try to click the button at first glance.

* Found myself scrolling up and an down a lot to read the next few instructions and updating the code. If things were side by side, this would be easier.

* It'd be nice to step backwards for the instructions

* The pre-formatted code in the instructions is a bit small. Might be hard to read for some people

~~~
gingerbread-man
I would _happily_ pay a consultant $300 an hour to do the CSS for my websites.
I imagine someone who specialized in CSS could do in 10 minutes what would
take me several hours of googling and hair-pulling frustration.

~~~
doublerebel
I will do this for you in one-hour minimums. Just send me the list of wants
and the git URL+creds or tarball/zip. Contact me through any channel,
satisfaction guaranteed.

------
m_fayer
Yep, surprisingly good. My only criticism is of the implied simplicity of the
"backend". In reality the choices are vast with a huge long tail.

That's because backend, as opposed to frontend or mobile, is really just good
old fashioned general purpose computing with a sprinkling of networking and
http middleware, and distributed systems glue.

~~~
oever
Exactly. It troubles me that all four suggestions for the backend have very
few inherent checks and leave a lot of room for security problems and other
bugs.

Personally, I prefer Yesod for the backend. It gives a very fast, static
binary. It requires learning Haskell.

The Haskell package Esqueleto ensures type safety all the way from the HTTP
requests to the database tables. A URI parameter that is encoded to be a key
on a table can only be used when querying that particular column or columns
that are foreign keys to it.

~~~
alexashka
This roadmap is for people who actually want to have a job at the end of their
roadmap :)

~~~
flukus
A job at a trendy startup. If you want a job learn something used in regular
business.

------
Etheryte
If a guide recommends jQuery as a central basic in 2017, it's hard to agree.
Sure, it can have its uses in old projects and simple one-off scripts, but for
any reasonably sized project with reasonable browser support you will be going
with something else. Is it still worth knowing? Sure. Is it something you
should learn first? Absolutely not.

~~~
spraak
Similarly I'm confused at the 'personal recommendation' of gulp over npm
scripts. Does anyone really use gulp for new projects..?

~~~
bshimmin
Is gulp seriously so out of fashion _already_?

~~~
Zalastax
It was used to hack together build pipelines since the tools didn't fit
together nicely, creating hard to debug messes which we grew tired of. Those
hacks can be replaced with webpack and you're often left with a few snippets
that fit nicely in the script section of package.json (npm scripts). Gulp is
still useful for some projects, but a lot less often.

------
noobiemcfoob
All of these can be reduced to... learn what you need to learn to build your
thing, learn that, then go build your thing.

------
idlewords
If you're a newcomer to web development, don't be intimidated by this stuff.
Much of it is unnecessary at any reasonable scale. The best piece of advice is
to have a small project you're genuinely interested in, and don't ever be
embarrassed because what you make is too simple or too plain-looking.

Your brain can only handle a fixed amount of complexity, so fight it at every
step, especially when you're just starting out.

------
nkkollaw
"start building" should be at the beginning, not the end...

~~~
robodale
This. Start building now. Get some momentum and motivation by working with
what you already know, then pull back on that stick and get that airplane
flying. Figure out how to steer/not-stall/do-loops/land with fancy stuff
later. It's the fear that you might do something wrong that's preventing you
from starting.

------
zeptomu
That is actually quite nice, but it also shows how incredible complex modern
web development gets as there are many moving parts involved.

The backend suggets Python, Ruby, JS or PHP and I agree that choosing one of
them is probably a good decision, as there is lots of documentation. However
if one goes down the Java or Go road, are there recommended packages - or do
people just use the standard libraries?

~~~
mcdevhammer
Spring Boot for Java

~~~
eranation
I second that. With honorable mention to Dropwizard

------
brian-armstrong
Computer architecture isn't even mentioned in the backend roadmap. That's
going to make a pretty weak backend type, who are usually very familiar with
the "how long does X operation take?" game

~~~
fizwhiz
Looks like it's mostly targeting application developers that don't normally
deal with nuances of specific microarchitectures.

------
yAak
This was fun to look at from a novelty perspective as a native application
developer.

Q: Should Rust be considered a noteworthy web backend development option, or
is there just not much community activity for that?

~~~
azdle
Probably not in a list like this. If you're just getting started you want
something where you can be productive fast. And I say this as someone who
writes web backend code almost exclusively right now.

The way that I see rust is as a language (& ecosystem) that is all about
making things right, reliable, & efficient. That unfortunately comes with a
bit of cognitive overhead during development. If you combine that with
learning rust it gets a bit more difficult, and if you combine that with
learning programming at the same time too you're going to end up with a lot of
people quitting out of frustration.

------
jetsnoc
Is anyone still developing multi-page architecture apps? Seems like you could
still develop simple applications a multiple of times faster with Ruby on
Rails or Django and sprinkle in Angular and/or AJAX Requests as needed. Surely
that is still a thing. I know that a lot of you are all engineering for
Netflix scale but developing two independent applications that speak to each
other over an API spec sure has it's costs and is a drag on a small scrappy
team wanting to iterate quickly.

~~~
szastupov
It totally depends on task at hand. If you have a db/forms heavy project than
Rails/Django gives you advantage, if your project is more driven by
interactions and subtle UX then SPA lets you focus on that.

Like, imagine how hard it would be to make Shopify as SPA
([https://engineering.shopify.com/17489056-rebuilding-the-
shop...](https://engineering.shopify.com/17489056-rebuilding-the-shopify-
admin-improving-developer-productivity-by-deleting-28-000-lines-of-
javascript)). On the other hand, Trello would never feel so fluid if it was
driven by server rendering (notice how weird Github projects comparing to
Trello).

Personally, I've been doing SPA for years and think it's the right way for
reach UI. But recently I had to build a form-heavy app and decided to go with
classical server-side setup + some jQuery on client. Old school but very
productive.

EDIT: added link to shopify blog.

~~~
jetsnoc
Of course, right tool for the job. I'm biased since most of our projects are
heavy on crud forms and database entry. Accounting and loyalty space.

------
bshimmin
My initial reaction to this was "Good grief, no one needs to know all this
stuff!" Then I saw the "Pick any" label in the key and it made a lot more
sense.

------
anotheryou
"star building" should be at the top

------
henryw
The backend is missing Java/Scala frameworks. Also, maybe Hack can be added to
the PHP branch.

------
ryanolsonx
It's pretty interesting that all of the backend languages are all interpreted
languages. No love for any typed languages?

------
soneca
Would anyone care to estimate how much time would take to someone starting
from scratch be able check all bright yellow boxes?

~~~
alpha_squared
A lot of time. Which roadmap in particular were you asking about? I'll attempt
to estimate each of the three, though I'm sure others here will have better
estimates in each. I'll overestimate as well, as much as double what I think
is fair because, if we're honest, developers are bad at estimating large time
periods.

This is hours-technology pairing. A '?' designates uncertainty.

Front-end:

010 - HTML

024 - CSS

070 - JavaScript

020 - jQuery (controversial / optional, I'd suggest it)

026 - JavaScript: ES6

010 - JavaScript: gulp

012 - JavaScript: npm / Yarn

0?? - JavaScript: Webpack

0?? - JavaScript: Typescript

/// TOTAL: 172+ hours

Back-end: (going to generalize)

060 - Language: Ruby / Python / PHP (+20) / Node.js (+??)

006 - Package manager

012 - Testing framework

024 - Web framework

120 - Web Server, Restful APIs, ..., Docker

0?? - Storage: Caching

036 - Storage: Relational databases

020 - Non-relational (NoSQL) databases

080 - Search engine, GOF design patterns, ... (+??)

/// TOTAL: 368+ hours

DevOps:

120 - Operating System

080 - Automation

140 - Cloud

0?? - CI / CD

0?? - Monitoring & Alerting

030 - Containers

030 - Cluster Managers

050 - Web server

999 - Love for terminal

??? - Everything else

/// Total: 450+ hours

You'll notice there's a lot of overlap between back-end and devops, though.
I'd say this is the _minimum_ time you'd need to understand the basics of each
branch, but you'd understand enough to be competently productive.

~~~
bshimmin
Pah, that's less than six weeks (if you don't sleep)!

I'd put a more realistic estimate at 2-3 years, though obviously anything
involving JavaScript will have changed at least 6 times whilst you've been
attempting to learn it.

~~~
alpha_squared
That's, true, but I was trying to estimate for a bare minimum, basic
competency to be productive. This doesn't include the countless hours
debugging, searching StackOverflow/Google and learning all the "gotcha"s in
each technology. Which all just takes experience and projects not necessarily
time.

------
hughes
This is quite an accurate overview of the surprisingly vast vocabulary of
concepts a web developer needs to be familiar with. It certainly looks a bit
daunting all laid out like this!

------
sAbakumoff
How come the 2017 backend chart doesn't have Golang?!

~~~
dullgiulio
It is correctly mentioned as "Go".

~~~
sAbakumoff
Oh, it's barely visible and for some reason it's in the same bucket as C# and
Java. That's so lame.

------
sauldcosta
This is really useful. We're building a lot of courses for Codevolve.com right
now and definitely will be using this as a reference for where to focus.

------
lukeda
It would be good to see the serverless architectures (eg. AWS lambda, API
gateway) added to the backend and/or devops section.

------
iLemming
Nothing about other languages transpiled/compiled to JavaScript? No
Clojurescript, Elm or Purescript?

------
domparise
I feel like this could also use DNS for backend or devops

------
hmans
Focus on HTML and CSS. Those will still be relevant in ~10 years, while most
of today's JavaScript hotness will be nothing but a memory long gone.

------
hoodoof
Nice. What was this drawn with?

~~~
et-al
Balsamiq -
[https://balsamiq.com/products/mockups/](https://balsamiq.com/products/mockups/)

------
gketuma
Like it

