Foundational Concepts

The Mental Models That Frame Everything

"The client is untrusted territory, the network is volatile, and the server and what you as a developer are what you can reasonably control."

CSE 135 — Full Overview

← → sections • ↓ more detail

Section 1The Internet vs. the Web

The Internet is infrastructure. The Web is one application running on it.

The Internet vs. the Web

Internet — global network of networks. Physical infrastructure: routers, cables, fiber, wireless. Since ~1969 (ARPANET).
Web — one application running on the Internet. Invented 1989 by Tim Berners-Lee. Three technologies: HTTP + HTML + URLs.
Other Internet apps: Email (SMTP), File Transfer (FTP/SFTP), Remote Shell (SSH), DNS, Streaming (RTSP/HLS)

The Internet existed ~20 years before the Web. When people say "the Internet" they usually mean "the Web." The distinction matters when you're building for it.

Read full section →

Section 2The Network Stack

HTTP is an application-layer protocol — it delegates delivery and routing to the layers below.

TCP/IP: 4 Layers

Layer	What	Question It Answers
Application	HTTP, HTTPS, FTP, SMTP, DNS	"What do I want to say?"
Transport	TCP (reliable) or UDP (fast)	"How do I ensure delivery?"
Internet	IP (IPv4 / IPv6)	"Where does it go?"
Link	Ethernet, WiFi, fiber	"How does it physically travel?"

HTTP doesn't care how packets travel. TCP guarantees delivery. IP handles routing. This separation of concerns is why HTTP from 1991 still works over WiFi and 5G.

Read full section →

Key Protocols

DNS — translates domain names to IP addresses. First thing that happens when you type a URL.
TCP — reliable, ordered delivery. Three-way handshake: SYN → SYN-ACK → ACK.
IP — addressing and routing. IPv4 (~4 billion addresses) vs IPv6 (effectively unlimited).

Client Server │── SYN ──────────────>│ │<── SYN-ACK ──────────│ │── ACK ──────────────>│ │ Connection ready │

Read full section →

Section 3Client-Server Architecture

The client asks, the server answers. The server never initiates.

Client-Server Architecture

Client initiates requests; server responds. Server never initiates.
Stateless: each request is independent. State must be managed explicitly (cookies, sessions, databases).
Scalable: because stateless, any server behind a load balancer can handle any request.

┌────────────┐ ┌────────────┐ │ Client │ ── Request ──> │ Server │ │ (asks) │ <── Response ── │ (answers) │ └────────────┘ └────────────┘

The request-response cycle is the heartbeat of the Web. Every page load, API call, and form submission follows this pattern.

Read full section →

Section 4What Happens When You Type a URL

~15 steps from keypress to pixels — the single most important mental model in this course.

~15 Steps in 6 Phases

Phase	Steps	What Happens
Resolution	1–2	URL parsing, DNS lookup
Connection	3–4	TCP handshake, TLS handshake (HTTPS)
Request	5–6	HTTP request sent, server routes it
Processing	7–8	App code runs, database queries
Response	9–10	HTTP response sent back via TCP/IP
Rendering	11–15	HTML parsing, CSS, JS, layout, paint, display

This is the single most important mental model in the course. Every topic connects to one of these phases.

Read full section →

How This Maps to the Course

Phase	Where	Course Connection
Resolution	Client + DNS	URL Overview
Connection	Client ↔ Server	Network Stack (S2)
Request / Response	Client ↔ Server	HTTP Overview
Processing	Server	Execution Models (S17)
Rendering	Browser	Architecture Generations (S19)

Read full section →

Section 5The Three Protocol Pillars

HTTP + HTML + URLs — everything else builds on these three.

The Three Protocol Pillars of the Web

Pillar	Role	Analogy
HTTP	The protocol — how client and server communicate	The postal system
HTML	The content — what gets displayed	The letter itself
URLs	The addresses — where things are	The mailing address

Everything else — CSS, JavaScript, databases, frameworks, APIs — builds on top of these three.

Jumping over the foundational fence is dangerous. Reaching for higher-level abstractions without understanding the foundation leads to problems in maintainability, performance, and security.

Read full section →

Section 6The Web's Resource Model

The web is a system of named, addressable, linked resources.

1 URL = 1 Resource • Addressability

A resource is any concept worth naming: a document, an image, a user profile, a search result set, an API endpoint.
The URL is its stable, globally unique address — the web's fundamental unit of organization.

