Session 1: How the Web Works

You type `ceaproducts.ng` and press enter, and about a second later a page appears. In that second several distinct things happened, and understanding them is what separates someone who can build a site from someone who can only edit one. Your computer is the client; it asks. Somewhere else, a server — an ordinary computer, kept on permanently, connected to the internet — holds the files and answers.

First your computer had to find the server. It cannot route to a name, only to a number, so it asked a DNS server — the internet's phone book — which translated `ceaproducts.ng` into an IP address such as `104.21.44.9`. Then it opened a connection to that address and sent an HTTP request: essentially 'please send me the page at this path'. The server responded with an HTTP status code — 200 meaning 'here it is', 404 meaning 'there is nothing at that path', 500 meaning 'the server itself broke' — followed by the file, which is usually HTML.

Your browser then read that HTML, and every time it found a reference to something else — a stylesheet, an image, a script — it sent another request for that too. A single page commonly involves thirty or more requests. This is why a slow website is usually slow for a boring reason: too many requests, or files that are too large. It is also why the status codes matter to you personally — a 404 means your file is in the wrong place or named wrongly, and knowing that saves hours of confusion later.

The client is whatever requests: your laptop's browser, your phone. The server is whatever responds. That split is the whole architecture of the web, and almost every confusing problem resolves once you ask which side it is on. A layout that looks wrong is a client problem. A page that will not load at all is usually a server or DNS problem. Mixing them up is the most common beginner error in debugging.

Front end is everything the browser runs — HTML, CSS and JavaScript sent to the client. Back end is everything running on the server: the database, the accounts, the payment processing, the logic that decides what to show whom. A static site like a business brochure has almost no back end; the server just hands over files. An application like a bank has a great deal.

This course is front end only, and that is a deliberate and honest scope. Everything you need to build a professional business website is front end plus a hosting service. When a client needs accounts, payments or a database, that is a different discipline — Web Development covers it, and knowing where your competence ends is a professional strength, not a weakness.

HTML is structure and meaning. It says: this is a heading, this is a paragraph, this is a picture of the product, this is a link to the contact page. It is not styling and it is not behaviour. Written well, an HTML page makes sense with all the styling removed — which matters for search engines, for screen readers used by blind visitors, and for anyone on a slow connection where the styling arrives late.

CSS is presentation: colour, size, spacing, position, and how all of those change on a phone versus a desktop. Separating it from HTML is not pedantry — it means one stylesheet can restyle a whole site, and changing a brand colour becomes a one-line edit rather than a hundred.

JavaScript is behaviour: what happens in response to something. A menu that opens, a form that validates before sending, a gallery that advances. In a business website you will use very little of it, mostly through things other people wrote, and that is fine. The important thing is knowing which language is responsible when something is wrong, because looking for a layout problem in JavaScript is how an afternoon disappears.

A useful analogy that holds up: HTML is the skeleton and the organs, CSS is the appearance, JavaScript is the movement. Remove the CSS and the body still functions, looking plain. Remove the HTML and there is nothing at all.

You need two things and no more. A text editor — VS Code is free, is the professional standard, and is what this course assumes. And a browser with developer tools, which every modern browser has built in. That is the whole setup. You do not need a server running on your laptop to build a static site; you can open an HTML file directly in a browser.

Configure VS Code once and it pays for itself. Install the Live Server extension, which serves your folder locally and reloads the page automatically every time you save — this removes the tedious save-and-refresh cycle that makes beginners think their edits did nothing. Enable word wrap and format on save in settings so long lines do not run off the screen and your indentation stays consistent without effort. Turn on Emmet, which is built in: typing `div.card>p` and pressing Tab expands into properly nested HTML, which is the fastest way to write structure there is.

Then learn three keyboard habits immediately. Ctrl+S to save — Live Server only reloads on save, so forgetting it is the most common cause of 'my changes are not working'. Ctrl+Shift+P to open the command palette. And F12 to open developer tools. That last one is the most valuable tool in this entire course and the next section explains why.

Developer tools let you inspect and change any live webpage, including ones you did not build, and see the result instantly. Press F12 on any site. The Elements panel shows the HTML as the browser sees it; clicking any element highlights it on the page and shows the CSS currently applied to it, with a box diagram showing its size, padding, border and margin. You can edit any of it right there and watch the page change. Nothing you do in dev tools is permanent — refreshing restores the original — which makes it a completely safe place to experiment.

The Console panel shows errors, and reading them is a real skill. A red message naming a file and a line number is the browser telling you exactly what is wrong; beginners ignore it and stare at the code instead. The Network panel shows every request the page made, how long each took, and which failed — this is where you diagnose a slow site or a missing image. The device toolbar — the phone icon — lets you view the page at any screen size, which is essential once you build for phones.

Practise on sites you did not build. Open a Nigerian business website, inspect its heading, change its colour, look at what fonts and colours it uses, check how many requests it makes. Twenty minutes of this teaches more about how real sites are built than any tutorial, and it is exactly how working designers reverse-engineer a look they admire.