You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
The web page in front of you is not a single thing the server simply "has". It is assembled — its structure written in one language, its appearance in a second, its behaviour in a third, and very often its content fetched from a database and stitched together by a program running on a machine you will never see. Understanding web technologies means understanding this division of labour: which language does which job, where each piece of work happens (in your browser or on the server), and why that placement matters enormously for both performance and security.
At A-Level you must be able to describe the distinct roles of HTML, CSS and JavaScript; explain the crucial difference between client-side and server-side processing and justify when each is appropriate; and explain how search engines discover, index and rank pages, including the conceptual idea behind the PageRank algorithm. The single most examined discriminator in this topic is the client-side/server-side distinction — and especially why security-critical work must never be trusted to the client.
This lesson addresses the Communication and networking area of the AQA A-Level Computer Science (7517) specification, specifically the web-technologies content. It covers the roles of HTML, CSS and JavaScript in building web pages; the distinction between client-side processing (in the browser) and server-side processing (on the web server) and the trade-offs between them; the operation of search engines, including web crawlers, indexing and ranking; and the conceptual basis of the PageRank algorithm. It builds directly on the protocols content (HTTP/HTTPS request–response) and the Internet and World Wide Web content, and links to the programming fundamentals and databases areas of the specification.
Before examining each language, fix the overall flow in mind, because every later idea slots into it:
sequenceDiagram
participant U as User
participant B as Browser (client)
participant DNS as DNS
participant S as Web server
participant DB as Database
U->>B: Enter URL / click link
B->>DNS: Resolve domain to IP address
DNS-->>B: IP address
B->>S: HTTP/HTTPS request (GET /products?cat=shoes)
S->>DB: Server-side script queries database
DB-->>S: Result rows
S->>S: Script builds the HTML response
S-->>B: HTTP response (HTML + links to CSS, JS)
B->>S: Further requests for CSS, JS, images
S-->>B: Those resources
B->>B: Render: parse HTML, apply CSS, run JS
Two ideas in this diagram do almost all the conceptual work of the lesson. First, the server side (everything to the right of the browser) does work the user can neither see nor alter — querying the database, building the HTML. Second, the client side (the browser) receives the finished resources and renders them, running any JavaScript locally on the user's own machine. Whether a given task happens on the left or the right of this picture is the recurring question this lesson keeps returning to.
HTML (HyperText Markup Language) is a markup language — not a programming language — that defines the structure and content of a page. It marks up text to say "this is a heading", "this is a paragraph", "this is a link", using elements delimited by tags.
| Concept | Detail |
|---|---|
| Tag | A keyword in angle brackets, usually paired: <p> ... </p> |
| Element | A complete unit: opening tag, content and closing tag, e.g. <h1>Title</h1> |
| Attribute | Extra information inside the opening tag: <a href="page.html"> |
| Nesting | Elements contain other elements, forming a tree |
| DOM | The Document Object Model — the in-memory tree the browser builds from the HTML, which JavaScript can then manipulate |
A minimal but complete page shows the standard skeleton — note how the <head> holds metadata and links, while the <body> holds visible content, and how CSS and JavaScript are linked in from separate files rather than written inline:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Shoe Shop</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<h1>Our Shoes</h1>
<p>Browse the <a href="/products/shoes">latest range</a>.</p>
<img src="trainer.jpg" alt="A blue running shoe">
<script src="app.js"></script>
</body>
</html>
The single most important property of HTML to grasp is that it describes structure and meaning, not appearance. An <h1> says "this is the most important heading" — it does not say "make this big and bold". Deciding how an <h1> actually looks is the job of CSS. This separation of concerns — structure in HTML, presentation in CSS, behaviour in JavaScript — is the central design principle of the modern web, and the reason the same HTML can be re-skinned with a different stylesheet without touching the content.
Forms are how a user sends data to the server, so they sit at the boundary between client and server:
<form action="/login" method="POST">
<label for="user">Username:</label>
<input type="text" id="user" name="username">
<label for="pw">Password:</label>
<input type="password" id="pw" name="password">
<button type="submit">Log in</button>
</form>
GET appends the data to the URL as a query string (visible, bookmarkable, length-limited); POST puts it in the request body (not shown in the URL, suitable for sensitive or large data). A login uses POST so the password never appears in the URL or browser history.CSS (Cascading Style Sheets) controls the visual presentation of HTML elements — colour, font, size, spacing, layout and how the page adapts to different screen sizes. It works by selecting elements and applying declarations (property–value pairs) to them:
h1 {
color: navy;
font-size: 2rem;
}
.product {
border: 1px solid grey;
padding: 8px;
}
| Concept | Detail |
|---|---|
| Selector | Chooses which elements a rule applies to — by tag (h1), class (.product) or id (#header) |
| Declaration | A property: value; pair, e.g. color: navy; |
| The cascade | When several rules target the same element, specificity and source order decide which wins |
| Responsive design | Media queries apply different rules at different screen widths, so one page works on phone and desktop |
CSS can be applied three ways, in increasing order of good practice:
| Method | How | Drawback / benefit |
|---|---|---|
| Inline | style attribute on the element: <p style="color:red"> | Mixes presentation into structure; hard to maintain |
| Internal | A <style> block in the <head> | Styles one page only; cannot be shared |
| External | A separate .css file linked with <link> | Preferred — one stylesheet styles the whole site and is cached by the browser |
The external approach is best precisely because it enforces separation of concerns: change one file and every page restyles, and the browser caches the stylesheet so it is not re-downloaded for every page — a real performance gain that links this topic back to HTTP caching.
JavaScript is a full programming language that runs inside the browser, on the user's machine. It makes pages interactive and dynamic by manipulating the DOM, responding to events and exchanging data with servers without reloading the page.
| Capability | Example |
|---|---|
| Manipulate the DOM | Show/hide elements, change text, insert new nodes |
| Handle events | React to clicks, key presses, mouse movement, form submission |
| Validate input | Check a field is filled / well-formed before submitting — instant feedback |
| Animate / update the UI | Transitions, dynamic charts, live counters |
| Fetch data asynchronously | Use the Fetch API / AJAX to request data and update part of the page without a full reload |
A small, realistic example of client-side form validation — note that it improves the experience but, as we will stress below, can never be trusted for security:
const form = document.querySelector('#login');
form.addEventListener('submit', (event) => {
const password = document.querySelector('#pw').value;
if (password.length < 8) {
event.preventDefault(); // stop the form submitting
showMessage('Password must be at least 8 characters.');
}
});
Because this code runs on the user's own computer, the user can read it, change it, or disable JavaScript entirely — a fact that drives the entire client-side/server-side discussion that follows.
This distinction is the most heavily examined idea in the lesson, so it deserves careful treatment. Where a piece of processing happens determines what it can access, how fast it feels, and crucially whether it can be trusted.
| Aspect | Client-side (in the browser) | Server-side (on the web server) |
|---|---|---|
| Where it runs | The user's own device | The web server you control |
| Language(s) | JavaScript (primarily) | PHP, Python, Node.js, Java, C#, Ruby, ... |
| Can access | The DOM, browser APIs, what is already in the page | Databases, the file system, secret keys, other server resources |
| Visible to user? | Yes — source is downloaded and can be read/altered | No — the user sees only the output, never the code or data |
| Trustworthy for security? | No — the user controls it | Yes — the user cannot tamper with it |
| Reduces server load? | Yes — work done on the client | No — work done on the server |
| Reduces network traffic? | Yes — avoids round-trips (e.g. instant validation) | No — needs a request/response |
| Typical uses | Validation for UX, animations, dynamic UI, fetching data | Authentication, database queries, payment processing, generating HTML |
The trade-off cuts both ways. Client-side processing makes a page feel fast and responsive and offloads work from the server — validating a form field instantly, animating a menu, or updating a list without a page reload. But anything done client-side is fundamentally untrusted: the user can open developer tools, edit the JavaScript, forge requests with a tool like curl, or simply turn JavaScript off. Server-side processing is the opposite: it can reach the database and secret keys, its code is invisible and unalterable by the user, and so it is the only place security-critical decisions can safely be made — but every server-side action costs a network round-trip and consumes server resources.
The classic exam question is: "Why should form validation be performed on both the client side and the server side?" The answer turns on the trust distinction:
The rule to remember: client-side validation is a convenience that can be bypassed; server-side validation is the real defence and must never be omitted. Trusting client-side checks for security is one of the most exploited mistakes in real web applications — it is the doorway to attacks such as SQL injection, studied in the network-security lesson.
Server-side scripts run on the web server before the response is sent, and produce the HTML (or JSON) the browser receives. Their privileged position lets them do things the client never can:
| Language | Common frameworks |
|---|---|
| PHP | Laravel, WordPress |
| Python | Django, Flask |
| JavaScript (Node.js) | Express, Next.js |
| Java | Spring Boot |
| C# | ASP.NET |
| Ruby | Ruby on Rails |
A concrete server-side flow — note that the database query and HTML generation happen entirely on the server, invisible to the user:
sequenceDiagram
participant B as Browser (client)
participant S as Web server
participant DB as Database
B->>S: GET /products?category=shoes
S->>S: Server-side script reads the 'category' parameter
S->>DB: SELECT * FROM products WHERE category = 'shoes'
DB-->>S: Matching rows
S->>S: Script loops over rows, builds HTML
S-->>B: 200 OK + generated HTML
B->>B: Render the page
A useful framing is the difference between static and dynamic content. A static page is the same file for every visitor — the server simply returns it unchanged. A dynamic page is built per request by a server-side script, often from database data, so two users (or the same user at different times) may see different content. A shop's product page is dynamic: the prices, stock levels and recommendations are pulled live from a database. This is why server-side scripting and databases are so tightly linked — most "real" web applications are dynamic.
Modern web applications increasingly use APIs (Application Programming Interfaces) so the client-side JavaScript can fetch just the data it needs and update part of the page, rather than reloading the whole page:
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.