Anything with a URL can be:

Linked to — another page can point to it
Bookmarked — saved for later
Shared — pasted in email, chat, social media
Cached — stored for faster retrieval
Indexed — discovered by search engines

SPAs that change views without updating the URL break the resource model. Users lose bookmarking, sharing, and back-button navigation. Use the History API or Navigation API to preserve addressability.

Read full section →

Resources vs. Representations • Hypermedia

A resource is the concept. A representation is the format delivered.

Resource: /products/42 │ ├── Accept: text/html → HTML page ├── Accept: application/json → JSON data ├── Accept: application/pdf → PDF document │ └── HTTP methods on the resource: GET = retrieve, PUT = replace, DELETE = remove, POST = submit

The client signals preference via Accept header (including Accept-Language). The server responds with Content-Type. This is content negotiation.

Hypermedia — links as navigation. HTML's <a href> connects resources into a traversable graph. The link is arguably the web's most important invention.

Read full section →

Section 7The Five Pillars of Web Technology

Architecture, Coding, Hosting, Design, Content/Visuals — where does each topic fit?

Five Pillars of Web Technology

Pillar	What It Covers	This Course?
Architecture	Client-server, REST, MVC, HTTP, TCP/IP	Primary focus
Coding	PHP, Node.js, Python, SQL, JavaScript, HTML	Primary focus
Hosting	Apache, Nginx, Linux, Docker, cloud, DNS	Primary focus
Design	CSS, responsive design, UX, accessibility	Mentioned
Content/Visuals	Images, video, typography, data viz	Mentioned

Architecture, Coding, Hosting are this course. Design and Visuals are CSE 134B. A beautiful CSS animation doesn't matter if the server returns a 500 error.

Read full section →

Section 8Three Participant Groups

Developers, Owners, and Users shape every technology decision with different priorities.

Three Participant Groups

Group	Cares About	Common Conflict
Developers	Clean code, modern tools, DX, interesting problems	May over-engineer or choose tools for resume appeal
Owners	Cost, time-to-market, reliability, compliance, ROI	May cut corners or resist upgrades
Users	Speed, ease of use, accessibility, privacy	Rarely consulted; needs assumed not measured

Technology choices are never purely technical. A developer wants React, the business wants WordPress, the user just wants the page to load fast. Understanding these tensions helps you make — and argue for — better decisions.

Read full section →

Section 9Standards Bodies & the Open Web

The web runs on open standards that anyone can implement. No single company owns it.

Who Maintains What

Domain	Standard	Body
Transport	HTTP, TLS, TCP, DNS	IETF (RFCs)
Markup	HTML Living Standard	WHATWG
Styling	CSS	W3C
Scripting	ECMAScript (JS)	TC39
Accessibility	WCAG	W3C WAI
Encoding	Unicode / UTF-8	Unicode Consortium

IETF = plumbing. WHATWG = markup. W3C = styling + accessibility. TC39 = language. Together = the platform.

Read full section →

Why Open Standards Matter

Interoperability — any browser renders HTML, any server speaks HTTP
No vendor lock-in — shared protocols, not proprietary platforms
Longevity — HTTP from 1991 still works. React from 2015 has had breaking changes.
Permissionless innovation — anyone can build a browser, server, or framework

Prefer protocols over platforms. Git over GitHub. HTTP over any framework. SQL over any ORM. Knowledge of standards compounds over decades; platform knowledge is on borrowed time.

Read full section →

The Living Standard & the XHTML Lesson

HTML used to be versioned: 2.0, 4.01, XHTML 1.0, HTML5. HTML5 was the last version number.
WHATWG now maintains a continuously evolving "Living Standard."
New features added when ≥2 browsers implement them. Spec reflects reality.

XHTML is a cautionary tale. The W3C demanded XML strictness. Developers didn't want parsing errors killing pages. Browsers had taught users to expect tolerance. The Living Standard embraced pragmatism. Standards must serve practitioners, not the other way around.

Read full section →

Section 10UX vs. DX: The Eternal Tension

What makes the developer's job easier vs. what makes the user's experience better.

UX vs. DX

Pure DX Pure UX ◀━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶ 2MB JS framework Hybrid / Progressive Vanilla Hot reload Enhancement Zero JS Component library Server render + enhance Works everywhere Great for developers Good for both Great for users

