For every topic in this section, trace one request through the full chain: client, network, server, and data storage, identifying at each stage where structure, presentation, behaviour, validation, and security are actually handled. Web development is never only page appearance — it equally involves requirements, accessibility, testing, performance, deployment, maintenance, and secure interaction between every one of these components.
A. Web Engineering, Architecture, and HTML
Web engineering applies disciplined software-engineering practices specifically to web applications, which must combine content, navigation, user interaction, data, networking, and rapid ongoing change all together. Requirements here include both functional behaviour and non-functional qualities such as security, accessibility, performance, and availability. Example: “a user can submit an application” is a functional requirement, while “the form works correctly with keyboard-only navigation” is a non-functional, accessibility-specific requirement — both matter, and treating only the functional half as “the requirements” misses genuinely important qualities the system must have.
HTML gives web content its structure and semantic meaning. Web architecture defines how clients, servers, application logic, services, and data stores all cooperate together. Client-server architecture separates the requester (client) from the service provider (server); layered or n-tier designs further split presentation, business logic, and data access into distinct, independently maintainable layers. Example: a browser sends an HTTP request to a web server; the server’s application logic may then query a database and return HTML or structured data back to the client — this simple request-response cycle is the foundation nearly every web interaction builds on. Separating these layers cleanly improves maintainability (each layer can change independently), security (a compromised presentation layer doesn’t automatically expose data-access logic), and testing (each layer can be tested in isolation).
B. CSS, JavaScript, and the DOM
Cascading Style Sheets (CSS) control presentation — layout, spacing, typography, and responsive appearance across different screen sizes; JavaScript adds programmable behaviour, running both in the browser and, increasingly, in other environments. CSS style rules select specific elements and apply properties to them; JavaScript uses variables, operators, functions, and event handlers (code that runs in response to a specific user action, like a click). Example: a button’s visual appearance can be controlled entirely by CSS style rules, while a separate JavaScript click handler validates user input or requests data from a server — keeping structure (HTML), presentation (CSS), and behaviour (JavaScript) conceptually separate, even though real applications inevitably connect all three together, is a foundational web-development discipline worth internalizing.
The Document Object Model (DOM) represents a loaded document as a tree of objects and nodes that a running program can read and modify. JavaScript commonly uses the DOM to change a page’s content dynamically after some user event, without needing to reload the entire page from the server. Example: a script can locate a specific paragraph node in the DOM and change its displayed text directly, without reloading the whole static page around it. An API (application programming interface) defines how separate software components communicate with each other; modern web APIs commonly use HTTP as their transport and exchange structured data (commonly JSON) as requests and responses.
C. Client-Side vs Server-Side Programming, and the Development Process
Client-side code runs mainly inside the user’s browser; server-side code runs on a server and handles protected logic, data access, and server-side resources that should never be exposed directly to the client. A critical security principle here: security-sensitive validation must never rely solely on client-side checks, because a user can always bypass or disable client-side code entirely. Example: a browser can usefully check whether an email field looks superficially valid as the user types, but the server must still independently validate that same input before ever writing it to a database — client-side validation is a convenience for legitimate users, never a security boundary. The request flow worth internalizing is: request, then server-side logic, then database, then response back to the client.
A web project’s development process moves from goals and requirements through information and interaction design, implementation, testing, deployment, and continuous improvement afterward. Deployment publishes the application into its actual operational environment; promotion helps its intended users actually discover and find it; ongoing operations includes monitoring, backups, updates, and incident response when something inevitably goes wrong. Example: a site is not genuinely “finished” the moment its code is uploaded — domains, security certificates, server configuration, logging, backups, and monitoring all separately determine whether it actually works reliably for real users over time, well beyond the initial code deployment itself.
D. Web Application Quality Issues
A genuinely useful web application must work for real users, remain fast enough to be usable, resist attacks, and stay maintainable well after its initial launch — these are four separate, and separately testable, quality dimensions. Accessibility includes keyboard-only access, meaningful semantic structure, and perceivable content for users with different abilities. Testing covers functionality (does it do what it should), compatibility (does it work across different browsers and devices), and security (can it resist deliberate attack). Performance involves network transfer time, browser rendering time, and server/database processing cost, all contributing together to how fast the application actually feels to a real user. Security includes authentication, authorization, input validation (never trusting data from the client, as covered in Section C), secure session management, and staying current with security updates. Example: a visually attractive, well-designed form is still genuinely defective if a keyboard-only user cannot actually reach and use its controls, or if unvalidated user input can be crafted to alter an underlying database query — visual polish and genuine quality are not the same thing. A reliable ordered checklist for evaluating any web application: accessibility, then functional testing, then performance, then security, then logging and monitoring, then backup and recovery, then ongoing maintenance.
Web Technologies key takeaways: every web topic can be understood by tracing one request through client, network, server, and data storage, and identifying exactly where structure, presentation, behaviour, validation, and security each get handled along that path. HTML, CSS, and JavaScript separately handle structure, presentation, and behaviour, and this separation of concerns is worth preserving even in real, more tangled applications. The DOM lets a running program treat a document as manipulable objects rather than static text. Client-side validation is a convenience, never a security boundary — genuine validation always happens on the server. A web application’s quality spans accessibility, functionality, performance, and security together, and none of these four is optional or substitutable for the others.
Computer Science — High-Yield Complexity & Concept Reference
- Linear search: O(n); binary search on sorted random-access data: O(log n)
- Bubble sort: O(n squared) in its basic form; merge sort: O(n log n); heap sort: O(n log n); quick sort: average O(n log n), worst-case O(n squared) for common implementations
- Stack = LIFO; Queue = FIFO; Hash table maps key to bucket/index; Tree = hierarchy; Graph = general network
- TCP = reliable, ordered transport stream; UDP = connectionless datagrams, lower overhead, no delivery guarantee
- ACID = Atomicity, Consistency, Isolation, Durability
- CIA security goals = Confidentiality, Integrity, Availability
- OSI layers, in order: Physical, Data Link, Network, Transport, Session, Presentation, Application
- Compilation chain, in order: lexical analysis, syntax analysis, semantic analysis, intermediate representation, optimization, code generation
With this, Computer Science (Part III) is now complete across both papers: computing foundations, programming, object-oriented programming, algorithms and data structures, software engineering, compilers, computer architecture, networks, operating systems, databases, image processing, and web technologies.