Web Programming

This chapter covers NET's Web Programming sub-item as a bundle of named technologies: HTML/DHTML for markup and client-side dynamism, XML for structured data exchange, scripting languages, and Java's server-side web technologies (Servlets, Applets) — none of which GATE CS's syllabus touches at all.

HTML, DHTML and XML

  • HTML is a markup language of nested tags describing a page's static structure and content, rendered by a browser; it is NOT a programming language (no variables, loops or conditionals of its own).
  • DHTML (Dynamic HTML) is not a separate language but a combination — HTML + CSS + client-side scripting (JavaScript) + the DOM — that lets a page change its own content, style and structure AFTER it loads, in response to user events, without a full page reload.
  • XML (Extensible Markup Language) defines custom tags for structured data exchange rather than presentation — unlike HTML's fixed tag vocabulary, an XML document's own tags are defined by the application (often validated against a DTD or XML Schema), which is what makes XML a data-interchange format rather than a display format.

Scripting Languages: Client-Side Versus Server-Side

A scripting language (JavaScript client-side, or a server-side scripting language) is typically interpreted rather than compiled, dynamically typed, and used to glue together and add behaviour to existing components rather than to build a whole system from scratch — client-side scripting runs IN THE BROWSER after the page is delivered, while server-side scripting runs ON THE SERVER before the page is ever sent, generating HTML dynamically per request.

Java on the Web: Applets and Servlets

ℹ️ Applets and servlets are opposite halves of the Java web story
A Java applet is client-side: a small Java program embedded in a web page, downloaded and run inside the user's browser (historically inside a JVM plugin), with its lifecycle methods init/start/stop/destroy called by the browser. A Java servlet is server-side: a Java class running inside a server-side container (e.g. Tomcat), receiving an HTTP request and generating the HTTP response — its own lifecycle is init/service/destroy, called by the container rather than a browser. Applets are effectively obsolete today (browsers dropped the plugin support they needed), but the client-side/server-side distinction they illustrate is exactly what a NET question tests.

The Client-Server Model and the HTTP Request-Response Cycle

Every web interaction follows the same shape: a client (browser) sends an HTTP REQUEST naming a method (GET to retrieve, POST to submit data) and a URL; a server processes it — a static file server simply reads a file from disk, while a dynamic server (running servlets or a scripting engine) executes code to build the response on the fly — and returns an HTTP RESPONSE with a status code (200 OK, 404 Not Found, 500 Internal Server Error, 301 Redirect) and a body (typically HTML). Sessions and cookies exist because HTTP itself is STATELESS — the server otherwise has no memory of a client between one request and the next.

Key takeaways

  • HTML is markup, not a programming language; DHTML is HTML+CSS+scripting+DOM combined to change a loaded page without a reload.
  • XML defines custom, application-specific tags for structured data exchange, unlike HTML's fixed display-oriented tag set.
  • Client-side scripting runs in the browser after delivery; server-side scripting runs on the server, generating each page's HTML before it is sent.
  • A Java applet is client-side (runs in the browser); a servlet is server-side (runs in a server container) — opposite halves of the same client-server model.

Practice questions (8)

Attempt each one before opening the answer. Every explanation names the tempting wrong option as well as the right one, because that is where marks are lost.

  1. HTML by itself is best described as:

    1. A markup language describing a page's structure, with no variables or loops of its own
    2. A fully-featured procedural programming language
    3. A database query language
    4. A server-side scripting language
    Show answer

    Answer: A — A markup language describing a page's structure, with no variables or loops of its own

    HTML has no control-flow constructs of its own — dynamism requires a separate scripting language layered on top of it, which is exactly what DHTML adds.
  2. DHTML is best understood as:

    1. A combination of HTML, CSS, client-side scripting and the DOM, not a separate language
    2. An entirely new markup language replacing HTML
    3. A server-side database technology
    4. A compiled binary format for web pages
    Show answer

    Answer: A — A combination of HTML, CSS, client-side scripting and the DOM, not a separate language

    DHTML names a combination of existing technologies working together to let a page change after it loads, rather than any single new language.
  3. Unlike HTML, XML:

    1. Allows the application to define its own custom tags for structured data
    2. Has a fixed, unchangeable vocabulary of tags
    3. Cannot be validated against any schema
    4. Is exclusively a display/presentation format
    Show answer

    Answer: A — Allows the application to define its own custom tags for structured data

    XML's tags are extensible and application-defined (hence the name), typically validated against a DTD or XML Schema — the opposite of HTML's fixed, presentation-oriented tag set.
  4. Server-side scripting, compared to client-side scripting, runs:

    1. On the server, generating each page's content before it is sent to the browser
    2. In the browser, after the page has already been delivered
    3. Only on mobile devices
    4. Nowhere; server-side scripting does not exist
    Show answer

    Answer: A — On the server, generating each page's content before it is sent to the browser

    Server-side scripting executes before delivery and produces the HTML that is then sent; client-side scripting is what runs afterwards, in the browser, on the already-delivered page.
  5. A Java servlet's lifecycle methods (init, service, destroy) are called by:

    1. The server-side container it runs inside (e.g. Tomcat)
    2. The user's web browser
    3. The database engine directly
    4. The DNS resolver
    Show answer

    Answer: A — The server-side container it runs inside (e.g. Tomcat)

    A servlet is a server-side component whose lifecycle is managed entirely by the container it is deployed in, in contrast to an applet's lifecycle, which was called by the browser it ran inside.
  6. Which of the following are true of a Java applet? (More than one option may be correct.)

    1. It runs client-side, inside the user's browser
    2. It is effectively obsolete today because browsers dropped the plugin support it needed
    3. It runs exclusively on the server
    4. Its lifecycle methods are called by the browser
    Show answer

    Answer: A — It runs client-side, inside the user's browser; B — It is effectively obsolete today because browsers dropped the plugin support it needed; D — Its lifecycle methods are called by the browser

    An applet is a client-side technology whose lifecycle (init/start/stop/destroy) is driven by the browser it runs inside; browser vendors' removal of plugin support has made applets effectively obsolete, which is the opposite of running exclusively on the server.
  7. Name the document format, defined by nested user-defined tags and often validated against a DTD or Schema, used chiefly for structured data exchange between systems (not display).

    Numerical answer — type the value.

    Show answer

    Answer: XML

    XML (Extensible Markup Language) lets an application define its own tag vocabulary for structured data, distinct from HTML's fixed, presentation-oriented tags.
  8. HTTP is described as a stateless protocol, which is chiefly why:

    1. Sessions and cookies exist, to let a server recognise the same client across multiple requests
    2. A server can never respond to more than one client at a time
    3. Web pages can never contain images
    4. XML replaced HTTP entirely
    Show answer

    Answer: A — Sessions and cookies exist, to let a server recognise the same client across multiple requests

    Without any built-in memory of a client between requests, a stateless HTTP server would treat every request as if from a stranger — sessions (server-side state keyed by an identifier) and cookies (that identifier stored client-side) are exactly the mechanism built on top of HTTP to work around this.