Slog
↑↓Navigate↵Go to PageescClose
Soumitra Saha

How I Would Learn Full-Stack Development If I Started Again

I lay out the learning path I'd follow from scratch: the specific order, what to spend time on, what to skip, and where AI tools actually fit in.

How I Would Learn Full-Stack Development If I Started Again

Most developer roadmaps are long lists of tools with no clear order. Learn JavaScript, then React, then Node, then a database, then Docker, then system design — and somewhere in there, TypeScript. The list looks reasonable until you realize it tells you nothing about sequencing. The sequencing is where the actual advice lives.

If I were starting over today, I wouldn’t change most of the tools. I’d change the order, how long I’d spend in each stage, and exactly where I’d stop adding new things. This post is that path — specific, opinionated, and honest about the trade-offs.

I’m going to walk through eight stages and explain why each one comes when it does. By the end, you’ll have a clear picture of what to build first, what to defer, and what to skip entirely in year one.

On this page

Start with the platform: HTML, CSS, and vanilla JavaScript

This stage takes longer than most roadmaps suggest. Not a weekend. Not a week. Months.

JavaScript ranks as the most-used language in the Stack Overflow 2025 Developer Survey — 66% of more than 49,000 respondents. HTML/CSS comes in at 61.9%. These aren’t prerequisites to frameworks. They’re the platform the frameworks are built on. If you don’t understand what the browser does with a <form> element, why event.preventDefault() exists, or how the DOM reflects state that JavaScript changes, then React becomes a magic box that sometimes works and sometimes breaks in ways you can’t explain.

What to actually learn here:

  • The DOM: how the browser builds it, how JavaScript reads and modifies it
  • Events: the event loop, bubbling, the difference between click and submit
  • Forms: FormData, validation, default browser behavior and when to override it
  • Fetch: sending HTTP requests, reading JSON responses, handling failures
  • Async/await: why JavaScript is single-threaded and asynchronous, what a Promise is, how async/await makes it readable

Build something real. A page that calls a public API and renders the results. A form that validates before submission. A small UI that changes based on user input. Don’t move on until you’ve broken things and debugged them without asking an AI or a tutorial for the answer.

What to skip: jQuery. Not because it’s gone — 23.4% of developers still use it — but because vanilla JavaScript already does everything jQuery was built to do. Learning jQuery first adds a layer between you and what the browser actually provides.

Add TypeScript before you touch a framework

This is probably the most counterintuitive part of the path. Most roadmaps teach React first, then suggest TypeScript as a later upgrade. That’s the wrong order.

TypeScript doesn’t add new concepts on top of React. It adds a correctness layer underneath everything you write. Learning it in isolation — before a framework — means you focus on what TypeScript actually is: a tool that reads your code and tells you when a value might not be what you assume it is. Among professional developers, TypeScript usage has reached 48.8%. It’s nearly as common as JavaScript itself in professional codebases, and it has a higher admiration rate (58%) than JavaScript (47%). Starting with it as a given, not a later addition, is worth the upfront effort.

The TypeScript for JavaScript Developers post covers the mental shift in more detail. The key lesson there: TypeScript doesn’t change how your code runs. It only changes what gets caught before it runs.

Keep this stage narrower than you think it needs to be. Learn type annotations, basic inference, interfaces, and union types. That’s enough to write React with TypeScript, which is exactly where you’re going next.

React: understand the model, not just the syntax

React is used by 44.7% of developers surveyed and has the highest desired adoption of any frontend framework. It’s not going anywhere, and for a new full-stack developer it’s the right place to learn component-based UI.

The trap is treating React as a collection of hooks to memorize. Knowing the API without knowing why the rules exist will slow you down constantly.

Three mental models worth internalizing before anything else:

  1. UI as a function of state. A component is a function. When state changes, the function re-runs and produces new output. That’s the entire model.
  2. One-way data flow. Data moves from parent to child through props. If a child needs to change something in a parent, it calls a function passed down from the parent. Data doesn’t flow upward on its own.
  3. State colocation. Keep state as close as possible to where it’s used. Lifting state too high too early is the most common source of unnecessary complexity.

React Fundamentals: Components, Props, and State goes deeper on all three. Spending time there before moving to any meta-framework is worth it.