DX Choice	User Impact
2 MB JS bundle for a blog	Slow load, broken without JS, drains battery
Client-side rendering for static content	Blank page until JS loads, poor SEO
CSS-in-JS libraries	Larger bundle, slower rendering

When DX and UX conflict, UX should always win. Your users didn't choose your framework. They care about speed, accessibility, and getting their task done.

Read full section →

Section 11Client-Server Trade-offs

Where should logic run — in the browser or on the server?

Thick Client vs. Thin Client

Aspect	Thick Client (Browser)	Thin Client (Server)
Examples	React SPA, Gmail, Docs	Wikipedia, Craigslist
Initial load	Slow (large JS bundle)	Fast (ready HTML)
Works without JS	No	Yes
SEO	Difficult	Easy
Security	Logic exposed in client	Logic on server
Complexity	High	Low

Read full section →

The Trust Boundary

Client = untrusted. Users can modify any HTML, CSS, or JavaScript. DevTools make this trivial.
Network = volatile and hostile. Without HTTPS, anyone can read or modify data in transit.
Server = where truth lives. All validation, authorization, and business logic must run here.

Validate on the client for usability. Validate on the server for security. Never only on the client.

Read full section →

Section 12The Layered Model

Four stacked layers, each building on the one below.

Content → Structure → Presentation → Interactivity

┌─────────────────────────────────────────────┐ │ Interactivity │ JavaScript, WASM, server-side code │ (Behavior) │ "What happens when you interact" ├─────────────────────────────────────────────┤ │ Presentation │ CSS, fonts, images, media │ (Look & Feel) │ "How it looks" ├─────────────────────────────────────────────┤ │ Structure │ HTML elements, DOM, components │ (Organization) │ "How it's organized" ├─────────────────────────────────────────────┤ │ Content │ Text, data (JSON, XML, CSV) │ (Information) │ "What it says" └─────────────────────────────────────────────┘

Each layer depends on the one below. Remove structure, and presentation and interactivity fail.
Maps directly to progressive enhancement (S18): start with content, add structure, layer presentation, enhance with interactivity.
The layers reveal dependencies — if you build interactivity without solid content and structure beneath it, you're building on sand.

These layers are not rigid walls — they interact. CSS creates visual interactivity (:hover, transitions). HTML has built-in interactivity (<details>, <dialog>). But layered dependencies help you reason about what breaks when a layer fails.

Read full section →

Section 13Sites vs. Apps

Content-dominant sites and interaction-dominant apps need different architectures.

The Spectrum

Sites Apps ◀━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶ Content-dominant Mixed Interaction-dominant Blog, docs, news E-commerce, social Gmail, Figma, trading HTML-first Hybrid approach JS-first Read-mostly Read/write Task-oriented

Content-dominant = site. Don't use heavy programming to manage it unless at scale — you're likely overcomplicating it.
Task/interaction-based = app. Bending traditional web tech for app-like behavior can be problematic, though it's tried and true.
The degree of site-ness and app-ness is not absolute. Apps have site-like features. Sites have interactive elements.

Read full section →

Architecture Implications

