Roadmap to becoming a web developer in 2017 | Hacker News Reader

Roadmap to becoming a web developer in 2017

github.com

261 pointsmpweiher108 comments

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.

And you can never be sure what questions will be asked from you during an interview, especially, since the only thing job description says is "Rockstar frontend Engineer"

How many of those have you done? It's usually basic JavaScript / CSS / HTML / responsive design, performance, accessibility. You don't hire a plumber by asking him about the make of his hammer.

I've been using this exact analogy the other way around about hiring in IT. First screening is usually some HR drone scanning your resume/cv for buzzwords.

HR: So, I see on your resume you have been building houses for a decade. This is a good foundation for the work we are doing. Applicant carpenter: Yes, all sorts of houses. Done both interiors and prep for concrete pouring. Fiddled a little bit with wiring on a job where the electrician needed some help. HR: Uhu. Yes. What vendor did you use for your tools? AC: Pardon? HR: Well, we have secured a really good deal on tools from Stanley. Are you familiar with their hammers? AC: (puzzled) uhn, sure. I'm not too sure what I used on my last site. For me a hammer is a hammer. It has to be a really crappy tool not to do it's work. HR: Thank you for coming in. I think you should expect a call from us sometime next week. (marks the checkbox, Not familiar with tools)

Coding is usually based around learning the solution we are employing. It's a very boring problem if the solution is known beforehand. It's now knowing the tools that make you effective, it's being able to learn them that is valuable about a knowledge worker.

You don't hire a plumber by asking him about the make of his hammer.

You might if all the nails you have could only be used with a certain make of hammer and if learning how to use a different hammer efficiently could take several month.

Let's not get carried away, but that's the result of your own choice to accept vendor lock-in. Like having to hire only authorised service providers. Most companies I've known are smart enough to avoid that and just hire good generalist developers, and the interviews will be shaped accordingly.

*rockstar frontend engineer with 10+ years of experience.

> I remember a decade ago when a front-end developer meant you handled HTML/CSS/JavaScript/Apache/PHP/MySQL.

Wait a minute. If front-end developers handled Apache/PHP/MySQL too then what did back-end developers handle?

I used to think front-end means client-side (HTML/CSS/Javascript) and back-end means server-side (Apache-or-nginx/PHP-or-Python-or-Ruby/MySQL-or-PostgresQL).

Seven years ago when I was starting my current job that is what I was doing; which was all of it. From taking design's PSDs to turn them into markup, to programming the back end, and occasionally traveling to the data center to setup servers and networking. The "Full Stack developer plus SysOps" of trades.

My job was not labeled as front end, back end, DevOps, or SysOps. We did not really use those terms that are much more common place today. Just an engineer who was wholly responsible for various web properties from end user experience to server up time.

Thanks.

In which case OC is still wrong. It's not that "a decade ago when a front-end developer meant you handled [X, Y, Z...]" but "a decade ago there was practically no such thing as front-end development, only web development...".

It can get quite confusing on the terminology as the landscape has changed so much :O

Check out HN search for "front end development" from 7 years ago:

https://hn.algolia.com/?query=front%20end%20development&sort...

Three pages of low vote threads with the occasional mention of front-end development.

There wasn't much of a term of front-end development 7 years ago. It's a new thing.

You had back-end devs who would do some funky front-end stuff with often atrocious UIs and a bunch of designers who would hack together some jQuery plugins badly.

The highest voted story from 7 years ago is talking about converting PSD to HTML/CSS, which many of us back then would have sneered at being called development.

Yeah, I feel like the notion of a dedicated front end engineer as oppossed to an engineer working with a contract designer is relatively new. A few years ago, I was working contract at MS, and they had this concept of DevOps which seemed so weird to me. It was like a marriage between IT and engineering. Only in the last few years has DevOps come to stand on its own as a dedicated discipline.

which actually gives me some perspective for the speed at which FE tools seem be iterating. I'll have to keep that in mind moving forward.

what did back-end developers handle?

Making sure Apache/PHP/MySQL didn't fall on their face under load and yelling at the front end guy to optimize his bloody SQL queries. At least that is what I did.

As a young'un myself (u/g senior), I think the more disturbing thing is that I see stuff that's missing (from front-end alone: ES5, ES7, Babel, Selenium, service workers, deferred dependencies, accessibility, Backbone, UI/UX, polyfills, and generally YAGNI/KISS to remind people that there are few things on the web that actually need to be SPAs).

Fortunately I have no desire to do front-end work.

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

It doesn't really matter very much where you start. Pick something and dive in. Once you feel very comfortable with that, add another skill.

Personally, I'd suggest learning a programming language first: Python, Javascript, and Ruby are all good choices. Find a book you really like in one of those languages and read it cover to cover.

