Web Foundations and Development Environment

Introduction

Every web application is built on a small set of ideas: a client requests a resource, a server processes the request, and a response travels back across a network. HTML defines document structure, CSS controls presentation, and JavaScript adds behaviour, but none of these technologies can be used effectively without understanding the environment in which they operate.

This chapter introduces the architecture and vocabulary of the web and establishes a professional development workflow. It explains browsers, servers, URLs, DNS, HTTP and HTTPS, then applies these ideas through editor configuration, browser developer tools, project organisation, command-line practice and Git version control.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish clients, servers, browsers and web applications;
• explain how a URL is resolved through DNS and used in an HTTP or HTTPS request;
• describe the request–response model and common HTTP methods and status codes;
• explain the security purpose of HTTPS and the role of certificates;
• create a standard front-end project structure;
• use an editor and browser developer tools for basic development and debugging;
• perform essential file-system operations from a command line; and
• create commits and inspect project history with Git.

1. The Web as a Distributed System

The World Wide Web is a distributed information system. Its resources—documents, images, stylesheets, scripts, data and media—may be stored on different computers and connected through networks. A user experiences a single page, but the page may depend on many servers and services.

A client is a program or device that requests a service. A web browser is the most familiar client, although mobile applications, command-line tools and automated programs can also make web requests. A server is a computer or software process that receives requests and provides resources or performs operations. The terms are contextual: the same computer can act as a client in one exchange and a server in another.

A web server commonly performs several tasks:

1. listens for network connections;
2. interprets incoming HTTP requests;
3. identifies a resource or application operation;
4. returns an HTTP response; and
5. records events, enforces access controls or forwards work to other services.

A server may return a static file, such as index.html, or generate a response dynamically by executing application code and querying a database. A browser then interprets the response. HTML is parsed into a document tree, CSS is used to calculate visual presentation, and JavaScript may modify the document or request additional data.

A layered view

Web development involves several related layers:

These layers should not be confused. DNS helps find a host; it does not transfer the page itself. HTTP defines messages; it does not determine the page's visual style. HTML structures content; it does not provide network security.

Figure: Simplified relationship between a browser, network services and a web server.

2. URLs, Domains and DNS

A Uniform Resource Locator (URL) identifies the location and access method of a resource. Consider:

https://www.example.org:443/courses/web/index.html?week=1#overview

Its components are:

A domain name is a human-readable name organised hierarchically. In www.example.org, org is the top-level domain, example is the registered domain, and www is a subdomain or host label. Domain names are not the same as web pages: a domain may host many paths, applications and services.

DNS resolution

Computers communicate using network addresses, while people generally use domain names. The Domain Name System (DNS) translates names into records, commonly including IP addresses. A browser or operating system may first consult cached information. If no suitable cached record exists, a DNS resolver obtains the answer through the DNS hierarchy.

DNS resolution does not download HTML. It answers a naming question: which network address is associated with this name? After resolution, the client can establish communication with the destination. DNS can also provide records for mail delivery, aliases and other services.

A simplified sequence is:

1. The user enters a URL.
2. The browser identifies the scheme and host.
3. A resolver searches its cache or queries DNS.
4. DNS returns an address or an error.
5. The client connects to the service at that address.
6. The client sends an HTTP request.

Several addresses may be returned for one name. This can support load distribution or geographic routing. Caches improve speed but mean that changes to DNS records may not be visible everywhere immediately.

3. HTTP and HTTPS

Hypertext Transfer Protocol (HTTP) is an application-layer protocol for exchanging web messages. HTTP is stateless in its basic design: each request contains the information needed for that transaction, although cookies, tokens and application mechanisms can associate multiple requests with a user session.

An HTTP request commonly contains:

• a method, such as GET or POST;
• a target path and protocol version;
• request headers; and
• an optional message body.

An HTTP response contains:

• a status code;
• response headers; and
• an optional body.

Important methods include:

A method's intended semantics matter. A GET link should not be used to perform an irreversible action merely because it is convenient. Idempotence means that repeating a request has the same intended effect as making it once; it does not guarantee identical responses or absence of logging.

Status codes

HTTP status codes are grouped by their first digit:

A 404 means that the server could not find a representation for the requested target; it does not necessarily mean that the server is offline. A 401 generally indicates that authentication is required or has failed, whereas 403 indicates that the server understood the request but refuses to authorise it.

HTTPS

