A layout that looked correct in the design file becomes a negotiation the moment it meets a real browser. The heading wraps at 768 pixels and pushes the button off screen. The form throws away everything the user typed when validation fails. The dropdown in the mockup has no keyboard behavior at all, because a static image never needed one. Frontend development is the trade of making that negotiation end in the user's favor on hardware you will never hold.
Tutorials tend to stop at the moment a component appears on screen, which is roughly fifteen percent of the job. The rest is state that arrives late, requests that fail, text that is longer than the placeholder, and a browser that ships a new version on a Tuesday. This page covers the whole of that, in an order that produces deployed work rather than a folder of exercises.
The Gap Between a Component and a Shipped Feature
A frontend developer builds the part of a product a person actually touches, inside a browser they did not choose, over a connection that stalls, for someone who will zoom the text to 200 percent and navigate with a keyboard. The deliverable is not a screenshot match. It is a page that keeps working when the data is missing, the network is slow, the screen is narrow, and the user does something the designer did not draw.
Most of the craft lives in four states that beginners forget. Loading, where something has to occupy the space so the layout does not jump. Empty, where the screen has to explain itself without looking broken. Error, where the user needs a way forward rather than a stack trace. Partial, where half the data arrived and the interface has to remain honest about it. A component that only handles the successful case is a demo. Four states make it a feature.
The role also carries a translation duty that no bootcamp mentions. A designer hands over a frame with intent about hierarchy and rhythm. A backend developer hands over a schema with fields that do not match the copy. A product manager asks for a flow that ignores what the browser will do on a slow phone. The frontend developer is the person who reconciles all three into markup, and who is expected to say clearly when a design cannot survive the data it will receive.
Day to day, the work is smaller and more varied than the title suggests. You spend a morning chasing a layout shift caused by a web font loading after the image. You spend an afternoon on a focus trap in a modal, because the keyboard user must not tab into the page behind it. You rewrite a list because it re-rendered four hundred rows on every keystroke. You explain to somebody why the redesign cannot ship on Friday without a regression pass on the three browsers your analytics actually show.
What separates a junior from someone trusted with the checkout page is not framework knowledge. It is judgment about failure: what happens when the API returns a 500, when the image is 4MB, when the user's session expires mid-form, when a translation triples the length of a button label. Frameworks come and go on a five-year cycle. That judgment compounds for a career.
The gate into paid work is a deployed thing with a URL. Not a repository of exercises, not a certificate, a site that loads for a stranger and does something useful. One live project with real users beats a folder of cloned dashboards, and hiring managers say so consistently, which is why the stages below end in deployment rather than completion.
What the Catalog Supplies, Area by Area
Four areas feed this role, and each one closes a different kind of gap.
Web Development carries the craft itself: markup, styling, layout, browser behavior, and the frameworks built on top of them. It holds 36 live entries, with 30 free and 6 paid. This is the area a beginner should live in for the first several months, because everything else assumes you can already turn a design into a responsive page without fighting it.
UI/UX Design supplies the judgment that separates a page that renders from a page that works. Hierarchy, spacing, contrast, affordance, and the vocabulary to argue about them with a designer without guessing. The catalog lists 30 resources here, 20 at no cost and 10 paid. It is the area where the paid share is highest, which is worth knowing before you assume the whole path is free.
Software Engineering is the discipline that keeps a growing codebase from turning into a liability. Version control, types, testing, naming, and the ability to read code you wrote six months ago without swearing. That area carries 36 live resources, split into 30 free and 6 paid. Frontend projects rot faster than most, because a component that works becomes a component that three other people import, and then the shape of it matters.
Databases & Backend is the half of the job that beginners try to avoid and then hit at full speed. Requests, responses, status codes, pagination, authentication, and what a database does when you ask it for a page of results. It holds 31 live entries with 27 free and 4 paid. You do not need to become a backend developer, but you do need enough of this area to debug your own network tab without asking someone else what a 422 means.
Read together, the four areas describe a working loop. The Web Development shelf teaches you to build the surface. UI/UX teaches you to decide what belongs on it. Software Engineering keeps the code readable as it grows. Databases & Backend explains where the data comes from and why it is late. Skipping the third and fourth is the most common reason a promising junior stalls at the second year.
From an Empty Folder to a Deployed Page
The sequence below is ordered by dependency, not by market demand. Each stage ends with something a stranger can load.
Stage one: write HTML and CSS by hand, with no framework. Not because frameworks are bad, but because a framework hides the layout model, and the layout model is where most bugs live. Responsive Web Design Certification (freeCodeCamp) (FREE) takes you from markup to flexbox and grid with exercises that require typing. HTML For Everyone: Real World Coding in HTML5 (FREE) covers semantic structure, which matters more than beginners expect once accessibility enters. Keep MDN Web Docs (FREE) open as the reference, since it is the only documentation that stays accurate across browser changes. Build Your First Website in 1 Week with HTML5 and CSS3 (FREE) is useful as a paced first pass if you need a schedule. This stage is finished when you can rebuild a simple two-column marketing page from a screenshot without opening a tutorial.
Stage two: learn JavaScript until the language stops surprising you. The browser is a JavaScript runtime before it is anything else. TypeScript: Basics to Advanced (Mohin Sheikh) (FREE) is worth taking early, because types catch the class of bug that eats a junior's afternoon. freeCodeCamp YouTube Channel (FREE) holds long-form courses on the language and the DOM that you can work through in sequence. Exercism (FREE) gives you mentored practice on small problems, which is the closest thing to a code review a self-taught developer gets. Finish this stage when you can explain the difference between an event bubbling and an event capturing, and when you have written your own fetch call with error handling instead of copying one.
Stage three: one framework, one application, all four states. Choose one and stay for a year. Build Your First React JS Application (FREE) gets a working app on screen without pretending you already know the ecosystem. Angular Basics for Absolute Beginners (FREE) serves the enterprise path, where structure and dependency injection are the point. Marko 6 Interactive Tutorial (FREE) is unusual: a server-first framework that teaches what rendering on the server actually changes about your component design. Whatever you pick, build the same application you would build in a tutorial, then add loading, empty, error and partial states, then break the network in dev tools and watch it behave. That exercise teaches more than three more tutorials.
Stage four: add the professional layer. This is where hobby projects become employable projects. Learn Git Branching (FREE) is visual, and it teaches branching and rebasing well enough that you stop fearing a merge. Git and GitHub for Beginners (Mohin Sheikh) (FREE) covers the collaboration workflow, which is a different skill from knowing the commands. Checklist Design (FREE) turns vague "make it look better" instincts into specific checks on spacing, contrast and states. Design Systems Repo (FREE) shows how real teams organize components, tokens and documentation, which is the structure you will be asked to work inside. This stage is finished when your project has a component folder with names you would defend in review.
Stage five: ship it, then defend it. Frontend Mentor (PAID) supplies professional designs with a review culture, which is the closest thing to agency work you can do alone. roadmap.sh Frontend Developer Roadmap (FREE) works better as a gap map at this point than as a curriculum at the start. App Academy Open (FREE) gives you a full curriculum if you want a structured second pass. Build a Portfolio Website with HTML, CSS, and JavaScript (Coursera) (FREE) treats the portfolio as a project with requirements rather than a gallery. Google Developers Codelabs (FREE) covers the platform features you will meet in real tickets, including service workers and authentication flows.
Testing belongs here too, at the smallest useful size. A handful of tests that cover the checkout path, the login form and the date formatting will catch more real regressions than a large suite of snapshot tests that nobody reads. The useful question is not how much is covered, it is which failure would embarrass you in production, and whether a test would have caught it before a user did.
Deployment belongs in this stage, not after it. Point a domain at it, add analytics, watch real sessions, fix the layout shift you find. A developer who has never looked at their own production error log is still a student, regardless of how many repositories they own.
Performance deserves a fixed budget rather than a cleanup pass. Pick a number before you build, such as the page reaching interactive on a mid-range phone over a throttled connection within a few seconds, and treat every dependency as spending from it. The decisions that matter are unglamorous: image formats and sizes, font loading, how much JavaScript ships before the first paint, and whether a carousel needs a library at all. Measuring with the browser's own tooling is free, and it changes what you consider acceptable.
Tools That Answer One Question Well
Some entries in the catalog answer one question so well that they are worth naming separately from the stages.
For visual judgment without a design education, Refactoring UI (PAID) is the shortest route from "this looks off" to naming the reason. Laws of UX (FREE) covers the perceptual rules that explain why some interfaces feel easier, without turning them into superstition. Apple Human Interface Guidelines (FREE) is worth reading even for web work, because it is unusually clear about state, feedback and touch targets.
For copying patterns instead of inventing them, Mobbin (PAID) holds screenshots of real product flows, which is faster than reasoning from first principles when the task is a settings page. Page Flows (PAID) records the interactions rather than the stills, which matters for anything with a multi-step form. Godly (FREE) curates site design with an emphasis on the ambitious end, useful for calibration rather than for copying. Growth.Design Case Studies (FREE) explains why a flow converts or fails, in comic form, with the reasoning shown.
For the design tool question, Penpot (FREE) is open source, and it is a legitimate substitute for the paid alternative when the work is layout and handoff rather than prototyping. Figma Learn (Help Center) (FREE) teaches the tool everyone else uses, which is worth an afternoon if you will be receiving files from designers.
For the backend half, Select Star SQL (FREE) teaches queries by making you answer questions against a real database in the browser. Full Stack Open (FREE) is the single best free bridge from frontend to full stack, since it assumes you can already build an interface. Express.js Guide (FREE) gives you a minimal server in an evening, which is enough to understand what your fetch calls are talking to. DB Fiddle (FREE) lets you test a query without installing anything. Backend Developer Roadmap (FREE) shows the shape of the other discipline, which helps you ask better questions rather than guess.
For the odd corners that show up in real jobs, Chrome Extensions: Develop 5 Extensions from Scratch (FREE) covers a platform most tutorials ignore. Beginner VS Code (FREE) saves a week of fumbling with the editor. Big-O Cheat Sheet (FREE) is the reference you want when someone asks why a nested loop over the product list is a problem. Software Engineering at Google (free ebook) (FREE) explains why large codebases are governed the way they are, which is useful context before your first review.
Zero Budget, Real Months
Web Development holds 30 no-cost entries against a modest paid remainder, and everything in stages one through four can be completed without spending anything. The paid items cluster in two places: certificate programs that impose deadlines, and design judgment sold as a product. Both are legitimate purchases at the right moment, and both are waste at the wrong one.
UI/UX Design is the exception worth flagging early. It carries 10 paid entries against 20 free ones, the highest paid share of any area in this roadmap, and a beginner can mistake that for a requirement. It is not. The free material in that area covers hierarchy, spacing, contrast and state design completely. What the paid entries sell is speed: curated examples, recorded critique, and a library of flows you would otherwise assemble from screenshots.
Time is the honest constraint. At a steady part-time pace, expect six to nine months before you can build a small site unsupervised, and twelve to eighteen before you are competitive for a junior role in a market that asks for a portfolio. The first month feels fast, because markup is forgiving. The third month feels slow, because state management and debugging are where the real learning curve sits. That is normal rather than a sign of unsuitability.
What should exist by month six: one deployed site with a custom domain, one application that handles loading, empty, error and partial states, one page you rebuilt from a design file and can explain every decision on, and a git history that shows how you work rather than one commit labelled "initial". Those four artifacts answer more interview questions than any certificate.
What money actually buys: deadlines, human critique, and a design library that saves research hours. What it does not buy: a portfolio, a referral, or the judgment to know when a layout is wrong. The most common wasted purchase in this field is a subscription to a design tool bought before the first project exists.
The first money you earn will probably come from something small and unglamorous: a landing page for a local business, a fix for a broken site, a WordPress theme someone needs adjusted. Those jobs pay badly and teach quickly, because a client will change their mind three times and the deadline will not move. Take two of them, keep the invoices, and write down what you would scope differently. That record is what lets you quote the next job without guessing.
Traps That Look Like Progress
The first trap is learning a framework before the layout model. A developer who cannot reason about flexbox will spend years fighting component libraries, because every library assumes the box model is intuitive to them. The symptom is a project where spacing is adjusted by trial and error and nobody can say why a container overflows.
The second is collecting tools. A build tool, a state library, a styling system, a testing framework, then a different set six months later. Tool churn feels like seniority and produces very little code. The stable core is smaller than the ecosystem suggests: HTML, CSS, JavaScript, one framework, one test runner, git.
The third is accessibility deferred until an audit. Retrofitting keyboard navigation into a finished product costs several times what building it in would have cost, and it is the one defect that can make a public sector contract disappear. The practical version is not an audit, it is a habit: tab through every screen you build, once, before you call it done.
The fourth is handling only the successful response. Every feature you build should be broken on purpose at least once. Throttle the network, return a 500, empty the array, and watch what the interface does. If it shows a blank rectangle with no explanation, the feature is not finished.
The fifth is never deploying. A local project teaches syntax. A deployed project teaches caching, environment variables, broken asset paths, mixed content warnings and the fact that your laptop's fast connection is not the user's. Deployment is not a final step, it is a feedback loop you should enter early and stay in.
The sixth is copying code without reading it. Copying is a legitimate professional skill when you understand enough to debug the copy. It becomes a trap when the code works and you cannot say why, because the first bug you cannot reproduce will have no explanation available anywhere.
The seventh is the portfolio that never ships. A developer who rewrites their portfolio four times has built one small site and four drafts. Ship the imperfect one, then improve it in public while applying. Nobody has ever been rejected for a live site with a slightly awkward hero section.
Where the Roadmap Leaves You
Go deeper in the four areas this roadmap rests on: Web Development, UI/UX Design, Software Engineering, and Databases & Backend. When a stage above felt weak, the matching area page is a better next stop than another framework tutorial.
The adjacent roles are worth reading if your interest is shifting. A UI designer spends the day in the design tool and hands over frames. A backend developer owns the request path and the data. A full stack developer does both halves at a smaller scale, usually at a company too small to split them. The full list is at Browse by Profession, and two neighboring roadmaps will tell you more about your own preference than another month of tutorials.
If you want one action now, take the last page you built and open it on a phone with the network throttled to slow. Everything you want to apologise for is the next month of work, and the list will be more specific than any curriculum.
FAQ
Do I need a computer science degree to get hired?
No, and the field is unusual in how consistently it says so. What gets read is a portfolio with deployed work and a conversation where you can explain your decisions. A degree helps with algorithms interviews at large companies and with visa processes in some countries. Those are real advantages, and they are narrower than the panic suggests.
Should I learn React first, or something else?
Pick the framework that the jobs you want actually list, then stay with it for at least a year. React has the largest hiring surface, Angular dominates in large enterprises, and server-first options are growing. The transferable skill is component design and state reasoning, which survives a framework change. Switching every six months teaches you three frameworks badly.
How much JavaScript do I need before touching a framework?
Enough to be comfortable with functions, arrays, objects, promises, and the DOM without a reference open. A practical test: build a small interactive page, a filterable list with a form, in plain JavaScript. If you can do that without copying, you are ready. If you cannot, a framework will hide the gap for about three months and then charge interest.
Is a paid design resource worth it for a developer?
Sometimes. If your pages render correctly but look amateurish, and you cannot say why, a structured resource on visual judgment pays for itself quickly, because it converts vague dissatisfaction into specific changes. If you already work with a designer who reviews your work, the same money is better spent elsewhere.
Do I need to learn backend development?
You need enough to debug your own work: HTTP methods and status codes, JSON shapes, pagination, cookies versus tokens, and how to read a network tab. Full backend competence is optional and useful. Not knowing why a request returns 401 is not optional, because it will happen in your first month on any real product.
How long before I can apply for junior roles?
Twelve to eighteen months of consistent part-time work is a realistic range, and the variable that matters most is whether you have shipped anything. Applications go further when they contain a live URL and a short explanation of one hard problem you solved. Applying at month four with four deployed projects beats applying at month twelve with none.
SkillCache Editors · Updated November 13, 2026