PS: https://eloquentjavascript.net is great, and free.

If you want to go with python, http://openbookproject.net/thinkcs/python/english3e/ followed by http://chimera.labs.oreilly.com/books/1234000000754 are both free and teach good habits on the way to backend web development.

I think this is the link for the site of the last edition of the 2nd book you mention http://www.obeythetestinggoat.com/

What a wonderful name for a programming book.

I actually bought a plushie goat and keep him on my desk.

Does 28 still count as young? I've been doing some form of web programming for 8 or 9 years now and it's almost impossible to keep up with JS/Node/NPM/100 different poor re-implementations of 'make'. Luckily there are big enterprises that provide job security without chasing every new framework.

These days I made a project as a test for a job.

It required a SPA framework, I am pretty much used to Backbone but wanted to use this opportunity to check how are the new shiny things these days. So I picked up Vue.js

The architecture is pretty clean, minimalistic and well thought. Soon I realized how terrible documented most of the tools on js land are these days, it was very frustrating to see that most of the options are not well documented, so that you must find a suitable blog post or tutorial from someone that is used with all the quirks.

This is not to say that the issue is with JS itself or it's ecosystem, it may be or not, but this little anecdote is what I can share from this experience. I hope this is just an exception.

I'm 28 myself, with experience primarily in web and ETL. I'm finding that even the big orgs are doing buzzword fishing on their jobs descriptions. MV* frameworks for largely static sites and data sets, served up to small, internal audiences, etc.

Strongly weighing my options for moving into another space such as embedded systems or DSP, where the problems are a bit more tangible.

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 , let me know if there is anything I can do to improve it.

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

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.

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.

I wonder how many can work in CSS these days? The proliferation of CSS frameworks/compilers is nearly as bad as javascript.

How can I apply?

Oh you are so right, my bad, CSS of course - updating my original post, I just blanked.

Those are good points - I need to figure out how to fit the instructions in while still having space for the editor and others. And yes to the others, I'll try to get them incorporated. Thank you!!!

For #3, I say skip jQuery and go with Vanilla JavaScript ala https://javascript30.com

Every green browser have pretty good JavaScript support. document.getElementById will be your friend.

This looks great!! Will have to peek at it more myself.

As you can tell, I'm a vanilla fan myself. Although I do think the DOM is still unnecessarily verbose - that aside, `innerText` still is not cross browser, so for that reason alone I recommend jQuery `$("#id").text("foo")` to discourage use of `.innerHTML` :( .

Why is innerText not cross browser? According to caniuse it's been in every major version of every popular browser for over a year.[0]

[0] http://caniuse.com/#search=innerText

Oh hmmm, I thought I tried it just the other month and it wasn't working. Maybe I hadn't updated IE, but I thought it was the whole Edge/11 split problem. Thanks for correcting me!

To my mind, using innerHTML is far better than including a 32K library just to avoid using it.

This is especially true if you want to apply for a job some day. Programming interviews are going to expect plain old javascript, not a framework-oriented approach. More importantly, jQuery is a tool. Know what you're making before you bother with a tool that makes it easier.

Not the programming interviews I've been in (on both sides).

I agree with you. Though, call it HTML5. CSS3 is OK, but so are Html tables. JS5 is lean and fine, I don't need the class syntactic sugar.

The most important skill is to brag about using a javascript framework that no one else has heard about in order to make everyone anxious that they are has-been already.

Echoing others here, definitely just pick somewhere and get started. Spending time worrying about making the "right" decision is the worst thing you can do. I made that mistake when I was teaching myself and it cost me a few weeks until I finally just picked a language and went with it.

You don't need to learn everything on there. Also, while some company may use/follow x (especially CSS methodologies), from what I've seen it's usually a poor attempt making it a lot easier to pick up.

Front end doing MySQL? And PHP?

Isn't that full stack?

Is that a sign that the good kind of consolidation hasn't happened yet or are all of these competing systems justified?

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.

And java and c# only get one little box each even though they're more widely used in the industry than node, ruby and python combined.

In the context of a "Roadmap to becomng a web developer" that seems appropriate to me.

For what definition of web developer? For front end web stuff most of that is unnecessary. For web apps then Java and c# are still more widely used.

Just wondering if you have any sources to support the claim. I've been under the impression that dynamic languages have had the lion's share of back-end web development for a considerable span of time - from PHP to Rails to Django/Flask to Node.

.NET is a blip by comparison, JSP/Spring isn't even that. Perhaps just a case of different perspectives?

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.

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

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

> It requires learning Haskell.

Which virtually nobody is using in production.

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.