HTTPS is HTTP carried through Transport Layer Security (TLS). TLS provides encryption in transit, server authentication through certificates, and integrity protection against undetected modification. It protects communication between the client and the TLS endpoint, but it does not make an application automatically secure.

A browser validates a server certificate against trusted certificate authorities, checks the domain identity and evaluates certificate validity. A warning may occur when a certificate is expired, incorrectly issued or does not match the host. Users should not casually bypass such warnings, particularly when entering credentials or payment information.

HTTPS does not protect against every threat. It cannot prevent a malicious website from receiving information that a user deliberately submits, remove vulnerabilities in server code, or guarantee that a downloaded file is safe. Secure application design still requires input validation, access control, safe session management, careful dependency use and appropriate data handling.

4. The Request–Response Model in Practice

Suppose a learner visits https://training.example/lesson.html. The browser may perform the following broad operations:

1. parse the URL;
2. resolve training.example through DNS;
3. establish a secure connection;
4. send a GET request for /lesson.html;
5. receive a response, perhaps with status 200 and content type text/html;
6. parse the HTML;
7. discover referenced CSS, JavaScript, fonts and images; and
8. issue further requests for those resources.

The page is therefore often the result of a sequence of request–response exchanges, not one exchange. Developer tools expose this sequence in the Network panel.

A simplified request might be:

GET /lesson.html HTTP/1.1
Host: training.example
Accept: text/html

A simplified response might be:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

<!doctype html>
<html>...</html>

Headers carry metadata. Content-Type describes the representation, Content-Length may describe its size, Cache-Control gives caching instructions, and cookies may maintain application state. Modern HTTP implementations may use different transport details, but the conceptual request–response model remains essential.

5. Configuring a Development Environment

A development environment should reduce friction while making work observable and reproducible. A basic front-end environment requires:

• a code editor with syntax highlighting, search, indentation and extensions managed carefully;
• a modern browser with developer tools;
• a terminal or command prompt;
• a web server for projects whose behaviour depends on HTTP; and
• Git for version control.

Editor setup

Create a workspace rather than opening unrelated files individually. Enable visible whitespace, automatic bracket pairing and consistent indentation. Use UTF-8 encoding and configure a formatter only when its rules are understood. Useful extensions may provide HTML completion, CSS inspection, JavaScript linting and Git integration, but excessive extensions can slow the editor or introduce unreviewed behaviour.

A minimal project can contain:

web-foundations/
├── index.html
├── css/
│   └── styles.css
├── js/
│   └── app.js
├── images/
├── README.md
└── .gitignore

Use lowercase names and avoid spaces where practical. Keep source files separate by responsibility. Relative paths should be tested from the document that uses them; for example, css/styles.css from index.html differs from ../css/styles.css when the HTML file is inside another directory.

A minimal index.html is:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Web Foundations</title>
  <link rel="stylesheet" href="css/styles.css">
</head>
<body>
  <main>
    <h1>Web Foundations</h1>
    <p id="message">The document has loaded.</p>
  </main>
  <script src="js/app.js" defer></script>
</body>
</html>

The doctype activates standards mode. The language attribute supports accessibility and language-aware tools. The viewport declaration supports appropriate layout on mobile devices. defer allows the script to be downloaded without blocking HTML parsing and runs it after parsing.

Browser developer tools

Developer tools are an investigation environment, not merely a place to inspect colours.

• Elements/Inspector: inspect the DOM and computed styles. Changes made here are usually temporary.
• Console: read errors, evaluate expressions and observe diagnostic messages. Never paste unknown commands into a console.
• Network: inspect requests, status codes, timing, headers, payloads and responses. Disable cache when testing loading behaviour, if appropriate.
• Sources/Debugger: set breakpoints and inspect JavaScript execution.
• Application/Storage: inspect cookies, local storage and other browser-managed data.
• Accessibility tools: examine names, roles, contrast and keyboard-related issues.

A disciplined debugging process begins with reproduction. Record the action that causes the problem, inspect the first relevant console error, locate the associated request in Network, and change one variable at a time. A 404 for styles.css usually suggests an incorrect path or filename; a JavaScript syntax error may prevent later code from running; a 200 response does not prove that the application produced the intended content.

6. Command-Line Foundations

The command line provides direct, scriptable control of the file system and development tools. Commands vary by operating system, but the following concepts are widely applicable.

Before removing or overwriting files, verify the current directory with a location command. Paths can be absolute, beginning at the file system root, or relative to the current directory. The symbol .. refers to the parent directory and . refers to the current directory.

A safe initial sequence might be:

