Web development: how websites and apps work

Explore the parts of a web experience—from browser rendering and HTML structure to CSS layout, JavaScript behavior, HTTP requests, servers, and inclusive design.

The web as a client-server system

The World Wide Web is a system of interlinked resources accessed over the Internet. A browser acts as a client: it requests documents and data from servers, interprets them, and presents an interface. The server may return a static file or generate a response using application logic and stored data.

A web address, or URL, identifies a resource and describes how to access it. It can contain a scheme such as HTTPS, a host name, an optional port, a path, and query parameters. The browser uses DNS and network protocols to reach a host, then requests resources using HTTP.

• Front end: browser code and resources that users interact with.
• Back end: server-side logic, APIs, and data services.
• Static resource: a file served largely as stored, such as an image or stylesheet.
• Dynamic response: content generated in response to a request or user-specific data.

These are architectural roles, not necessarily separate machines. A small site can serve static pages from a single host; a large application may involve a browser, CDN, API services, databases, and identity providers.

HTML gives content structure

HTML (HyperText Markup Language) describes the meaning and structure of content. Elements such as headings, paragraphs, lists, links, forms, and buttons create a document that a browser and assistive technologies can interpret.

<main>
  <h1>Upcoming events</h1>
  <p>Choose an event to see its details.</p>
  <a href="/events">Browse events</a>
</main>

Semantic elements express purpose. A real button should generally use a <button>, not a styled <div>, because the browser provides keyboard behavior and accessibility semantics. A heading hierarchy helps people scan and navigate a document.

Forms and validation

Forms collect information through controls such as text inputs, selects, and checkboxes. Associate every control with a visible label, describe required formats, and report errors in a way that can be found with a keyboard or screen reader. Browser validation improves usability but does not replace server-side validation; clients can be modified or bypassed.

Use HTML for meaning and content, not merely to obtain a visual effect. Correct semantics improve accessibility, browser behavior, search interpretation, and maintainability.

CSS controls presentation and layout

CSS (Cascading Style Sheets) describes how HTML is presented: color, typography, spacing, borders, and layout. The cascade resolves which styles apply based on origin, importance, specificity, and source order. A rule that appears later does not always win if another selector is more specific.

.event-list {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr));
  gap: 1rem;
}

Modern layout tools such as Flexbox and Grid adapt content to available space. Prefer flexible sizes, responsive constraints, and meaningful document flow over fixed positions that break when text grows or a screen narrows.

Responsive design

Responsive design adapts an interface to different screen sizes and input methods. Start with content and a fluid layout; add breakpoints when the design needs a structural change rather than targeting a list of particular devices.

Test zoom, long text, different languages, and narrow viewports. A page that technically fits on a phone but requires horizontal scrolling for ordinary content may still be difficult to use.

JavaScript adds behavior

JavaScript can respond to user actions, update the document, validate input, and communicate with APIs. An event listener reacts to an event such as a button click or form submission. The page can update without reloading, though navigation and standard browser behavior should remain understandable.

const button = document.querySelector("#show-details");
const panel = document.querySelector("#details");

button.addEventListener("click", () => {
  panel.hidden = !panel.hidden;
});

JavaScript execution is event-driven. A long-running task on the main thread can block input and rendering, making the page appear frozen. Asynchronous operations such as network requests allow the browser to continue other work while waiting for a response.

Use progressive enhancement where practical: provide meaningful content and navigation in HTML, then use JavaScript to improve the experience. Handle loading, success, empty, and error states explicitly rather than leaving users unsure whether an action worked.

How a browser renders a page

A browser parses HTML into a document structure called the DOM and parses CSS into style rules. It combines them to determine layout, paints pixels, and composites layers for display. JavaScript can change the DOM or styles, which may cause some rendering work to happen again.

1. The browser requests a document and receives HTML.
2. It parses markup and discovers linked stylesheets, scripts, images, and fonts.
3. It builds document and style structures and calculates layout.
4. It paints and composites the page for display.
5. It responds to input and script changes by updating the affected parts.

The process can overlap: resources may load while parsing continues. A large script that blocks parsing, an oversized image, or repeated layout changes can slow a page. Measure with browser developer tools before optimizing.

