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.
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.
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.
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 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!
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.
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?
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.
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.
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?
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.
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.
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.
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.
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().
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.
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.
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.
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 feel like I got into programming years back ( I chose JS/web focus for future job prospect reasons) because I wanted to be introverted and solve problems. Instead it's become an extroverts heaven of circlejerk-buzzword-sixfigurehunting-pretension. I kid - there are amazing people doing amazing things but maybe embedded systems or dsp is more what I'm looking for?
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.
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.
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.
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
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!!!
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.
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` :( .
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!
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.
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.
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.
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.
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.
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.
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.
> 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).
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.
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.
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...".
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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?
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.
114 comments
[ 2.7 ms ] story [ 179 ms ] threadQ: Should Rust be considered a noteworthy web backend development option, or is there just not much community activity for that?
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.
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?
That being said, buffalo is getting pretty popular. http://gobuffalo.io/docs/getting-started
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.
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.
Which virtually nobody is using in production.
.NET is a blip by comparison, JSP/Spring isn't even that. Perhaps just a case of different perspectives?
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.
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().
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.
Strongly weighing my options for moving into another space such as embedded systems or DSP, where the problems are a bit more tangible.
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.
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.
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.
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
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!!!
Every green browser have pretty good JavaScript support. document.getElementById will be your friend.
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` :( .
[0] http://caniuse.com/#search=innerText
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.
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.
Fortunately I have no desire to do front-end work.
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).
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.
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.
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.
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...".
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.
Isn't that full stack?
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.
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 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.
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.
Your brain can only handle a fixed amount of complexity, so fight it at every step, especially when you're just starting out.
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.