Web Programming

Web programming is not merely the study of HTML tags or a particular server framework. It requires an understanding of how the browser, DNS, URLs, HTTP, TLS, HTML, CSS, JavaScript, accessibility, security, caching, client state, and server-side application models interact. These notes place historical technologies in context while treating the current Web platform through standards rather than product-specific recipes.

The Web is continuously evolving. HTML and Fetch are living standards, ECMAScript versions the JavaScript language, and HTTP semantics are intentionally separated from individual transport versions. The goal is therefore to learn durable platform and protocol principles rather than a particular editor, browser, or framework release.

1. The Internet and the Web are not the same system

The Internet is the global infrastructure interconnecting IP networks. The Web is an application ecosystem built on that infrastructure using URLs, HTTP, HTML, and browser APIs. E-mail, SSH, DNS, and many other protocols use the Internet without being part of the Web.

This distinction matters architecturally. A web interface may use HTTP while downstream services use a database protocol, message broker, or another transport.

2. From client-server to a distributed web request path

The simplest model has a browser as client and an application as server. A production request often follows a longer path:

browser
-> recursive DNS resolver
-> CDN / edge
-> load balancer / reverse proxy
-> web application
-> cache / database / message broker / downstream service

Every layer changes latency, failure, security, and caching behavior. A page displayed as one UI can contact many origins and services.

3. DNS: resolution and delegation

DNS is not merely a hostname-to-IP table. It is a hierarchical distributed naming system. A and AAAA records carry addresses, CNAME aliases, MX mail routing, and TXT various policy or verification data.

Responses can be cached according to TTL, so a record update is not necessarily visible everywhere immediately. DNSSEC provides an authenticated chain for DNS data integrity and origin; it does not replace TLS or application authentication.

4. URL, URI, origin, and site

A typical HTTP URL contains scheme, host, optional port, path, query, and fragment:

https://api.example.org:8443/v1/items?id=42#details

An origin is the scheme + host + port tuple. https://a.example and https://b.example are different origins. The browser's notion of a site, used by cookie and related policies, is a different concept and should not be treated as a synonym for origin.

A URL fragment is normally not sent in the HTTP request; it is handled by browser navigation or client-side state.

5. HTTP semantics are separate from transport versions

HTTP defines request-response semantics around resources. HTTP/1.1, HTTP/2, and HTTP/3 share the same core method and status semantics while using different transports and message encodings. HTTP/2 multiplexes streams and compresses fields over a connection. HTTP/3 uses QUIC, a secure multiplexed transport over UDP rather than TCP.

Choosing GET, POST, PUT, PATCH, or DELETE is not just assigning CRUD labels. Safe and idempotent method semantics influence retry, caching, and intermediary behavior.

6. Anatomy of a request and response

A message carries start-line information, headers, and an optional body:

GET /api/devices/42 HTTP/1.1
Host: example.org
Accept: application/json
If-None-Match: "v17"

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: private, max-age=60
ETag: "v17"

{"id":42,"state":"active"}

Headers are protocol metadata. Application data should not be moved into arbitrary custom headers when standard semantics or a body model are more appropriate.

7. Do not hide application failure inside HTTP success

Status codes classify the protocol-level result:

• 2xx: request was successfully processed,
• 3xx: redirection or conditional/cache outcome,
• 4xx: request/access issue attributable to client context,
• 5xx: server could not fulfill the request.

Returning 200 OK with {"success":false} can obscure protocol semantics. Conversely, treating every business-rule rejection as 500 is also incorrect. An API contract should define HTTP status and structured domain error together.

8. HTTPS and TLS

HTTPS is HTTP carried over TLS. TLS provides endpoint authentication through certificates, transport confidentiality, and integrity.

TLS is not application authorization. A correctly certified server can still expose the wrong record to an authenticated user. HTTPS also does not eliminate XSS or injection flaws.

Production deployments should manage HTTP-to-HTTPS redirection, HSTS, modern TLS configuration, and certificate lifecycle as one operational concern.

9. HTML is the semantic content layer

HTML is a markup language, not a programming language. It defines document semantics and application surfaces. Current HTML is maintained as a living standard, so durable knowledge comes from semantic elements and conformance rather than memorizing an old "HTML5 version."

<main>
  <article>
    <header><h1>System Status</h1></header>
    <p>Updated <time datetime="2026-09-16T09:30:00+03:00">09:30</time>.</p>
  </article>
</main>

A generic div can contain almost anything, but main, nav, article, button, and label provide stronger semantics, accessibility behavior, and maintenance contracts.

10. HTML parsing is deliberately error tolerant