Modern SPA tools require heavy tooling, which is fine but too overwhelming for a beginner. Even if the tools are easy to set up (create-react-app, next.js) they are thick layers, and when you start you better be closer to basics. jQuery is more basic.

Besides, not every project requires single page application interface. Sometimes, you'd be more productive with server-side rendering in classic framework like Rails and Django and and a bit of JS inside $(document).ready().

This. Thankfully, the only thing 'foundational' about the web is the pure languages that it is built upon, and not its frameworks.

The reason I had a 'web-development epiphany' is that I moved away from for months fleetingly trying to hack jQuery into my web projects, and then suddenly grokked React within days.

If you come from a programming background (and especially a functional one at that), learning ES6 javascript with a more modern framework (React, Angular, Vue) is the way to go.

If you read the legend, you would see that jQuery is color-coded under the "possibilities" category. This seems reasonable. There is a ton of work out there that requires familiarity with jQuery but it's not foundational or the only way to make a front-end by any means.

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

Is gulp seriously so out of fashion already?

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.

I heard webpack is in now. Grunt and Gulp have gone the way of the <marquee> tag.

I liked gulp, but it does seem like webpack has the mindshare going forward. If your using the Angular CLI then your project is using webpack.

While I agree that I wouldn't use jQuery in just about any meaningful project going forward I wouldn't dismiss it when you're on the learning path. jQuery serves as an incredibly good bridge between "I can write a for loop" and "I can build non-trivial web apps". The real trick is teaching why jQuery is useful without letting it become a crutch.

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

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.

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

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.

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?

For Java JHipster (https://jhipster.github.io) wouldn't be a terrible starting point.

For Go, people use either the standard library or third-party routers, etc. glued together

That being said, buffalo is getting pretty popular. http://gobuffalo.io/docs/getting-started

Spring Boot for Java

I second that. With honorable mention to Dropwizard

For Go people use stdlib.

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

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

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?

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.

Speaking as someone who is currently developing a web app with Rust: no, not yet. It's getting there, certainly, but the tools just aren't ready for general use yet and there's still likely to be a lot of change before things stabilize. In particular, tokio is still at 0.1, and many of the web frameworks have yet to move their internals to be based on it. Foundational pieces like serde and diesel have yet to reach 1.0, but are at least usable on the stable version of the compiler now. More bleeding-edge frameworks like Rocket.rs still require nightly though, and will continue to do so until procedural macros are stabilized.

This is not really an answer to your question but.. The one liner for Rust suggests that it's a systems programming language. It's designed to solve problems of software engineers who deal with lower level stuff than most application level engineers. Personally, I would try to pick a language that's more suitable for the job.

Rust is not a particularly convenient choice for general backend. Specific, high throughput / parallel microservices, yeah, but doesn't lend itself to being particularly productive in the realm of web dev.

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.

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

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.

I spent a long time developing traditional rails apps. Today I spend most of my time on SPAs, and that I can tell, development time is similar. Of course the first few SPAs took much longer while I learned things and the ecosystem built up, by today, I feel equally comfortable.

If you can get the time to develop the software to be similar with all of the benefits of a SPA, that is hard to ignore. Any recommendations on how to make this a reality?

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.

"star building" should be at the top

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

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

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

I just recently completed my journey to "tick all the yellow boxes", i.e. to have sufficient competence in every required technology to be able to build my own full stack applications from end to end.

For all three of the roadmaps on the diagram, it took me five years, part time weekends and nights.

What this means in practical terms is that most of the things that I need to build an application are familiar to me and I have worked with them and programmed them at some point, and I feel like I know where to start when resolving issues with those technologies.

And that was starting from the point of being extremely technical, and having previously owned software companies and already having architected and designed more applications than I can even remember, and having done a little programming here and there over the years.

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.

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.

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.

If you are actually comfortable at all with JavaScript as a proper programming language and not just as a bucket of jquery plugins you bundle together and use to toggle a class or two, then the tooling (gulp, webpack) are going to be only an hour or two each for a basic working understanding. Those tools in particular are very well documented and have a great community around them.

Optimistically? You could do it in two years if you're studying full-time, focused, and have a mentor for any roadblocks. Six months getting familiar with programming, and 6 months in each area (front, back, devops). However, with things like devops, I'd personally want someone with a year or two of real, working experience. And this is not factoring in the potential of burnouts from repeated 8-10 hour days of studying.

Lastly, it's pointless to check off all the boxes there unless you're trying to make yourself super marketable. For example, if a company is hiring a Rails developer, they don't care if you know Node/Django/Go/the next hot thing.

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!

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

It is correctly mentioned as "Go".

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

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.

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

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

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

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.

Nice. What was this drawn with?

Balsamiq - https://balsamiq.com/products/mockups/

Like it

Reply on news.ycombinator.com