mkdir web-foundations
cd web-foundations
mkdir css js images
touch index.html README.md .gitignore

On systems without touch, create files through the editor or use the platform's equivalent command. A local development server can be useful because it reproduces HTTP behaviour and avoids some restrictions associated with opening files directly using a file: URL. The exact command depends on the installed tool; always understand which directory is being served and whether the server is accessible beyond the local machine.

7. Git-Based Version Control

Git is a distributed version-control system. It records snapshots and the relationships between them, allowing developers to inspect history, compare changes and restore earlier states. Git is not the same as a remote hosting service: Git operates locally, while services such as GitHub or GitLab may host shared repositories.

The central concepts are:

• working tree: files currently being edited;
• repository: Git's stored history and metadata;
• staging area: the proposed contents of the next commit;
• commit: a recorded snapshot with an author, message and parent history;
• branch: a movable name referring to a line of development; and
• remote: another repository used for collaboration or backup.

A basic workflow is:

git init
git status
git add index.html css/ js/ README.md
git commit -m "Create initial web project"

git add stages a snapshot of selected changes; it does not permanently commit them. Inspect the staged and unstaged differences:

git diff
 git diff --staged
git log --oneline

The first command compares the working tree with the index, while the second compares the index with the most recent commit. The space before git diff --staged in the displayed block is not part of the command and should be omitted when typing it.

A .gitignore file prevents unsuitable files from being tracked. It may include operating-system metadata, editor settings, build output and secrets. Never commit passwords, private keys, access tokens or production configuration containing confidential information. Ignoring a file does not remove a secret that has already been committed; compromised credentials must be revoked or rotated, and repository history may require specialist remediation.

Good commit messages describe a coherent change, such as Add responsive navigation styles. Frequent, focused commits make defects easier to locate and code review easier to perform. Before sharing work, inspect the status, review the diff, test the application and confirm that no sensitive information is included.

8. Illustrative Case: A Missing Stylesheet

Background. A student creates a portfolio page with index.html and css/styles.css. The page loads, but it appears unstyled.

Problem. The browser shows a successful document request, yet the Network panel shows GET /styles.css returning 404 Not Found.

Analysis. The HTML contains <link rel="stylesheet" href="styles.css">, which asks for a stylesheet in the same directory as index.html. The actual file is inside the css directory.

Approach and solution. The student changes the link to <link rel="stylesheet" href="css/styles.css">, reloads the page, and checks the Network panel. The stylesheet now returns 200 OK. The student then commits the correction:

git add index.html
git commit -m "Correct stylesheet path"

Outcome. The page is styled, and the request trace provides evidence that the correction worked.

Learning points. A browser's visual result should be connected to evidence in developer tools. Status codes, file paths and project structure are related. Version control records not only the final result but also the reasoning embodied in a small, reviewable change.

9. Professional, Ethical and Contemporary Considerations

Web development affects privacy, accessibility and trust. Developers should minimise collection of personal data, communicate clearly about cookies and storage, protect credentials, use HTTPS, and avoid exposing private information in source code or logs. Accessibility is not an optional visual enhancement: semantic HTML, keyboard access, readable contrast and meaningful labels support users with varied abilities and technologies.

Modern applications frequently depend on third-party packages, content delivery networks, analytics and cloud services. These dependencies create supply-chain, availability and privacy risks. Pinning and reviewing dependencies, monitoring security advisories, limiting permissions and documenting external services are professional responsibilities.

AI-assisted coding can suggest markup, commands or debugging hypotheses, but generated output must be reviewed. It may invent APIs, introduce insecure code, mishandle personal data or include licences that are unsuitable for a project. The developer remains responsible for testing, attribution, security and correctness. AI is most useful as an aid to explanation and exploration, not as a substitute for understanding the request–response chain.

Chapter Summary

The web is a distributed client–server system. Browsers act as clients, servers provide resources or application operations, URLs identify resources, and DNS translates domain names into network addresses. HTTP defines request and response messages, while HTTPS adds TLS-based encryption, integrity and server authentication. A page commonly requires several requests for HTML, CSS, JavaScript and other assets.

A productive development environment combines a well-organised project, capable editor, browser developer tools, command-line skills and Git. Developer tools connect visible behaviour to DOM structure, network messages and program execution. Git's working tree, staging area, commits, branches and remotes support traceable collaboration. Professional practice also requires attention to accessibility, privacy, security, dependency risk and responsible use of AI tools.

Key Terms

Client: A program or device that requests a service.