What to skip for now: Redux and state management libraries. If you need shared state across a small app, React’s built-in Context is sufficient to learn on. Redux adds real value in large codebases, but learning it early makes state management seem more complicated than it is.

The backend: Node, Express, and PostgreSQL

With a JavaScript foundation, TypeScript, and React in place, the backend feels approachable. Node.js — 48.7% usage, the most popular JavaScript runtime for backend work — runs the same language you already know. Express adds routing and middleware in a way that shows you what a backend framework does, without burying the fundamentals under heavy abstractions.

Build a simple REST API: routes, middleware, request parsing, and basic error handling. Then connect it to a database.

For the database, choose PostgreSQL. It’s been the most desired and most admired database in developer surveys for three years in a row — 55.6% of developers use it, and 65.5% say it’s the one they’d choose again. More importantly, learning it teaches you relational thinking: how to model data with tables, write queries with joins, and understand what the database is actually doing. That mental model transfers to every other database you’ll encounter.

Starting with a document database to avoid SQL just defers the same conceptual work. You’ll need relational thinking eventually. Better to build it when you’re starting fresh.

Git and CI/CD from day one

81.1% of developers use GitHub as their primary collaboration tool. That’s not trivia — it’s a signal that working without version control means working outside the workflow of nearly every professional codebase.

The goal here isn’t to memorize every Git subcommand. It’s to build a reflex: commit small changes with clear messages, branch for experiments, use pull requests as the default way to review your own work before merging.

Then add one automated check: run your tests on every push. That single habit forces you to keep tests current and your build reproducible. Both compound over time. A codebase with a CI gate that you’re afraid to break is a codebase you’ll treat more carefully from the start.

System design basics and AI tooling: add them late

These two belong together because they share the same failure mode — learning them too early, with too little context.

System design — load balancers, caches, message queues, database replication, service decomposition — becomes meaningful once you’ve built something that needs to scale or fails under load. Before that, it’s mostly abstract terminology. My 2026 Developer Roadmap covers the specific concepts worth learning in a year of deliberate study. The short version: learn enough to understand why the system you’re working on is built the way it is. Not enough to design a distributed system before you’ve shipped a working monolith.

AI tooling is where I’d apply the most caution. The Stack Overflow 2025 Developer Survey found that 84% of developers use AI tools — but 66% report frustration with solutions that are “almost right, but not quite,” and 46% actively distrust the accuracy of what they receive. I wrote about what I see as the real ceiling in What I Learned Building Full-Stack Applications in 2025.

The right moment to lean on AI tooling is after you’ve built the foundation. When you can read a generated function and recognize whether it handles the edge cases, whether the abstraction fits the problem, and whether the proposed approach matches your architecture — then AI tools genuinely speed you up. Before that point, they generate code you can’t debug. That isn’t velocity. It’s borrowed time.

What I’d skip, at least for the first year

A few things not in the path above, and why:

  • Multiple frontend frameworks at once. Vue, Svelte, and Angular are all interesting. None of them is the right second framework. Learn React deeply before exploring alternatives.
  • Docker and containers. Genuinely useful and eventually necessary, but not in year one. Ship something that works first. Then make the environment reproducible.
  • Microservices. Start with a monolith. Splitting services before you understand how the pieces fit together creates complexity without the scale that justifies it.
  • CSS frameworks before CSS. If you can’t write a flexbox or Grid layout from scratch, a utility framework will make things look right without explaining why. Learn the CSS first.

The order is the advice

The specific tools I’ve named — JavaScript, TypeScript, React, Node, Express, PostgreSQL, Git — aren’t the only valid choices. The shape of the path is what matters: platform first, then type safety, then a UI model, then a server and a database, then automation, then higher-order thinking.

Every shortcut in this sequence has a real cost. Skipping vanilla JavaScript means React’s internals stay mysterious. Skipping TypeScript means type errors become runtime surprises. Skipping relational databases means scaling conversations start from scratch, later.

The tools are interchangeable to a degree. The sequence isn’t.

Pick the next stage you haven’t finished. Build something with that stage in scope and nothing beyond it. The project doesn’t matter — the constraint does.

Sources