What Happens When You Type a URL and Press Enter
DNS lookups, TCP and TLS handshakes, HTTP requests, servers, and the browser's rendering pipeline. The whole journey of a web page, explained so it finally clicks.
Read →What each role actually does day to day, the skills each one needs, how the job market sees them, and a simple way to figure out which direction fits the way you like to work.
If you're learning web development, you'll hit this fork quickly: frontend, backend, or full stack? Job titles make them sound like separate worlds. In reality they overlap a lot, and your choice is less permanent than it feels. Still, knowing what each one involves helps you focus your learning.
Frontend developers build the part of an application that runs in the browser (or on a device): layouts, interactions, forms, animations and everything that makes an interface feel good.
Day to day:
Core skills: HTML, CSS, JavaScript (and usually TypeScript), a framework like React, Vue, Svelte or Angular, accessibility, responsive design, browser DevTools, and a feel for design.
You might enjoy it if you like visual feedback, care about details users notice, and enjoy the craft of interfaces. (Responsive design and accessibility are good places to go deeper.)
Backend developers build the systems the frontend talks to: APIs, databases, authentication, business rules, integrations and background processing.
Day to day:
Core skills: a server language (JavaScript/Node.js, Python, PHP, Java, Go, C#, Ruby...), SQL and database design, HTTP and API design, security fundamentals, caching, queues, and some Linux and deployment knowledge.
You might enjoy it if you like data, systems and logic puzzles, and get satisfaction from things that are correct, fast and reliable even if nobody sees them.
A full stack developer works across frontend and backend, and usually deployment too. In practice, most full stack developers are stronger on one side and competent on the other. That's normal, and it's what most employers expect.
You might enjoy it if you like building complete features yourself, want to ship your own products, or work at a startup or small team where everyone wears several hats.
| Frontend | Backend | Full stack | |
|---|---|---|---|
| Focus | Interface and experience | Data, logic, infrastructure | Whole features end to end |
| Feedback loop | Immediate and visual | Tests, logs, API responses | Both |
| Changes fastest | Frameworks and tooling | Infrastructure practices | Everything, a bit |
| Common in | Product teams, agencies | Product teams, platforms | Startups, small teams, freelancing |
Even specialists cross the line constantly:
So whatever you pick, learn the basics of the other side. A frontend developer who understands databases, or a backend developer who understands rendering, is far more effective.
If you're not sure, start full stack. It keeps your options open, and you'll discover your preference by doing. Here's a structured plan: the full stack developer roadmap.
All three are in demand, and it shifts with time and region. Some honest observations that tend to hold:
Pick based on what you enjoy enough to practise for years. That beats chasing whatever seems hottest this month.
It's broader rather than harder. You need working knowledge of more areas, but less depth in each one than a specialist. Most full stack developers specialise more over time.
Most people start with frontend because the feedback is visual and immediate, then add backend. Starting with backend works too, especially if you enjoy logic and data.
Yes, and it's common. The fundamentals (programming, debugging, HTTP, Git) transfer directly. You'd mainly add a server language and database skills.
DNS lookups, TCP and TLS handshakes, HTTP requests, servers, and the browser's rendering pipeline. The whole journey of a web page, explained so it finally clicks.
Read →There are dozens of HTTP status codes, but about fifteen cover nearly everything. What each one means, when to return it, and the mix-ups (401 vs 403, 301 vs 302) that confuse everyone.
Read →A, AAAA, CNAME, MX, TXT and NS records in plain English, why DNS changes seem slow, and the troubleshooting commands that tell you what is really going on.
Read →