The web development ecosystem is downright daunting for newcomers. I’ve been thinking a lot about what a minimum curriculum for frontend devs might be. In other words—what’s the minimum path from nothing to applying for your first FE job?
I think it’d go something like this:
1) How the web works (e.g., client v server, HTTP)
2) HTML
3) CSS
4) JavaScript
5) Git
6) Choose a framework (React, Vue, etc)
7) Security (e.g., HTTPS, XSS, CSRF)
8) Accessibility
9) Projects (~1 vanilla, 2 framework)
Thoughts? Obviously, there’s so much more to the ecosystem, but again I’m trying to distill down to the minimum for a first FE job.
If you enjoy this discussion, please give it a 💓, 🦄, or 🔖 and consider:
- signing up for my free weekly dev newsletter
- subscribing to my free YouTube dev channel
Top comments (54)
I would take away the framework option. To me that is generally something a junior can learn or adopt on the job. An understanding of JS is most important.
At least with the way I learned, I started with a good foundation in vanilla javascript got a couple of small projects under my belt and then learned React. I'm super glad I went in knowing it already otherwise I would have been completely lost I was able to be up and running in a week rather than months. I would say it's definitely learning at least one then the rest should be easy.
Well... That depends.
You should be able to land a job by saying "I know Angular" (or Vue, React, whatever). Learning this stuff top down instead of bottom up, is an option and you can very well learn about http, an vanilla JS on the job.
That works if a company has a fixed approach to the way in which they do front end however it also pigeon holes the developer from moving on if they want to or increases the ramp up time if the company changes framework for whatever reason. A really good example of this is working for an agency doing projects for different companies. If one project requires Vue and another React then the developer will need to learn both. With a top down approach having learnt Vue they may not know the base concepts from Vanilla Js that would apply to React and therefore their ramp up time would be a lot slower than if they just had an understanding of Vanilla Js. It's all JS at the end of the day and I'd argue you can never fully understand a framework until you understand the base component.
All of what you said, is true. Top down might not be the fastest way to get to the long term goal, but it might be faster for the intermediate goal "landing a job".
If you got plenty of time, by all means approach the whole thing bottom up. If not, top down is a valid option.
If new-comers focus on...
That's a good start.
The back end or cloud requests all follow same pattern.
Keep functions small each doing only one thing.
Keep functions small each doing only one thing.
This is gold.
They're still trying to learn JavaScript (hell, so am I, and I've used it for 18 years). Forcing TypeScript on them is detrimental to that (and I'm not even touching the Angular thing). Otherwise I agree (but as my comment states, I'm still willing to work with potential if there's something lacking in the immediate actual).
Typescript for a beginner is simple. It can be used in full JavaScript only mode. For beginners, the intellisense option makes the blind see as they type. No more scrolling to find stuff.
I can understand your perspective because you are a JavaScript only expert.
Many JavaScript experts like Mike Elliot and others reject Typescript. The reasons they give IMO are inane half truths.
Typescript winds up all JavaScript anyway. It's only an annotation tool that keeps developers honoring design at code time instead of run time.
JavaScript has lots of traps for beginners.
So you're saying you could just use JSDoc (as you should anyway)?
No, that is your assumption. My perspective is informed by nearly two decades of JavaScript use, but also many years of TypeScript use (and seeing, long term, the messes that it can lead to in code "organization" for the sake of organization and stunted junior dev growth).
So does JavaScript, without all the non-JavaScript syntax.
And pretending it is/hacking it to behave like C# (I'm not singling out TS BTW, same opinion on CoffeeScript and Python devs; it's just not nearly as widespread these days), instead of learning the what and why of those "traps," is supposed to help beginners? The biggest traps in JavaScript are self-imposed, from expecting it to behave like class-based and/or statically typed languages. This is why I refer to You Don't Know JS as required reading for any JS dev, so they can learn (rather than avoid) its true nature. And like the "object oriented JavaScript" (🙃) craze Kyle Simpson warned about way back in the first edition (and I unfortunately lived through), TypeScript (BTW, are his criticisms of it half-truths?) is another attempt at hacking around that nature.
As Simpson said (paraphrasing): They're not "bad parts," or "weird parts," they're just JavaScript parts.
FWIW, I'll even credit TS with driving a lot of innovation in the evolution of the ES spec. And Intellisense with ts-check is fantastic. But you can set it to check JS (via JSDoc comments which, again, you should be using anyway, and which you can even scaffold automatically). No TypeScript annotation required.
Nobody I know who uses Typescript is pretending anything. They're just loving intellisense, sticking to the models and preventing stupid run time errors that add up over time. Jsdoc has nothing to do with Typescript but can be used in same way.
Your comments imply Typescripters are dumb asses who can't figure out its little brother.
Finally; if it's good enough for Google and Microsoft it has a strong future. Oh wait, I heard React supports it?
BTW... Messes are caused by people not coding languages. I've seen plenty of rotten JavaScript code but it has nothing to do with JavaScript.
I get it ; your dislike of Typescript triggered you to respond to a good recommendation. Not everyone has full on PTSD for Typescript.
No, my dislike for adding to learning curve for junior devs and simultaneously short-circuiting their understanding of the underlying language "triggered" me to respond to a recommendation which assumes that either a junior dev spent years learning both properly, or skipped proper understanding of JS to focus on your preferred cover. And no, unless it's Scratch, maybe, learning a language is not "simple" for a beginner; especially when you're piling on to the language they're already trying to learn with things which aren't actually a part of it.
I'm saying:
And no, I didn't call anyone "dumbasses." On the contrary, it was you who assumed that I couldn't possibly know anything about TS if I'm not emphatically cheering on the bandwagon. Guess what? PHP put a lot of food on my table for a decade and, while it's certainly light-years ahead of where it was when I started with it (when it was still procedural and would be for a while), and I've never diminished it as so many others so, I still can't really say I like it.
Look back on this thread, and you'll see that it began with me simply saying that that's not good for a junior JS dev's growth so early on.
It was you who led with assumptions:
And condescension:
Then followed with more smug condescension:
Pure opinion
Pure speculative prediction of how a person will learn.
Nonsense
You mean like 3rd gen languages, piled on top of Assembly?
It doesn't get in the way that's just your opinion.
Typescript doesn't prevent this, this is just your opinion.
Only you said it was like C#, another pejorative opinionated comment.
No you just implied it.
No I just disagree with your final "expert" conclusions, just like Mike Elliot.
Irrelevant point
That's no condescension, it's the truth masked in what I believe are "Studies by biased people"
When anyone claims the "absolute truth" they are already off-base. I challenged every one of your assertions of which you didn't respond.
Javascript is a sick language in healing mode. It's getting better, and Typescript forced it along the way as you agreed. What's interesting is that Typescript people were enjoying these "new features" 5 years before they were adopted by ECMA. Javascript is a wonderful language but so is the concept of Type annotation, because that is the only difference between Typescript and Javascript, and it's 100% optional.
As far as inheritance and polymorphism, both "evil" OOP Concepts, didn't I see that both Angular and React use base classes just to get going? And prototypal property defs. work ok, but the syntax is awful. In Typescript all properties become prototypal but not once is the awful syntax seen.
One last thing, in Typescript via the tsconfig.json file we can change the targeted JS dist version by typing in ES5, 2015, ES6 and other versions.
You mean when someone's "absolute truth" isn't "TypeScript is amazing and the ONE TRUE WAY™ to write JavaScript and every JS dev must bow before it."
And yeah, you're right about classes (and all those methods you can't reuse)... But ES6 "classes" were always a concession to devs like you who whined about how those "evil" concepts work in an already OOP language, just one not based on classes. But even if you can't see how that further proves my point about learning the what and why of JavaScript vs. slapping your preferred OOP paradigm on top, you inadvertently made another concession that TS isn't even necessary.
If you haven't noticed, React has also created a much more reuseable (and cleanly transpiled - do a simple output comparison of class vs. functional/hooks components) alternative. No "OOP" class crutch required.
I never said that, indeed it was you stating Javascript is the only way.
Makes no sense
No sense again. Besides I never whined about anything.
I've never dismissed learning the what and why of Javascript. You implied, wrongly that people that learn Typescript do not learn proper Javascript concepts.
Not necessary, Typescript compiles all classes to functions anyway.
That's your bias right there, in black and white.
You've spent half of this discussion making cases for things TypeScript does which do not require TypeScript, the other half badmouthing the way JavaScript does things in support of why you need TS and classes (hence my use of "crutch," and your "transpiles to functions anyway" shows not only doubling down on the crutch and inadvertently making yet another case against any "necessity" of TS, but favoring it over performance or just missing the point completely), and all of it in dismissive rudeness; trying to paint me as an idiot because you're "triggered" (your word) by the audacity of a JS dev saying: Not only are these things unnecessary, but they get in the way of a junior dev learning how things work (the things you keep badmouthing) in a language which (by your admission) it will always end up being in the end.
Oh, and implying that basically every other JS dev not using TS considers inheritance and polymorphism "evil," rather than allowing any possibility that we may, in fact, understand them, just understanding that they work differently than in class-based languages (again, kind of the whole point of letting junior devs learn JavaScript itself without imposing TS on them before they do).
What's really ironic is that the last TS defender who got in a spat with me claimed that TS makes it harder to use classes (I'm all for discouraging their use, but not like that), only to edit that out of his comment when I quoted it and called him on the contradiction, resorting to "I didn't say that" gaslighting... Eerily similar to what you're doing every time I call you on how you're behaving (but at least to your credit, to my knowledge, you're not also tampering with evidence in the process).
I don't need TS or Classes
You've already decided that anyone who uses TS is handicapped. That's why I stated earlier you insinuate they are dumb asses.
It was you that posted here in defense of plain ole Javascript not me. It's only your opinion it gets in the way. I find intellisense far superior to anything I've seen in the past with Javascript. I believe Typescript is way easier to use because of that.
That's because Typescript haters like to tie in 'those lame (crutch people), lazy (don't like to study Javascript) and begging (have to have a class) OOPers' who love Typescript irregardless of use of polymorphism, inheritance or even class use.
One thing I can say about other static typed languages, I never once read a book like "Java: The Good Parts" that's only reserved for Javascript 'deep dives'. Does that imply there were bad parts? Yes.
How hard is it to use a class, it not hard , just hated. What's harder about using classes?
Everything I've posted is true, the truth hurts sometimes, but as mentioned before it was your post that started this conversation off not mine. I'm just glad to engage you because this and other posts on the same topic act as libraries so I can get many perspectives on why Typescript is hated by some so much.
The evidence so far has pointed to nothingness, empty space, dark matter! Just like Elliot's diatribe on "No quality gained with Typescript"... Ridiculous. Hey dudes, if you all hate it so much then just go away peacefully. You don't have to stir up shit...
Great! So don't force the former (and ideally not the latter, which is just sugar) on junior devs who still have a long way to go in learning the language.
Quite the contrary. It's handicapp*ING* learning actual JavaScript for some whether self-imposed or imposed on others.
I use it every day, in purely JS codebases. It's simple to set up for everyone in their editor settings, and project-wide. No non-JavaScript annotation syntax required.
JavaScript is OOP. Polymorphism is a key principle of OOP, inheritance makes it possible, so they're obviously a part of JS. Your comments are going to lead devs who are still learning to believe this isn't the case.
You mean the parts that behave similarly enough to the types of languages you're more comfortable with, instead of having to learn a different paradigm.
Not my words, those of the last TS worshipper because he wanted to trip me up for saying both TS and ES6 classes were a bad idea, until he was the one caught in a contradiction and had to edit his way out of it.
But in both ES and TS, they're just sugar. They're not real classes, because JS is prototype-based. And transpiled, they're hideous.
You:
Also you, next sentence:
LOL. Let the record show that I started by saying this wasn't a good thing to impose on junior devs, and was immediately greeted with assumptions that I lack experience in TS, and insults (to anyone who holds a non-reverent view of TS, apparently).
TypeScript is Great!
Why do Javascript people use the term Crutch for Typescript
Is Javascript an OOP Language?
Most JavaScript old timers push the functional nature of JavaScript which is good. However they don't seem to realize that good OOP winds up in small functional bits anyway. OOP meets functional styles all the time.
Is Javscript a functional programming language?
What are the benefits of Typescript?
Why do people hate TypeScript
Is Typescript an official language at Google?
Does GitHub really have close to 160,000 Typescript Repositories?
Who owns Github?
What is most popular technology
It's true that JavaScript is king today. It was an still is the only language internal to browsers. It was created in 1995. This makes it close to 25 years old. Typescript is 8 years old. Is Typescript's popularity rising fast?
Web Assembly has the ability to bypass both Typescript and JavaScript.
Will Typescript die? Not likely as Microsoft (who owns GitHub) and Google (the Angular creators) decided it's better for large scale projects.
WebAssembly can bypass both Typescript and Javascript?
According to Microsoft :
I'm glad the tone has improved in the last comment, at least.
But this is still an assumption:
I'm not "most JavaScript old timers" (that you know of, anyway). I've said repeatedly throughout this thread that JavaScript is OOP, and it's not hard to see that I've not once placed OOP at odds with functional - and in my initial response, my "otherwise agree[ing] with you" implied that my agreement included
Moving on, there are differences to note here:
Essentially, yes, though technically the JS API is still currently required to load it (for now, but probably not much longer). The difference is that WASM is loading pieces compiled from languages which are actually strictly typed and class-based, and acts as an alternative to JS. TypeScript, on the other hand, is a layer on top of JS (just as ES6 classes are on top of functions). While many (obviously) find this helpful, in practice this leads to a shift in thinking, treating JS as something it is not: Statically typed and class-based (even if the latter is TC39's fault, though TS influenced that).
And that brings me back to my original comment: This is not a good thing for junior developers. Nor is the additional syntax, when they can and should be learning how to comment properly instead.
And I've never denied that many projects I use and love (and many I have yet to try, and some I used, hated, and moved on from) are built with TypeScript; however, even Microsoft's own words fail to make the case:
This is an architectural/design/QA issue, not a dynamic typing issue. You still need documentation. You still need linting. You still need a style guide. You still need tests.
And you still need to teach these things (and I don't care if the junior is coming from Udemy, Flatiron, or Stanford), ideally without adding to the learning curve.
Yes
Typescript improves the learning curve in my opinon.
In my experience, the work of a junior frontend dev can vary between different companies. There are companies (bad ones) that expect juniors to create full projects from scratch, these companies usually are consulting companies and I have seen several companies with projects full of bad practices and wrong software designs due to the lack of experience and preparation of these juniors developers. On the other hand, we have companies that develop a single product or a limited amount of products in these companies juniors usually have to work in very specific tasks and they would have the opportunity to learn from a senior developer, unfortunately, it is very difficult to get this kind of job, there are very few of these.
So, now having this in mind the answer to our question
What is the Minimum Skillset for Junior Frontend Devs?Really varies from company to company. I believe that it is a good set of knowledge and skills that you have already listed here which allow newcomers to have a view of the big picture. I have taught people with no prior knowledge of programming to code inside a company and they are great developers nowadays. I believe that soft skills are more important than hard skills.I believe the more important soft skills that a junior should have are the following
1)-Having the eagerness to learn continuously- I would expect a junior developer to work 6-8 hours daily and besides that investing 2-4 hours learning everything that they can. On free days invest 4-6 hours the more the better.
2)-Having the courage to recognize that there will be always something that you do not know- When falling a technical interview or being asked to do something that you have no idea how to do it don't blame yourself instead have the courage to use skill 1) and 3) and learn that thing that you don't know.
3)-Be humble and ask for help as often as you can- This is very important developers are very intelligent people and sometimes, they do not accept to ask for help because on a normal day they don't need help but in the programming realm there is a lot to learn and the more important things to learn comes from the experience if you are a newcomer pretending to know everything let me tell you that that is the worst strategy that you can adopt, learn to be humble and ask for help, also learn when to ask for help and how. Try not to bother every 5 minutes the same person, don't be ashame to say that you no idea about how to doing something, and if in your workplace there is no one you can learn from then go to online resources, stackoverflow, dev.to, go to workshops, hackatons, FB groups.
4)-Be resilient, learn from your mistakes and try again- If you fail at an interview or when creating a project. Embrace failure and learn from your mistakes I can assure you that this is the more important skill. If you didn't know how to answer a question in an interview then do some research to understand why you failed and fix it. Theoretically, there is a limited amount of things that they can ask you in a frontend junior interview maybe after failing 5,10 or 50 interviews learning for each mistake there will be a point where you will pass any interviews I am telling you that because that happened to me I failed like 23 interviews but that was few year ago last time I applied for jobs I got like 8 job offers and it is not like I am very smart or I am genius it turns out that companies always ask the same questions in interviews, in my last technical interview I solved 4 whiteboard algorithmic questions in like 20 minutes and the interviewer told me that I was supposed to solve 1 at most 2. He got angry and told me
How did you do that? Did you memorize everything?lol I even put edge cases, architectures, different language implementations, corner cases, test cases, design patterns, FP vs OOP approaches and data structures. And still, I feel like a complete ignorant (rule 2).Hopefully, my opinion can help any newcomers. Sorry for bad english.
As a newbie to the industry, giving my two cents I'd question a front-end dev role requiring how the web works and frameworks. Everything you've listed goes under tooling for me. HTML/CSS/JS are simply languages, Git is a method of tracing work, and Security / Accessibility are a must to consider when an End-User is trying to use your product. A Front-End importantly needs the skillset of what the user is needing and the empathy to understand why.
For example, recently I've moved away from a hamburger menu in my own site to a more native feeling bottom-bar approach because mobile users are bottom-bar navigators. My menu was short enough to transition to an approach where the main navigation should be in thumbs-reach at all times. If not, I can always add a vertical ellipsis / hamburger on the left or right (depending on country/culture) for further navigation options.
I actually love working with accessibility because it's concrete standards.
An Engineer should understand the deeper learning of how things work, however any developer or engineer first needs the fundamental skillset of problem solving in a way that suits the role presented.
Personally I've not landed a role in web dev just yet, I've love to work in Front-end, but I've learnt Full-stack JS for what Peyton mentioned; adding in other tools, languages, and how your own work is implemented is integral to understanding how your own work impacts on a project or for other members of a team. Combined, they're presented to the user who should hopefully be able to navigate their way with ease to what they're wanting to attain.
I think the minimum path from no prior knowledge is 12-18 months worth of concentrated study on the topics you mention above. A code school is a good option to structure that time and accelerate learning, if you pick a good one. Starting out with a month or two of self-study would be a smart way to see if this is really for you, before investing in technical training. It is possible to teach yourself, but your odds go up if you are in a cirriculum built with the end goal of getting you the job you want.
Over the top standards. Juniors should come with a solid base understanding of JS, CSS, HTML and how the web theoretically works with each other. Everything else is learnable or a plus.
Now let’s talk soft skills. Communication and being able to discussion objectively should be nothing the junior is afraid off. Teamwork and the kind of spirit to learn new interesting stuff must be given.
With the rapid pace of change in the tech industry, it can be difficult to predict which skills will be in demand in the future ?
However, there are top 10 skills that are essential for any front-end developer.
Instead of piling on to or tweaking this list, I'll start with what too many people in positions to hire devs at any level - but especially junior - fail to notice, acknowledge, or emphasize:
0) Willingness to:
I may not be able to hire you on this alone, but I can forgive and work with you on getting up to speed on anything lacking in what everyone else has mentioned if I see that you're strong in this requirement 0.
Hire for potential, not just current demonstrated proficiency - and that's not even getting into just how awful and ineffective most hiring processes' checks for proficiency are.
While far too many companies treat "junior" as "we're too cheap to pay you mid-senior level, but you still need a gazillion skills in these (often niche) technologies," it actually means "entry level" or not far from it. Keep that in mind and remember that you used to be there, just waiting for someone to recognize your potential and give you a chance, or at least tell you where and how to improve.
And if you expect all these things right off the bat, then you should probably be mentoring the hell out of people on and off the job; or at the very least, making damn sure you follow a rejection with detailed pointers on where to improve.
I'm not a frontend developer, but imho i would take away accessibility and maybe put in JSON and some basic knowledge (really basic) of webpack.
I'm not quite sure about focusing on a framework. A basic knowledge about the differences between Angular, React and Vue and how they work could be well enough for a Junior FE position.
I would say, basic accessibility knowledge is definitly neccessary. Esspecially I would put some of this basic knowledge into knowing HTML, because writing correct HTML avoids many a11y issues.
I would add: Optimising performance.