Programming for the web
Learn the core concepts and decision-making in Cambridge 9626 Topic 21, then practise recall, application and transfer with fictional scenarios.
Exam scope and assessment notes
This is original StudyForA teaching and fictional practice based on Cambridge syllabus outcomes, not copied syllabus text, an official question, a required software brand or a Cambridge mark scheme. Practical software tasks here are planning and reasoning exercises; StudyForA does not inspect files created in spreadsheet, database, graphics, audio/video or animation software, simulate the practical exam environment, award official marks or predict a grade. Follow the software and file-format requirements issued by your centre for your exam year.
Before you begin
- Check whether your route is AS Level (Topics 1–11) or full A Level (Topics 1–21).
Work on paper. Try each question before revealing help, and explain why your method works.
Quick readiness check
Before Topic 21: programming for the web
What you will learn
- Explain client-side and server-side web processing and how HTML, CSS, JavaScript and databases can work together
- Use web-programming constructs: variables, data types, operators, selection, iteration, functions, arrays and events
- Validate forms, process data and generate appropriate output
- Explain timing events including setTimeout()/setInterval(), comments, testing and safe handling of user input
The browser and server have different roles
HTML gives page structure, CSS controls presentation and JavaScript adds client-side behaviour. Server-side code handles requests that need trusted or private processing and can communicate with databases. A browser should not be trusted with secrets or authoritative decisions: users can inspect or alter client-side code. A form sends values; those values need appropriate type, range, presence and format checks on the server as well as helpful client feedback.
Write, test and explain small behaviours
Programs use variables, data types, operators, selection, loops, functions and arrays to transform inputs into outputs. Events respond to user action; setTimeout() schedules one delayed callback and setInterval() repeats at an interval until stopped. Comments explain intent and assumptions. Test normal, boundary and invalid inputs, empty fields, timing and errors. Use text-safe output and avoid exposing sensitive data in page code or error messages.
Sources for this lesson
Pause and explain
Which approach best demonstrates secure, reliable IT practice in programming for the web?
Worked example
A page should show a message 3 seconds after a button is clicked. Describe the event and timing approach and one test.
Show the worked solution
- Attach a click event handler to the button.
- Call setTimeout with a 3000 ms delay to show the message once.
- Test repeated clicks and whether an earlier timer should be cancelled.
Answer When the button's click event occurs, call setTimeout(() => showMessage(), 3000). This schedules one delayed action; setInterval would repeat and is unnecessary. Test no click, one click and rapid repeated clicks. If only one message should appear, store and clear an existing timer before scheduling another.
Try a topic test
Choose Easy, Normal or Difficult. Save your answers and open worked review after finishing.
Test this topic →From guided practice to a new situation
Write your answer and reasoning first. Use a hint only if you are stuck. The model solution is for self-checking; your written work is not automatically marked.
A web form accepts a learner age and sends it to a server. Name client-side feedback and server-side checks.
Give me a hint
The browser improves usability; the server must enforce trust boundaries.
Compare my reasoning
- Give immediate browser feedback for missing or out-of-range values.
- Repeat validation on the server before processing or storing.
- Return safe, clear errors without echoing unsafe input.
The browser can mark the required field and show a range message before submission. The server must independently check that the value is present, numeric and within the permitted age range before saving or using it. Client checks can be bypassed, so they are not a security control. Return a clear error without trusting or executing submitted text.
Look for these in your work
- Distinguishes usability from trust
- Checks type and range server-side
- Handles output safely
A page uses setInterval to refresh a countdown every second. What must happen when the countdown reaches zero or the page closes?
Give me a hint
Repeated timers need a stopping condition and should not keep running unnecessarily.
Compare my reasoning
- Store the interval identifier.
- Clear the interval at zero or when no longer needed.
- Avoid updating after the component/page has been removed.
Store the identifier returned by setInterval and call clearInterval when the countdown reaches zero or when the page/component is removed. Otherwise repeated callbacks may continue unnecessarily or attempt to update an unavailable page. Test the zero boundary and cleanup after navigation.
Look for these in your work
- Identifies interval cleanup
- Handles the stopping boundary
- Tests page lifecycle
A search page inserts a user's query directly into an HTML result string. Explain a safer approach and a test.
Give me a hint
Treat user input as data and check whether it can be interpreted as markup.
Compare my reasoning
- Use text-safe output rather than interpreting input as HTML.
- Validate length and handle empty input.
- Test ordinary text and markup-like strings.
Render the query as text through a safe text API or use a framework's escaped text interpolation, rather than concatenating it into executable HTML. Validate sensible length and handle empty values. Test a normal query and a markup-like string to confirm it displays literally and does not run as code.
Look for these in your work
- Uses safe output
- Handles input constraints
- Tests a hostile-looking value safely
Common mistakes
- Putting secrets or trusted authorization checks in client-side JavaScript
- Using setInterval when a one-time delay is required
- Checking input only in the browser
What can you explain now?
A web form accepts a learner age and sends it to a server. Name client-side feedback and server-side checks.
Compare with the explanation
The browser can mark the required field and show a range message before submission. The server must independently check that the value is present, numeric and within the permitted age range before saving or using it. Client checks can be bypassed, so they are not a security control. Return a clear error without trusting or executing submitted text.
The browser improves usability; the server must enforce trust boundaries.
After trying it yourself, choose your next review. This is your self-assessment.
Your review choice appears on Today. Sign in to sync it across devices.
Make it stick
Why must server-side validation repeat checks already performed in the browser?
If you needed the solution, close it and solve the problem again from a blank page. A correct answer is stronger when you can explain the reason for each step.