Characteristic	Site-like	App-like
Primary content	Documents, articles, media	Interactive features, real-time data
Navigation model	Page-to-page (1 URL = 1 page)	State-based (views within a shell)
JavaScript role	Enhancement (optional)	Essential (won't work without it)
Rendering approach	Server-side / static	Client-side / hybrid
SEO importance	High	Often low (behind auth)
Caching strategy	Aggressive (content rarely changes)	Complex (real-time data)

Before reaching for a framework, ask: is this a site or an app? A "static dynamic site" — a database-driven site delivering the same content to every visitor — is needless complexity.

Read full section →

Section 14HTML Fundamentals

HTML is the content layer of the Web — structure, meaning, and remarkable browser forgiveness.

HTML vs. XHTML: The Strictness Spectrum

Feature	HTML5	XHTML
Tag case	`<DIV>` = `<div>`	Must be lowercase
Closing tags	`<br>` (optional close)	Must self-close: `<br />`
Attributes	`checked` (boolean OK)	`checked="checked"`
Error handling	Browser guesses & recovers	Parser stops on first error

Browser forgiveness is a feature. If browsers rejected malformed HTML, half the early web would have been blank pages. HTML5 codified these error-recovery rules into the specification.

Read full section →

Section 15Forms: Data to the Server

The original mechanism for sending data from client to server — and still foundational.

Forms: How Data Gets to the Server

GET Forms

Data appended to URL as query parameters
/search?q=javascript
Visible, bookmarkable, cacheable
Use for: searches, filters

POST Forms

Data sent in HTTP request body
Not visible in URL
Not bookmarkable or cacheable
Use for: creating, updating data

Forms work without JavaScript. Before fetch(), before XMLHttpRequest — forms were the only way to send data. Progressive enhancement starts with forms.

Read full section →

Section 16Client-Side Security Is an Illusion

Every client-side "security" measure is trivially bypassable.

Everything Client-Side Is Bypassable

Password fields — hides characters on screen, but GET sends them in the URL (visible in history, logs, Referer header)
Hidden fields — invisible on page, but visible and editable in DevTools
maxlength, readonly, disabled — all trivially removed via DevTools. UX conveniences, not security.
localStorage / sessionStorage — readable by any script on the page, including third-party scripts you invited in

Read full section →

Data Collection Zones

Zone	Who Controls It	Trust Level
Client	User (and extensions/scripts)	Zero — can modify anything
Transit	ISPs, routers, proxies	HTTPS encrypts; HTTP is plaintext
Server	You (developer/operator)	Trusted — validation lives here
Third-party	Someone else	You're trusting their code in your page

Never trust the client. Every form input, cookie, and piece of client state must be validated and sanitized on the server. The client is fundamentally untrusted territory.

Read full section →

Section 17Server-Side & Client-Side Execution Models

How code runs shapes why different languages feel different to deploy.

Server-Side Models

Model	Examples	Key Trait
Fork/Exec (CGI)	CGI scripts, early PHP	New process per request. Simple but expensive.
Server-Side Scripting	PHP, ColdFusion, Classic ASP	Interpreter in server process. Drop a file, it runs.
Embedded Container	Java Servlets (Tomcat/Jetty)	Runtime inside server. App stays loaded in memory.
Embedded Native	Apache Modules, ISAPI	C/C++ compiled into server. Max performance, min portability.
Code-as-Server	Node.js, Deno, Bun	Your code is the server. You own the lifecycle.

The model shapes the DX. PHP = drop a file. Node = write the server. Java = deploy to container. Understanding the model explains why different languages feel different to deploy.

Read full section →

Client-Side Models

Model	Examples	Status
Helpers	External apps (Acrobat, Winzip)	Still used for MIME types
Client-Side Scripting	JavaScript, WASM	The winner
Applets	Java Applets	Dead
Plug-ins	ActiveX, Flash, NaCl	Dead
Native Wrapping Web View	Electron, Capacitor	Active (compromise)
Native Code Calling Web	Swift/Java using HTTP	Active

JavaScript won. The graveyard: Applets, ActiveX, Flash, NaCl. WASM extends JS into high-performance territory. The web view pattern (Electron) is today's compromise: write web tech, wrap it in a native shell.

Read full section →

Section 18Progressive Enhancement & Graceful Degradation

Two competing philosophies — the choice reveals whether you're building a site or an app.

Two Philosophies, Two Starting Points

Progressive Enhancement

┌─────────────────┐ │ JavaScript │ Layer 3 │ (Interactions) │ ┌────┴─────────────────┴────┐ │ CSS │ Layer 2 │ (Presentation) │ ┌┴───────────────────────────┴┐ │ HTML │ Layer 1 │ (Content) ↑ BUILD UP │ └─────────────────────────────┘

Graceful Degradation

┌─────────────────────────────┐ │ Full Application │ Start full │ (JS+CSS+HTML) ↓ DEGRADE │ └┬───────────────────────────┬┘ │ Reduced functionality │ └────┬─────────────────┬────┘ │ Minimal fallback│ └──────────────────┘

PE = natural fit for sites. Content is king; each layer is optional. Page works at every level.
GD = natural fit for apps. The app requires JS and specific APIs. Goal: fail gracefully when requirements aren't met.

Read full section →

The Tension

Both philosophies appear in every execution. Code, markup, and style exist in every web page. You can loosely couple them, but full decoupling is impossible.
Practitioner comfort drives choice: markup-first developers lean toward PE; code-first developers lean toward GD.
Right approach depends on: the volume of each layer, the type of problem (site vs. app), and the practitioners involved.

"Is your markup in my code, or is your code in my markup?" Template-heavy server-side pages put code in markup (PHP, JSP). JavaScript-heavy SPAs put markup in code (JSX, template literals). Neither is universally right — the answer depends on what you're building.

Read full section →

Section 19Web Architecture Generations

The biggest architectural decision: who builds the HTML that the user sees?

Where Does Rendering Happen?

Aspect	SSR	CSR	Hybrid
First load	Fast (HTML ready)	Slow (JS loads first)	Fast
Navigation	Slow (full reload)	Fast (client routing)	Can be fast
SEO	Excellent	Poor	Excellent
Without JS	Works	Blank page	Works (degraded)
Complexity	Low	High	Very high

Read full section →

The Generational Evolution

Generation	Era	Approach
Gen 1: Server-Side	~1993–1999	Thin client, server renders everything. 1 URL = 1 page.
Gen 1.5: Enhanced	~1997–2004	Client-side validation, DHTML effects. Server still controls flow.
Gen 2: Ajax	~2005–2012	XMLHttpRequest, in-place updates. Broke then fixed 1 URL = 1 resource.
Gen 3: Native Apps	~2008–present	iOS/Android. Native perf, but platform lock-in.
Gen 4: PWAs	~2015–present	Offline-first, service workers. Speed of native + web distribution.
Current: SSR+Hydration	~2018–present	Static snapshot fast, then hydrate with JS. Best of both, complexity is the cost.

All generations remain legitimate. Form follows function — the right approach reveals itself from the problem, not from trends.

Read full section →

Form Follows Function & Maturity

The decision process:

Is this a site or an app? — Content-dominant or interaction-dominant?
What degree of dynamism does it need? — Static content? Real-time data? User-generated content?
What's the context? — Audience, constraints, team capabilities, business requirements.

The wrong choice in either direction — over-engineering a brochure site or under-engineering a complex app — creates unnecessary pain.

Mature + safe = boring but reliable. Immature + risky = exciting but may not survive. For production, boring wins. All frameworks eventually derive down to the vanilla platform — start there.

Read full section →

Section 20The Volume Problem

The web toolbox is too vast to master. The better strategy: understand how it fits together.

Mastery vs. Understanding

Client-Side Network Server-Side ┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐ │ Storage: │ │ │ │ Code Execution: │ │ LocalStorage │ HTTP Req │ HTTP │ │ PHP, Java, JS │ │ Cookies │ ───────> │ Request/ │ │ Ruby, Perl, ... │ │ │ │ Response │ │ │ │ Code Execution: │ <─────── │ │ │ Storage: │ │ JavaScript │ HTTP Res │ Content │ │ Database │ │ WASM │ │ Types: │ │ Session Store │ │ │ │ HTML, CSS, │ │ File System │ │ Display: │ │ JS, JSON, │ │ │ │ HTML, CSS, JS │ │ Images... │ │ File Serving: │ │ Images, Fonts │ │ │ │ HTML, CSS, JS │ │ │ │ │ │ Images, Fonts │ │ Web Browser │ │ │ │ Web Server │ └──────────────────┘ └──────────────┘ └──────────────────┘

The web toolbox is too vast to master. HTML, CSS, JS, frameworks, servers, databases, APIs, cloud — and each interacts with others.
The joints between technologies — not the individual parts — are where trouble happens. A well-understood simple system beats a poorly understood complex one.
The better strategy: understand everything at a conceptual level and go deep where your work demands it.

Your value as an engineer comes from understanding how systems fit together, not from knowing the syntax of every framework. Frameworks come and go. The ability to reason about architecture, trade-offs, and failure modes compounds over a career.

Read full section →

Section 21Summary

Key takeaways from all 21 sections.

Key Takeaways

Internet ≠ Web — the Web runs on the Internet
HTTP + HTML + URLs = the three protocol pillars
1 URL = 1 resource — addressability is the web's superpower
Open standards (IETF, WHATWG, W3C, TC39) — protocols persist, platforms pivot
Client = untrusted, network = volatile, server = truth
UX > DX when they conflict
Content → Structure → Presentation → Interactivity — layers build on each other
Site or app? — the answer drives architecture
Validate on server for security; client validation is for usability only
PE vs GD — build up from HTML or build full and handle failure
Execution models — CGI → scripting → containers → code-as-server
Understand, don't master — the joints between technologies are where trouble happens
Understand foundations before reaching for abstractions

Read the full Foundational Concepts overview → | Review Questions →