Browsers implement standards but may differ in supported features and rendering details. Standards-based code, feature detection, and testing in relevant browsers reduce compatibility surprises.

HTTP and web requests

HTTP is a request-response protocol. A request includes a method, path, headers, and sometimes a body. The response includes a status code, headers, and optionally content. HTTPS uses TLS to protect the connection and authenticate the server when certificates are validated.

Method	Common intent	Important consideration
GET	Retrieve a representation	Should not be used to perform a destructive action
POST	Submit data or request processing	Repeating may create another result unless designed otherwise
PUT	Create or replace a resource at a known path	Often designed to be idempotent
DELETE	Request removal of a resource	Requires authorization and clear outcome handling

Status codes communicate broad outcomes such as success, redirection, client error, or server error. A browser or API client should still interpret the documented response body and handle network failures, timeouts, and expired authentication.

Cookies can store small pieces of state associated with a site. Security attributes such as Secure, HttpOnly, and SameSite help reduce particular risks when configured correctly. Do not store sensitive secrets in client-visible storage without understanding the threat model.

Servers, APIs, and data

A server receives requests and returns responses. An API defines how software clients request operations or data. A JSON API might expose endpoints to list events, retrieve one event, or register a user.

Server-side code validates input, checks authorization, applies business rules, interacts with storage, and returns a response. Never rely only on a browser to enforce permissions or validate important rules; a client is controlled by the user.

Worked example: submit a registration

1. The browser collects a name and email with labeled fields.
2. Client-side checks catch obvious missing values quickly.
3. The browser sends a request over HTTPS to a registration endpoint.
4. The server validates the data again, checks for conflicts, and stores the record.
5. The server returns success or a useful error; the browser communicates the outcome.

The server should avoid exposing whether a sensitive account exists when that information could be abused. The interface should preserve valid input after an error and explain how to correct it.

APIs need stable contracts: field names, types, error behavior, authentication, and versioning strategy. Documenting these details helps other clients integrate without depending on internal implementation.

Responsive and accessible design

People use different devices, browsers, languages, input methods, and assistive technologies. Semantic HTML, keyboard support, visible focus, sufficient contrast, captions, and text alternatives make experiences more inclusive.

Interactive controls should be reachable in a logical keyboard order and announce their purpose and state. Do not convey an error using color alone. Respect text resizing and reduced-motion preferences. Test with a keyboard and screen reader in addition to automated accessibility tools.

Accessibility is not an optional polish phase. Include it in acceptance criteria and component design so inaccessible patterns are not copied throughout the application.

Performance, security, and testing

Web performance affects access and user experience. Reduce unnecessary requests, compress appropriate resources, optimize images, and avoid shipping large scripts that are not needed. Use caching with correct freshness rules, and measure real loading behavior on representative devices and networks.

Security basics include HTTPS, server-side validation, parameterized database queries, output encoding, authorization checks, safe dependency updates, and careful handling of credentials. These controls address different risks and should be selected for the actual application.

Test at several levels: unit tests for small logic, integration tests for APIs and storage, and browser tests for important user workflows. Include keyboard use, empty data, slow responses, and errors. A working desktop screenshot is not enough to prove a site works across conditions.

A compact glossary

DOM

The browser's structured representation of a document.

HTTP

A request-response protocol used to transfer web resources and API messages.

API

A documented interface through which software components communicate.

Responsive design

Layout and behavior that adapt to different viewports and contexts.

Progressive enhancement

Building a useful baseline experience and enhancing it with additional capabilities.

Semantic HTML

Markup that expresses the role and meaning of its content.

References and further reading

1. MDN Web Docs. Learn web development. Learning pathway.
2. WHATWG. HTML Living Standard. Standard.
3. World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2. Accessibility standard.
4. web.dev. Learn Performance. Performance course.

Try it yourself

1. Sketch the request and response for a browser loading a page with one stylesheet and one image.
2. Why should the server validate a form even if the browser already checks it?
3. Choose semantic elements for a page title, navigation menu, event list, and registration action.
4. List three states an API-driven page should communicate besides success.
5. Use a keyboard to navigate a website and note where focus is visible or confusing.

Remember: the web works through standards and layers; build semantic, accessible clients that communicate safely with validated services.