Introduction to Web Development
Learning Objectives
By the end of this page, you should be able to:
- Explain what web development is and distinguish it from web design or software development in general.
- Describe the client-server model and trace what happens between typing a URL and seeing a rendered page.
- Differentiate front-end, back-end, and full-stack development, including the tools and languages typical of each.
- Write and identify the roles of a minimal HTML document, a CSS rule, and a JavaScript DOM manipulation.
- Explain the roles of browsers, web servers, and the HTTP protocol in serving a web page.
- Identify common beginner misconceptions about "the web" versus "the internet" and about where code actually runs.
Quick Answer
Web development is the process of building and maintaining websites and web applications — everything a user sees and interacts with in a browser (front-end), plus the server logic, databases, and APIs that power it behind the scenes (back-end). It matters because the web is the primary way software reaches users today: browsers run on almost every device, so a single web application can serve billions of users without separate installs. Web development sits at the intersection of design, programming, networking, and security, and it's usually the first practical, visible skill CS students build — you write code and immediately see it render as a page.
Table of Contents
- What is Web Development?
- The Client-Server Model
- How a Web Page Actually Loads
- Key Components of Web Development
- HTML Basics
- CSS Basics
- JavaScript Basics
- A Brief Evolution of the Web
- Key Terms
- Common Mistakes
- Comparison and Connections
- Practice Questions
- FAQ
- Quick Revision
- Related Topics
What is Web Development?
Web development is the process of building websites and web applications that run over the internet and are accessed through a browser. It covers everything from structuring content and styling a page, to writing the interactive behavior a user sees, to building the servers, databases, and APIs that respond to requests behind the scenes.
It's useful to separate three terms people often blur together:
- Web design — how a page looks and feels (layout, typography, color, UX).
- Web development — how a page is built and made functional (code that renders content and handles logic).
- Software development — the broader discipline, of which web development is one specialization (alongside mobile, embedded, desktop, etc.).
A web developer might do only front-end work, only back-end work, or both. What unites all web development is that the end product is delivered over HTTP(S) and rendered by a browser (or consumed by another program via an API), rather than installed as a native executable.
The Client-Server Model
Almost everything in web development is an instance of the client-server model: one machine (the client) asks for something, and another machine (the server) provides it.
- The client is usually a web browser (Chrome, Firefox, Safari) running on the user's device. It sends requests and renders whatever comes back.
- The server is a machine (or cloud service) that stores the website's files or runs application logic, and sends responses back to clients.
This is a request-response relationship: the client always initiates, the server always responds. Understanding this one idea unlocks almost everything else in web development — why you need a server to "host" a site, why a database lives on the back-end and not in the browser, and why an API is just a server built to respond to other programs instead of humans-in-browsers.
How a Web Page Actually Loads
Walking through the diagram above step by step, when you type www.example.com into your browser and hit enter:
- DNS lookup — the browser doesn't know the server's location yet, only its domain name, so it asks a DNS (Domain Name System) server to translate
www.example.cominto an IP address (e.g.93.184.216.34). - Connection — the browser opens a TCP connection to that IP address, typically on port 443 (HTTPS) or 80 (HTTP), and performs a TLS handshake if it's HTTPS.
- Request — the browser sends an HTTP request, usually
GET /, asking for the homepage. - Server processing — the web server receives the request. For a static site it just reads a file off disk. For a dynamic site, it runs back-end code, which might query a database, then builds an HTML response.
- Response — the server sends back an HTTP response: a status code (like
200 OKor404 Not Found) plus a body containing HTML (and links to CSS/JS files). - Rendering — the browser parses the HTML into a DOM (Document Object Model) tree, fetches any linked CSS and JavaScript, applies styles, executes scripts, and paints pixels to the screen.
This entire round trip typically takes well under a second, but every layer here (DNS, TCP/TLS, HTTP, HTML parsing, CSS layout, JS execution) is itself a deep topic you'll meet again later in this module.
Key Components of Web Development
Web development is broadly split into three areas, distinguished by where the code runs and who/what it talks to.
Front-end Development
Front-end (a.k.a. client-side) development is everything that runs inside the user's browser. It's responsible for what the user sees and interacts with directly.
- HTML (HyperText Markup Language) — defines the structure and content of a page.
- CSS (Cascading Style Sheets) — controls layout, colors, spacing, and responsiveness.
- JavaScript — adds interactivity: form validation, animations, fetching data without reloading the page, etc.
Why it matters: no matter how good your back-end is, users only ever experience your product through the front-end. A slow or confusing UI loses users even if the server logic is flawless.
Common misunderstanding: students often think front-end code is "simple" because it's visual. In practice, modern front-end work (state management, accessibility, performance, cross-browser behavior) is a deep engineering discipline in its own right — see the "Front-end Frameworks" page later in this module.
Back-end Development
Back-end (a.k.a. server-side) development is everything that runs on the server, invisible to the user. It handles business logic, data storage, authentication, and anything that shouldn't be exposed to (or trusted from) the browser.
- Server-side languages/runtimes: Python (Django/Flask), Java (Spring), Ruby (Rails), PHP (Laravel), Node.js (Express).
- Databases: MySQL, PostgreSQL (relational); MongoDB, Redis (non-relational).
- APIs: the interface the back-end exposes so front-ends (or other services) can request data — see the "RESTful and GraphQL APIs" page.
Why it matters: anything that must be kept secret or consistent — passwords, payment logic, inventory counts — has to live on the back-end, because client-side (browser) code is visible and editable by anyone who opens dev tools.
Common misunderstanding: "the front-end validates the form, so the data must be safe." Client-side validation is a UX nicety, not a security boundary — the back-end must re-validate everything, because a malicious user can bypass the browser entirely and send raw requests.
Full-stack Development
A full-stack developer works across both front-end and back-end. This doesn't mean being equally expert at everything — most full-stack developers have a stronger side — but it does mean being able to build a feature end-to-end: design the database schema, write the API, and build the UI that consumes it.
Why it matters: small teams and startups often need generalists who can ship complete features without waiting on a specialist for each layer.
HTML Basics
HTML structures the content of a page using nested elements (tags). Every HTML document has a predictable skeleton:
<!DOCTYPE html>
<html>
<head>
<title>My First Web Page</title>
</head>
<body>
<h1>Welcome to Web Development</h1>
<p>This is an example of a simple HTML page.</p>
</body>
</html>
<!DOCTYPE html>tells the browser to render in standards mode (HTML5).<head>holds metadata (title, character encoding, linked CSS/JS) — nothing here is displayed directly on the page.<body>holds everything the user actually sees.
Real-world example: every link you click, every image you see, every form you submit on the web is represented as HTML elements: <a>, <img>, <form>, <input>. Browser "View Page Source" on any website shows you this structure directly.
CSS Basics
CSS separates presentation from structure. Instead of styling each HTML element by hand, you write rules that select elements and apply properties.
body {
background-color: lightblue;
}
h1 {
color: navy;
text-align: center;
}
.card {
border: 1px solid #ddd;
border-radius: 8px;
padding: 16px;
max-width: 400px;
}
A CSS rule has a selector (h1, .card) and a declaration block ({ property: value; }). Selectors can target tags, classes (.card), IDs (#header), or relationships (nav > a).
Why it matters: without CSS, every website would look like a plain, top-to-bottom stack of default black-on-white text — CSS is what makes the web visually usable and brand-consistent.
JavaScript Basics
JavaScript runs inside the browser and can read and modify the page after it has loaded — this is what makes pages feel "alive" instead of static documents.
// Change text content dynamically
document.getElementById("demo").innerHTML = "Hello, World!";
// React to a user event
document.querySelector("#myButton").addEventListener("click", () => {
alert("Button was clicked!");
});
// Fetch data from a server without reloading the page
fetch("https://api.example.com/users/1")
.then(response => response.json())
.then(data => console.log(data.name));
The first two examples manipulate the DOM (Document Object Model) — the browser's live, in-memory tree representation of the HTML. The third example, fetch, is how modern pages talk to back-end APIs asynchronously, which is the basis of single-page applications (SPAs).
Real-world example: when you "like" a post on social media and the counter updates instantly without the page reloading, that's JavaScript calling fetch (or similar) to talk to the back-end and then updating the DOM with the result.
A Brief Evolution of the Web
Understanding roughly how we got here helps explain why the field looks the way it does:
- Static web (1990s) — pages were plain HTML files; every click reloaded a whole new page from the server.
- Dynamic server-rendered web (late 1990s–2000s) — server-side scripting (PHP, ASP, JSP) generated HTML per request, enabling databases and personalization, but still full-page reloads.
- AJAX and interactive web (mid-2000s) — JavaScript could request data in the background (
XMLHttpRequest, laterfetch) and update parts of the page without reloading — Gmail and Google Maps popularized this. - Single-page applications / modern frameworks (2010s–present) — frameworks like React, Vue, and Angular let the front-end manage most of the UI logic in JavaScript, talking to back-ends purely through APIs (often REST or GraphQL).
This history explains why "front-end" and "back-end" have become such distinct specializations: the front-end grew from "a few style tags" into an application layer in its own right.
Key Terms
| Term | Definition | Context/Related Concepts |
|---|---|---|
| Client | The program requesting a resource, typically a web browser | Initiates requests in the client-server model |
| Server | A machine/program that stores resources or runs logic and responds to client requests | Hosts websites; runs back-end code |
| HTTP/HTTPS | HyperText Transfer Protocol (Secure) — the protocol browsers and servers use to exchange requests and responses | HTTPS adds TLS encryption over HTTP |
| DNS | Domain Name System — translates human-readable domain names into IP addresses | First step in loading any page |
| DOM | Document Object Model — the browser's in-memory tree representation of an HTML page | Manipulated by JavaScript to update pages dynamically |
| Front-end | Code that runs in the user's browser (HTML, CSS, JavaScript) | Also called client-side development |
| Back-end | Code that runs on the server (business logic, databases, APIs) | Also called server-side development |
| API | Application Programming Interface — a defined way for programs to request data/services from each other | Used by front-ends to talk to back-ends; see REST/GraphQL |
| Full-stack | A developer/skillset spanning both front-end and back-end | Builds features end-to-end |
| Static page | A page whose HTML is fixed and identical for every visitor | Contrast with dynamic, server-rendered pages |
| Dynamic page | A page generated or altered per request, often using a database | Powered by back-end logic |
| Web browser | Client software that requests, parses, and renders web pages | Chrome, Firefox, Safari, Edge |
| Web server | Software/hardware that stores site files or app logic and serves them on request | Apache, Nginx, Node.js servers |
| Rendering | The browser's process of turning HTML/CSS/JS into pixels on screen | Follows parsing and style/layout calculation |
Common Mistakes
-
Misconception 1: "The internet and the web are the same thing."
- Why it's wrong: The internet is the underlying global network of connected computers and infrastructure (cables, routers, protocols like TCP/IP). The web is just one service that runs on top of it, alongside email, file transfer, and other protocols.
- Correct explanation: Think of the internet as the road network and the web as one type of traffic (cars) that uses those roads — email and other services are different traffic using the same roads.
-
Misconception 2: "Front-end work is just making things look pretty, so it's less technical than back-end work."
- Why it's wrong: Modern front-end development involves state management, performance optimization, accessibility, security (e.g. preventing XSS), and handling dozens of browser/device combinations — it's a full engineering discipline, not just visual design.
- Correct explanation: Design (how it looks) and front-end development (how it's built and behaves) are related but distinct skills; a front-end developer needs strong programming skills, not just visual taste.
-
Misconception 3: "If I hide something in my JavaScript code, users can't see or change it."
- Why it's wrong: All front-end code — HTML, CSS, and JavaScript — is sent to and runs on the user's own machine, so anyone can view it via "View Source" or browser DevTools, and can even modify it before it runs.
- Correct explanation: Anything sensitive (API keys, business rules, permission checks, pricing logic) must be enforced on the back-end, where the code and data stay on a server the user cannot access directly.
Comparison and Connections
| Concept A | Concept B | Key Difference |
|---|---|---|
| Front-end development | Back-end development | Front-end runs in the browser and handles UI/UX; back-end runs on the server and handles logic, data, and security |
| Website | Web application | A website is mostly static/informational content (e.g. a blog); a web app is interactive with significant client/server logic (e.g. Gmail, online banking) — the line is blurry but usage/interactivity is the key signal |
| HTTP | HTTPS | HTTPS is HTTP layered with TLS encryption, so data in transit can't be read or tampered with by a third party; functionally the request/response model is identical |
| Client | Server | Client initiates requests and renders results; server stores/processes data and responds — one machine can act as a client to one service and a server to another |
| Web design | Web development | Design focuses on look, feel, and user experience; development focuses on building the functional code that implements that design |
| Static site | Dynamic site | A static site serves the same fixed HTML to every visitor; a dynamic site generates or customizes HTML per request, often from a database |
Practice Questions
Recall
-
What are the three main technologies used in front-end development, and what does each one do?
- Answer guidance: HTML structures content (elements like headings, paragraphs, links), CSS controls presentation (colors, layout, spacing, responsiveness), and JavaScript adds interactivity and dynamic behavior (event handling, DOM updates, network requests).
-
What is the DOM?
- Answer guidance: The Document Object Model is the browser's in-memory, tree-structured representation of an HTML page. JavaScript reads and modifies the DOM to change what's displayed without requiring a full page reload.
Understanding
-
Explain why client-side form validation alone is not sufficient for security.
- Answer guidance: Client-side validation runs in the user's browser and can be bypassed — a user can disable JavaScript, edit requests with browser DevTools, or send raw HTTP requests directly to the server (e.g. via curl or Postman), skipping the browser entirely. The server must independently validate and sanitize all incoming data because it cannot trust anything the client claims.
-
Why does a browser need to perform a DNS lookup before it can request a web page?
- Answer guidance: Browsers communicate over the network using IP addresses, not domain names. DNS acts as a directory that maps a human-friendly name (like
example.com) to the numeric IP address of the server hosting that site, so the browser knows where to actually send the request.
- Answer guidance: Browsers communicate over the network using IP addresses, not domain names. DNS acts as a directory that maps a human-friendly name (like
Application
-
You're building a to-do list app. Deciding whether "mark a task complete" should update a database, describe which part of the stack (front-end or back-end) is responsible for what, and why.
- Answer guidance: The front-end handles the click event and immediately updates the UI (e.g. strikes through the task) for responsiveness, then sends a request (e.g. via
fetch) to the back-end. The back-end receives the request, validates it (is this a real task, does this user own it), and updates the database — the actual persistent state must live on the back-end/database, since front-end state disappears when the page is refreshed or closed.
- Answer guidance: The front-end handles the click event and immediately updates the UI (e.g. strikes through the task) for responsiveness, then sends a request (e.g. via
-
A user reports that a website "loads forever" on a slow connection. At which stage(s) of the request-response cycle could the delay be happening, and how would you narrow it down?
- Answer guidance: Delay could occur during DNS resolution, the TCP/TLS handshake, server processing time (e.g. a slow database query), network transfer of the response, or browser rendering (large images, blocking JavaScript). You'd narrow it down using browser DevTools' Network tab, which times each phase separately (DNS, connect, TTFB, download, etc.).
Analysis
-
Compare a purely static website to a dynamic, database-backed website in terms of complexity, cost, and use cases.
- Answer guidance: A static site (plain HTML/CSS files) is cheap to host, fast, and simple to secure, but can't personalize content or handle user accounts — good for portfolios, documentation, marketing pages. A dynamic site requires a back-end, database, and server infrastructure, adding cost and complexity, but enables personalization, user accounts, and real-time data — necessary for things like e-commerce or social platforms.
-
Evaluate the claim: "A full-stack developer is always more valuable than a specialist front-end or back-end developer."
- Answer guidance: This isn't universally true — it depends on team size and project needs. Full-stack developers are valuable for small teams/startups needing end-to-end feature ownership with fewer people, but specialists typically go deeper on advanced problems (e.g. complex UI performance, database scaling) that full-stack generalists may lack the depth to solve. Value depends on context, not a fixed hierarchy of skill.
FAQ
Q: Do I need to learn back-end development to be a web developer? A: No — many developers specialize in only front-end or only back-end. "Web developer" is an umbrella term; you can build a career focused on just one side, though understanding the basics of both makes you more effective at either.
Q: What's the difference between a website and a web application? A: There's no hard technical boundary, but generally a website is mostly informational/static (a blog, a company homepage), while a web application is interactive and stateful, with significant logic running on both client and server (email clients, project management tools, online banking).
Q: Why do I need both a front-end and a back-end language — why can't JavaScript alone do everything? A: Actually, JavaScript can run on both sides now (Node.js lets it run on the server), so it's possible to use JavaScript everywhere. But you still conceptually need two separate pieces of logic: one running in the user's browser (front-end) and one running on a server you control (back-end) — the language choice and the client/server split are independent decisions.
Q: What should I learn first: HTML/CSS/JS or a back-end language? A: Start with HTML, CSS, and JavaScript. They're the foundation of everything visible on the web, require no server setup to experiment with, and give you fast feedback — you can open a file in a browser and immediately see results. Back-end concepts (servers, databases, APIs) build naturally on that foundation.
Q: Is web development the same as computer science? A: No. Web development is an applied specialization that uses programming, but it doesn't require deep knowledge of, say, algorithm complexity or operating systems theory to get started. That said, CS fundamentals (data structures, networking basics, security principles) make you a significantly stronger web developer as projects grow in complexity.
Q: How is a web app different from a mobile app? A: A web app runs inside a browser and is accessed via URL, requiring no installation and working across devices with a browser. A native mobile app is installed from an app store and built for a specific operating system (iOS/Android), often with deeper access to device hardware. Some apps ("hybrid" or "PWA") try to blend both approaches.
Quick Revision
- Web development = building websites/web apps; splits into front-end (browser-side) and back-end (server-side).
- Client-server model: the client (browser) always initiates a request; the server always responds.
- Loading a page: DNS lookup → TCP/TLS connection → HTTP request → server processing → HTTP response → browser parses/renders.
- Front-end trio: HTML (structure), CSS (presentation), JavaScript (behavior/interactivity).
- Back-end handles: business logic, databases, authentication, and anything that must stay hidden/secure from users.
- The DOM is the browser's live tree model of a page; JavaScript reads/writes it to update the UI dynamically.
- Full-stack developers work across both front-end and back-end.
- HTTPS = HTTP + TLS encryption; same request/response model, encrypted in transit.
- Client-side validation improves UX but is never a substitute for server-side validation/security.
- Internet ≠ web: the internet is the network infrastructure; the web is one service (HTTP-based) that runs on it.
- Static pages serve fixed HTML to everyone; dynamic pages generate/customize HTML per request, often via a database.
- The web evolved from static pages → server-rendered dynamic pages → AJAX → modern SPA frameworks (React/Vue/Angular).
Related Topics
Prerequisites
- Basic programming concepts (variables, functions, control flow)
- Fundamentals of computer networks (IP addresses, protocols)
Related Topics
- HTML and CSS Basics
- JavaScript and DOM Manipulation
- Web Security Essentials
Next Topics
- Front-end Frameworks
- Back-end Development
- RESTful and GraphQL APIs