Paths
How to Actually Become a Web Developer: A Path That Doesn't Waste Your Time
An opinionated guide to becoming a web developer: the right HTML/CSS/JS ratio, when to pick a framework, backend minimum, and a portfolio that gets hired.
Every month someone publishes a new "complete web developer roadmap" with 47 technologies, 200 hours of video, and a diagram that looks like a circuit board. Most of them are correct in the sense that everything on the list is real. Most of them are also useless as a learning plan, because knowing what exists is not the same as knowing what order to learn it and what to skip.
I am going to tell you what I actually believe: the path to a working, hireable web developer is shorter than the industry wants you to think. Here is that path.
The Starting Point: HTML and CSS Are Not Optional, But They Are Not Deep
HTML is a document markup language. It describes structure. You can learn the essentials, elements, attributes, semantic markup, forms, tables, in about two weeks of consistent daily study. CSS is harder and stranger, but the 20% of CSS that covers 80% of what you will actually write, the box model, flexbox, basic grid, typography, and responsive units, can be learned in another 3, 4 weeks.
The mistake beginners make is one of two opposite errors:
Error 1: Spending four months on HTML/CSS before touching JavaScript. You do not need to master CSS before you start JS. CSS mastery comes from building things, not from studying properties in isolation.
Error 2: Rushing through HTML/CSS in a weekend and straight to React. This creates a person who can copy-paste components but cannot build a layout from scratch, debug a flex alignment issue, or write a form without a tutorial. I have interviewed people like this. It is not a good position to be in.
The right ratio in the first two months: roughly 30% HTML, 40% CSS, 30% beginning JavaScript. They should be learned together, with each feeding the other.
JavaScript: This Is Where the Real Work Is
JavaScript is a full programming language with a complicated history, genuine quirks, and an enormous ecosystem. You should spend real time here, not to learn the entire language before building anything, but to understand the following core things well enough to use them without looking them up:
- Variables (
let,const), data types, operators, Functions, declaration, expression, arrow functions, Arrays and objects, how to create, read, modify, and iterate over them, DOM manipulation,querySelector,addEventListener, modifying content and styles, Events and event handling fetchfor making API calls and handlingPromise-based asynchrony, Basic error handling (try/catch)
That is not the entire language. Closures, prototypes, generators, WeakMap, those exist and they matter eventually, but they do not matter for getting hired as a junior developer. The list above does.
Budget three to four months on JavaScript fundamentals before you think about a framework. Build things with vanilla JS, not because frameworks are bad, but because when you understand what the framework is doing for you, you use it far more effectively.
Build Three Small Projects Before Learning React
I am going to be specific here because vague advice is useless.
Project 1: A to-do app without any library. Yes, this is cliche. Do it anyway. Building a to-do app in vanilla JS forces you to handle: creating DOM elements, reading user input, storing data in an array, updating the DOM when the array changes, and deleting items. These are the foundational UI patterns. Every framework in existence is solving the same problems you will solve manually in this project.
Project 2: A weather app that calls a real API. Use the OpenWeatherMap free tier or any public API you like. The point is to write fetch, handle async/await, parse JSON, and display the result. This is how most real web apps work, get data from somewhere, show it to the user. Do this before you learn any state management library.
Project 3: A multi-page portfolio site, styled by hand. Not a template. Not a WordPress theme. Write the HTML, write the CSS, make it responsive, deploy it. The discipline of making something look good without Bootstrap or Tailwind will give you a CSS intuition that pays dividends for years.
After these three projects, you have earned the right to learn React. You will also notice, when you start React, that most of what it does maps directly onto problems you have already solved manually.
When to Start a Framework
Start React (or whichever framework your job market uses, Vue and Angular are legitimate alternatives) when:
- You have finished the three projects above.
- You find yourself manually syncing DOM state with JavaScript variables and wishing there were a better way. That frustration is the right time to learn a framework, not before you feel the problem.
React is not magic. It is a systematic solution to a problem (keeping UI in sync with data) that you should have encountered yourself before being shown the solution. Frameworks learned before the problem is felt are frameworks poorly understood.
Learn React in this order: components, props, state with useState, rendering lists, handling form events, useEffect for side effects, and fetching data inside a component. That is the majority of what you will write as a junior. Context, custom hooks, and Redux can wait.
The Backend Minimum to Land an Internship
This is where opinions differ. Mine: you can get a frontend internship without meaningful backend knowledge. A full-stack internship requires more.
For a frontend internship, the minimum is:
- Strong HTML/CSS/JS, React (or the local market equivalent), Basic Git, clone, branch, commit, push, pull request, A public GitHub profile with the three projects above
For a full-stack internship, you additionally need:
- Node.js and Express, enough to build a REST API with a few routes, One database, SQL (PostgreSQL or MySQL) or a document store (MongoDB). Understand how to connect from your backend, run queries, and return JSON to the frontend., Deployed application, not just locally running
The SQL-vs-MongoDB question is not worth obsessing over at this stage. Learn SQL. It is more generally useful and is tested in more interviews. MongoDB is fine and popular, but if you have to choose one, choose SQL.
You do not need to understand databases deeply to land an internship. You need to be able to: create a table, insert records, run a SELECT with a WHERE clause, do a basic JOIN, and query from Node.js. That is it.
The Resume and GitHub Strategy
A resume without a portfolio link is a weak resume for a web development role. This is not negotiable, you are applying for a job where the output is visual and interactive. Employers expect to see your work.
GitHub strategy:
- Keep your three main projects pinned at the top of your GitHub profile., Every repository should have a clear README with: what the project does, what technologies it uses, and how to run it locally., Commit frequently and with meaningful messages. A repository with 3 commits looks like you copied the code. A repository with 40 commits over 3 months looks like you actually built it., Your commit history is visible. It tells a story. Make sure that story is "I worked consistently on this over time," not "I downloaded this the night before."
Resume strategy:
Keep it to one page. A junior developer resume that spills onto page two is not impressive, it is a sign of poor editing judgment. The sections that matter: a 2, 3 line summary (not an objective statement), skills (list technologies, not fluency levels, do not write "proficient in CSS," just write CSS), projects (link to GitHub and live demo), and education.
Do not list technologies you cannot talk about confidently in an interview. If you put "Redux" on your resume and cannot explain what problem it solves, that line will hurt you.
The live demo matters. Deploy your projects, Netlify and Vercel are free for personal projects and trivially easy for React/static sites. A recruiter who can click a link and see your work is significantly more likely to proceed than one who has to clone a repo and run npm install. Make the barrier as low as possible.
A Realistic Timeline
If you study 2 hours per day consistently:
- Weeks 1, 4: HTML and CSS fundamentals. Build a static page that looks good on mobile., Weeks 5, 12: JavaScript fundamentals. Build the to-do app and weather app., Weeks 13, 16: Build the portfolio site. Deploy it. Apply for internships., Weeks 17, 24: Learn React. Build a React version of one previous project or a new one., Weeks 25, 32: Add a backend, Node/Express + SQL. Build one full-stack project., Month 9 onwards: Apply for full-stack roles. Iterate on feedback.
Eight to nine months of consistent effort. Not three years, not three weeks. Anyone who tells you otherwise, in either direction, is selling something.
One More Thing
The web development job market is real and large. But it is also crowded with people who have consumed enormous amounts of tutorial content and built very little. The way you stand out is not by knowing more things, it is by having made more things.
Stop watching tutorials at the 80% mark and starting new ones. Finish the project. Fight through the confusing part. The confusion is not a sign that you need a better tutorial. It is the learning happening.
Build things. Ship them. Apply. Iterate.
Want to learn more?
Explore free chapter-wise notes with quizzes and code playground
Prefer watching over reading?
Subscribe for free.