text/html is not parsed as strict XML. The HTML Standard defines detailed error-recovery rules. Malformed markup can appear to work while producing a DOM tree different from what the source text visually suggests.

The reliable approach is valid semantic markup, conformance checking, and inspection of the actual DOM produced by the browser.

11. Forms, native controls, and validation

Native form controls provide keyboard behavior, serialization, accessibility semantics, and built-in constraints.

<form id="device-form">
  <label for="serial">Serial number</label>
  <input id="serial" name="serial" required minlength="6" autocomplete="off">
  <button type="submit">Save</button>
</form>

Client validation improves UX but is not a security boundary. The server must validate all external input again. Disabled fields, checkbox/radio serialization, and multipart file uploads all affect the server contract.

12. CSS: cascade, layout, and responsive composition

CSS defines much more than color and fonts. Cascade, specificity, inheritance, the box model, and formatting contexts determine layout behavior. Flexbox and Grid are the primary modern layout primitives; media and container queries can express responsive conditions.

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

.card { container-type: inline-size; }

Large piles of inline style and !important rules usually trade a local fix for global unpredictability. A constrained selector strategy and explicit design tokens are easier to reason about.

13. Responsive design is not a list of screen resolutions

Responsive design preserves usability across viewport size, zoom, font scaling, input method, and content variation.

Testing only a few pixel breakpoints misses long translations, OS text scaling, keyboard focus, touch targets, reduced-motion preferences, high contrast, and orientation changes.

14. Web accessibility

Accessibility is not an ARIA patch applied at the end. Native semantic HTML is the first option. A real button already carries keyboard, focus, and role behavior that a clickable div does not.

Core checks include meaningful heading order, programmatic form labels, complete keyboard operation, visible focus, non-color-only information, purposeful alternative text, sufficient contrast, and accessible announcements for dynamic state.

WCAG 2.2 is the current W3C Recommendation; automated testing should be complemented by keyboard and assistive-technology review.

15. JavaScript and ECMAScript

JavaScript's standardized language is ECMAScript. ECMAScript 2026 is the 17th edition of ECMA-262. Modern code can rely on language/platform primitives such as let/const, modules, promises, async/await, iterators, classes, and typed arrays according to its browser support target.

const state = Object.freeze({ retries: 3 });

export function normalize(value, min, max) {
  if (max <= min) throw new RangeError("invalid range");
  return (value - min) / (max - min);
}

Dynamic typing does not remove the need to validate untrusted external data.

16. DOM and the event model

The browser represents an HTML document as a DOM tree. JavaScript reads and mutates the tree through standardized APIs.

const button = document.querySelector("#refresh");
const output = document.querySelector("#status");

button.addEventListener("click", async () => {
  output.textContent = "Loading";
  const response = await fetch("/api/status");
  output.textContent = response.ok ? "Ready" : `Error ${response.status}`;
});

External listeners separate behavior from markup and work better with restrictive CSP policies. Events may travel through capture, target, and bubble phases; delegation can avoid thousands of duplicate listeners for homogeneous elements.

17. Modules and loading behavior

Modern browser modules use type="module", have module scope, and support import/export.

<script type="module" src="/assets/app.js"></script>

A bundler is not mandatory. Bundling, minification, tree-shaking, and code splitting should be chosen according to target browsers, cache strategy, and delivery cost.

18. The event loop and asynchronous execution

Browser JavaScript runs through an event-loop model. Promise continuations use the microtask queue, while timers and user events arrive through task sources. Long CPU work can block input and rendering.

For CPU-heavy work, chunking, Web Workers, or appropriate WebAssembly modules can be considered. async/await does not automatically move work to another thread; it structures promise-based asynchronous control flow.

19. Fetch API

The Fetch Standard unifies requests, responses, redirects, CORS, credentials, and service-worker interaction.

async function loadDevice(id, signal) {
  const response = await fetch(`/api/devices/${encodeURIComponent(id)}`, {
    headers: { Accept: "application/json" },
    signal
  });

  if (!response.ok) throw new Error(`HTTP ${response.status}`);
  return response.json();
}

Fetch generally rejects on a network-level failure, not because a server returned 404 or 500; status handling is an application responsibility.

20. Same-origin policy and CORS

The same-origin policy limits how code from one origin can read resources from another. CORS is an HTTP opt-in mechanism allowing a server to expose selected cross-origin responses.

CORS is not authentication and is not server-side authorization. A non-browser client can still issue the request; CORS primarily governs whether browser code may access the response.

Credentialed CORS requires particular care around allowed origins and preflight behavior.

21. Cookies, sessions, and browser storage

Cookies can be attached to HTTP requests automatically. Secure, HttpOnly, and SameSite should be selected according to the session model.