Server: A program or computer that receives requests and provides resources or services.

Browser: Client software that retrieves and interprets web resources.

URL: A structured address identifying a resource and its access method.

Domain name: A human-readable hierarchical name used to identify a host or service.

DNS: The Domain Name System, which maps names to network records.

HTTP: The application protocol used to exchange web requests and responses.

HTTPS: HTTP protected by Transport Layer Security.

TLS: A security protocol providing encryption, integrity and authenticated endpoints.

Request: A message sent by a client to ask for a resource or operation.

Response: A message returned by a server after processing a request.

HTTP method: A verb expressing the intended operation, such as GET or POST.

Status code: A three-digit response classification indicating processing outcome.

Header: Metadata associated with an HTTP request or response.

Developer tools: Browser utilities for inspecting structure, styles, scripts and network activity.

Command line: A text-based interface for executing system and development commands.

Git: A distributed version-control system.

Repository: A directory and metadata containing Git history.

Commit: A recorded snapshot of project changes.

Staging area: The set of changes selected for the next Git commit.

Review Questions

Short Answer Questions

1. What is the difference between a client and a server?
2. What information does DNS provide during a typical web visit?
3. Identify three components of a URL and state the purpose of each.
4. What is the main security purpose of HTTPS?
5. What is the role of the Git staging area?

Long Answer Questions

1. Explain the sequence from entering a URL to displaying an HTML page, including DNS, HTTPS and subsequent asset requests.
2. Compare GET, POST, PUT, PATCH and DELETE, including the importance of method semantics.
3. Describe how browser developer tools can be used to diagnose a page that does not appear correctly.
4. Explain a suitable project-folder structure for a small HTML, CSS and JavaScript application.
5. Describe a responsible Git workflow from editing files through reviewing and committing changes.

Analytical / Application Questions

1. A page returns 200 OK, but its stylesheet returns 404 Not Found. Using the request–response model, identify the likely cause and propose a verification procedure.
2. A team wants to commit an API token so that a client-side application can use it. Analyse the security problem and recommend a safer design and Git response.
3. A website loads quickly on one computer but slowly on another. Identify at least four observations that could be collected using developer tools and explain how each could support a diagnosis.

Multiple Choice Questions with Answers

Question 1

Which component translates a domain name into network records such as an IP address?

A. HTML parser

B. DNS

C. CSS engine

D. Git repository

Correct Answer: B. DNS

Question 2

Which URL component identifies a resource or route on a host?

A. Scheme

B. Fragment

C. Path

D. Port

Correct Answer: C. Path

Question 3

What does HTTPS primarily add to HTTP?

A. Automatic accessibility compliance

B. Encryption, integrity protection and endpoint authentication through TLS

C. A database for storing web pages

D. A replacement for DNS

Correct Answer: B. Encryption, integrity protection and endpoint authentication through TLS

Question 4

A browser requests /missing.css and receives status 404. What does this most directly indicate?

A. The server could not find a representation for the requested target

B. The browser has successfully applied the stylesheet

C. The DNS resolver has necessarily failed

D. The connection is encrypted

Correct Answer: A. The server could not find a representation for the requested target

Question 5

Which HTTP method is normally used to retrieve a representation without intending to change server state?

A. GET

B. POST

C. DELETE

D. PATCH

Correct Answer: A. GET

Question 6

Which developer-tools panel is most useful for inspecting request URLs, status codes, headers and response timing?

A. Elements

B. Network

C. Sources

D. Accessibility

Correct Answer: B. Network

Question 7

What does git add do in the basic Git workflow?

A. Deletes the current repository

B. Publishes the project to a remote server

C. Stages selected changes for a future commit

D. Automatically fixes syntax errors

Correct Answer: C. Stages selected changes for a future commit

Question 8

Why is defer useful on the script element in the example?

A. It prevents the JavaScript file from ever loading

B. It allows downloading without blocking parsing and runs the script after parsing

C. It converts JavaScript into CSS

D. It encrypts the script

Correct Answer: B. It allows downloading without blocking parsing and runs the script after parsing

Question 9

Which item should normally be excluded from a Git repository?

A. A reviewed README file

B. The main HTML document

C. A CSS file required by the page

D. A private access token

Correct Answer: D. A private access token

Question 10

A domain may return several network addresses primarily to support which possibility?

A. Load distribution or geographic routing

B. Changing HTML into CSS

C. Removing the need for HTTP

D. Guaranteeing that every request is successful

Correct Answer: A. Load distribution or geographic routing