Theory
Two computers run your website
When a student registers on FestConnect, two very different machines are involved. Their phone (the client) shows the form and reacts as they type. The college's server actually stores the registration and checks it against the seat count.
Code can run in either place, and it matters which. A script in the browser can flash 'email looks wrong' the instant they type. A script on the server can save the record and email a ticket. Neither can do the other's job well.
Theory
The waiter and the kitchen
At a restaurant, the waiter (client-side) is right there: takes your order, corrects obvious mistakes ('we are out of that'), gives instant responses. The kitchen (server-side) is out of sight: it holds the ingredients, follows the secret recipes, and actually makes the food. You would not let a customer into the kitchen, and the waiter cannot cook. A website splits work the same way.
Theory
Client-side vs server-side
- Client-side scripting runs in the browser. The language is JavaScript. It reacts to clicks and keystrokes, updates the page without reloading, and validates instantly. The user can see it (View Source) and even switch it off.
- Server-side scripting runs on the web server before the page is sent. Languages include PHP, Python, Node. It reads and writes the database, checks passwords, holds secrets, and builds HTML. The user never sees this code.
Real sites use both.
At a glance
Where the work happens
| Aspect | Client-side (JS) | Server-side (PHP/Python) |
|---|---|---|
| Runs on | the browser | the web server |
| Good at | instant UI, reactions | database, secrets, auth |
| Visible to user? | yes (View Source) | no |
| Needs a reload? | no | usually returns a new page |
Think first
Who checks the seats?
FestConnect shows 'seats left: 3'. Should the check that stops a 4th person from registering happen in the browser (JS) or on the server, and why can it not be trusted to the browser alone?
Show the answer
On the server. The browser copy of 'seats left' can be stale (someone else just registered) and the user can edit or disable the JavaScript. Only the server sees the real, current database and can reject the 4th registration reliably. The browser can hint ('looks full') for a nice experience, but the server holds the truth. This is the golden rule: never trust the client for anything that must be correct.
Quiz
Your FestConnect form uses JavaScript to reject blank fields before submitting. Is that enough to keep bad data out of the database?
- No: the server must re-validate, because users can bypass client-side JS
- Yes: client-side validation fully secures the database
- Yes, as long as you also add more JavaScript checks
- No: JavaScript cannot validate forms at all
Show the answer
No: the server must re-validate, because users can bypass client-side JS
Client-side JS validation is for a fast, friendly experience, but a user can disable JS or send a request directly, bypassing it entirely, so the server must check again before saving (A). More JS (C) does not fix a checker that can be switched off. JS certainly can validate (D is false); it just is not the last line of defence. The rule: validate on the client for UX, re-validate on the server for security.
Watch out
The trust trap
The single biggest misconception: 'my JavaScript checks it, so it is safe'. Anything in the browser is visible and editable by the user. Passwords, prices, seat limits, permissions, all must be enforced on the server. Client-side scripting improves how a page feels; server-side scripting decides what is true.
Theory
You have already met the server side
The database work in BCA303 (Python + SQLite) and the SQL in BCA105 were server-side: code running away from the browser, next to the data. This whole Unit 3 is the other half, the client side, in JavaScript. By the end, FestConnect's form will validate in the browser (this unit) and you will understand exactly why the real save still belongs on the server.
Summary
Key takeaways
- Client-side scripting (JavaScript) runs in the browser: instant reactions, UI updates, no reload; visible and disableable by the user.
- Server-side scripting (PHP, Python, Node) runs on the server: database, secrets, authentication; hidden from the user.
- Real sites use both: JS for a snappy feel, the server for truth and storage.
- Client-side validation is convenience only; the server must re-validate for security.
- Never trust the client for anything that must be correct (seats, prices, passwords).
- Memory hook: the waiter (client) and the kitchen (server).