Set-Cookie: session=opaque-value; Path=/; Secure; HttpOnly; SameSite=Lax

localStorage and sessionStorage are readable by page JavaScript and therefore exposed to successful XSS. IndexedDB is a better primitive for larger structured client data.

A server-side session is not the cookie itself; the cookie may contain only an opaque session identifier while state lives on the server.

22. Authentication and authorization

Authentication answers "who is this?"; authorization answers "what may this principal do?" Session cookies, bearer tokens, OAuth/OIDC, and passkeys create different trust and lifecycle models.

Authorization must be enforced at the server endpoint and object level. Hiding a button in the UI is not access control.

23. CSRF, XSS, and injection

CSRF abuses automatically attached browser credentials. SameSite cookies reduce some exposure; some architectures still require CSRF tokens or origin checks.

XSS occurs when untrusted data reaches an executable HTML/JavaScript context. Context-correct output encoding, safe DOM APIs, template auto-escaping, and CSP form layered defenses.

SQL, command, and template injection occur when data is concatenated into executable syntax. Parameterized APIs are the primary control.

24. Content Security Policy

CSP restricts which resources a page may load or execute and can limit the impact of script injection.

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'

It is a defense-in-depth mechanism, not a replacement for secure data handling. Broad wildcards and a dependency on inline script weaken the policy.

25. OWASP Top 10:2025 as a design checklist

OWASP Top 10:2025 highlights broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, software/data integrity failures, logging and alerting failures, and mishandling of exceptional conditions.

The list is an awareness baseline rather than a complete security specification. Threat modeling, abuse cases, dependency provenance, secret management, and safe failure behavior remain necessary.

26. REST, resources, and JSON

REST is not a JSON format. It uses resource-oriented identifiers and standard HTTP semantics, with stateless/cache-aware interactions where appropriate.

POST /api/devices
Content-Type: application/json

{"serial":"A-1042","enabled":true}

JSON contracts should define dates, money, large integers, binary data, and polymorphic payloads explicitly. API versioning is a compatibility policy, not merely a /v1 prefix.

27. Where XML fits today

XML remains useful for document interchange, enterprise integrations, signed structures, and configuration. It is not a replacement for HTML.

For browser documents, text/html is the normal syntax. WHATWG explicitly does not recommend the XML syntax for new HTML content because it is essentially unmaintained and does not evolve with HTML features.

28. WebSocket, Server-Sent Events, and real-time delivery

Polling is not the only delivery model. Server-Sent Events can provide a one-way event stream, while WebSocket gives a long-lived bidirectional channel.

Selection should consider connection count, proxy timeouts, reconnection, backpressure, ordering/duplication, authentication renewal, and horizontal fan-out. "WebSocket is faster" is not sufficient architecture analysis.

29. Service workers and Progressive Web Apps

A service worker is an event-driven browser component operating between a page and network resources. It can provide offline caches and programmable fetch strategies.

Cache-first behavior suits immutable assets but can be dangerous for personalized or rapidly changing data. Service-worker cache is separate from the normal HTTP cache and needs its own invalidation lifecycle.

30. WebAssembly

The W3C WebAssembly Core Specification dated 12 August 2026 describes release 3.0 and is published as a Candidate Recommendation Draft. WebAssembly is a safe, portable, low-level code format useful for compute-heavy modules, codecs, simulation, and bringing libraries from other language ecosystems to the web; it is not a general replacement for JavaScript or the DOM.

A Wasm module interacts with the host through explicitly provided imports, which is part of its sandbox model.

31. Caching and conditional requests

Avoiding unnecessary transfer is often cheaper than accelerating it. Cache-Control, ETag, Last-Modified, If-None-Match, and Vary allow browsers and intermediaries to reuse or revalidate content.

Cache-Control: public, max-age=31536000, immutable

That policy suits hash-named immutable assets but should not be copied to personalized pages or authorization-dependent API responses.

32. Performance spans network and rendering

User-perceived latency includes DNS, TCP/QUIC/TLS setup, server time, payload size, parsing, JavaScript, style/layout, and painting.

A useful optimization order is to measure first, remove unnecessary requests, reduce payload/image size, fix caching, reduce render-blocking work, split long main-thread tasks, and control DOM/layout churn.

33. Images and media

Responsive images can use srcset and sizes; noncritical images can use native lazy loading.

<img
  src="/img/device-800.webp"
  srcset="/img/device-400.webp 400w, /img/device-800.webp 800w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800"
  height="450"
  alt="Device telemetry panel">

Explicit dimensions reduce layout shifts. Indiscriminate lazy loading of above-the-fold critical content can make performance worse.

34. Server-side programming independent of framework

Regardless of language, a typical request crosses similar responsibilities:

request parsing
-> authentication/authorization
-> validation
-> domain logic
-> transaction / external calls
-> response mapping

Java/Spring Boot, C#/.NET, Go, Python, PHP, Node.js, and other stacks expose different APIs around the same concerns.

HTTP request/session objects should not become domain-model dependencies without a clear reason.

35. What CGI, Classic ASP, and Web Forms teach historically

CGI, Classic ASP, VBScript, and ASP.NET Web Forms are not current default choices for new general web applications, but their designs explain the evolution of server-side web programming.

CGI made per-request process costs obvious. Classic ASP popularized server-side scripting. Web Forms attempted to project a desktop event model onto stateless HTTP using ViewState, server controls, and postback.

Modern server-rendered frameworks and APIs expose HTTP semantics more directly. The durable concepts behind old Request, Response, Session, form GET/POST, and XML examples remain relevant.

36. jQuery, VBScript, Flash, and historical editors

jQuery solved real browser-normalization, selector, AJAX, and event problems when browser APIs differed substantially. Modern DOM APIs, querySelector, Fetch, and standardized events remove many basic reasons to add it, although existing applications can still depend on it.

Browser VBScript is not part of the modern web platform, and the Flash plug-in model has disappeared from the mainstream platform. They belong in migration/history sections rather than current implementation guidance.

Product names such as FrontPage, HomeSite, and Visual InterDev are not durable web knowledge. Standards-conformant output, version control, build/testing, and deployment are.

37. E-mail, FTP, and Telnet in web systems

SMTP, IMAP, and POP are e-mail protocols, not Web protocols. Web applications may reach mail infrastructure through SMTP or an HTTP mail API.

FTP was historically common for publishing files; SFTP/SSH or HTTPS-based deployment is generally preferred when secure transport is required. Telnet is not a secure remote administration channel; SSH is its common secure operational replacement.

The durable lesson is to understand protocol security and transport properties rather than memorize old client software names.

38. Deployment: from hosting upload to delivery pipeline

Publishing a web application can involve artifact/image production, immutable version identifiers, configuration and secret separation, migration ordering, health/readiness checks, reverse proxy/TLS, DNS/CDN configuration, staged rollout, and rollback.

A static site, a monolith, and a distributed service should not be forced through the same deployment strategy.

39. SEO, metadata, and machine discoverability

title, meta descriptions, canonical links, robots directives, structured data, and sitemaps serve different discovery functions.

Historical meta keywords practices are not a modern SEO center. Robots directives are not access control and cannot protect confidential content.

Semantic HTML, useful content, stable URLs, and correct HTTP status codes are core technical SEO properties.

40. Testing strategy

Web testing should be layered:

• unit tests for pure business rules,
• integration/contract tests for HTTP contracts,
• realistic integration tests for persistence,
• browser end-to-end tests for critical journeys,
• automated and manual accessibility tests,
• security testing including dependencies and targeted attacks,
• performance tests using production-like load and browser profiles.

Using E2E tests for every detail creates a slow and brittle suite. Prefer the cheapest deterministic layer that can prove the property.

41. Production reliability

Browsers and networks are unreliable components. Requests can be cancelled, users can double-submit, proxies can time out, and retries can race with late responses.

Critical endpoints should therefore consider idempotency, timeout, cancellation, bounded retry, and duplicate handling. Optimistic UI also needs reconciliation and rollback behavior.

42. Related courses

For server-side Java development see Spring Boot; for C#/.NET see C# Programming; for language semantics see Programming Languages; for transport and routing see Computer Networks; for persistence see Database Management Systems; and for legal constraints see Information Technology Law.

References

1. WHATWG, HTML Living Standard. https://html.spec.whatwg.org/
2. WHATWG, Fetch Living Standard. https://fetch.spec.whatwg.org/
3. IETF, RFC 9110 — HTTP Semantics. https://www.rfc-editor.org/rfc/rfc9110
4. IETF, RFC 9113 — HTTP/2. https://www.rfc-editor.org/rfc/rfc9113
5. IETF, RFC 9114 — HTTP/3. https://www.rfc-editor.org/rfc/rfc9114
6. Ecma International, ECMA-262 — ECMAScript 2026 Language Specification. https://ecma-international.org/publications-and-standards/standards/ecma-262/
7. W3C, Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/
8. W3C, Content Security Policy Level 3. https://www.w3.org/TR/CSP3/
9. OWASP, OWASP Top 10:2025. https://top10.owasp.org/2025/
10. W3C WebAssembly Working Group, WebAssembly Core Specification 3.0. https://www.w3.org/TR/wasm-core/
11. MDN Web Docs, Web platform documentation. https://developer.mozilla.org/