History & Walking Skeleton

A Short History of Web Applications

---

The Web began as a way to share linked information. Let’s follow how it developed into several ways of dividing work between browsers and servers. These arrangements still coexist, and getting to know them will help us understand the application we will run in the next chapter.

The Internet and the Web

The Internet connects networks so computers can exchange data. The Web uses that connectivity to make resources available through addresses, requests, and links. Email can use the Internet without being a web page.

Tim Berners-Lee proposed the Web at CERN in 1989. Browser and server software followed, using HTML documents, HTTP requests, and resource addresses. CERN made the technology freely available in 1993. The W3C’s history of the Web describes these developments.

A lasting feature is interoperability: a document can link to a resource on another server without the two sites sharing a programming language or development team. The browser needs compatible ways to identify resources and interpret responses.

Linked documents

Consider a community center that publishes one HTML page for each event. A visitor follows a link to an event page, the browser requests that resource, and the server returns its prepared document.

Figure 1 follows the request for a prepared event page. The server can return the document as it was written.

Headings organize the information and links provide navigation. These native browser capabilities can already make a useful interface. A site whose content changes infrequently may need little application code.

As browsers developed, differences in supported features made compatibility a practical concern. Web standards provide shared expectations for document structure, presentation, and interaction. Even when we use a framework to build a page, the browser still interprets the files it receives.

Server-generated pages

Suppose event times and available seats now change regularly and are stored in a database. A server program can read the current records and construct an HTML response for each request.

In Figure 2, the server first reads the current data, then uses it to construct the document.

The browser receives the finished document without needing to know the database tables. Links and form submissions can provide navigation and actions. Repeated tasks such as selecting an operation, querying data, and constructing a response led to server frameworks that organize this work.

From the visitor’s perspective, the page can still work in the same way. A heading or link remains useful whether a person wrote the HTML ahead of time or a program generated it for this request.

Applications in the browser

What if we want to update the event list while keeping the rest of the page in place? Browser scripting made it possible to update part of an already loaded page. A browser application can request event data and use the response to change the visible list.

Figure 3 starts after the browser application has loaded. The later response contains data, which browser code uses to update the page.

Asynchronous requests and partial page updates became associated with the term AJAX. Its historical name includes XML, but this interaction does not require XML; applications commonly use JSON. The MDN explanation of Ajax describes that distinction.

Filtering events already loaded into browser memory can happen locally. Fetching newly saved availability requires a request to the server. Both may change a visible list, but only the second interaction crosses the network. Loading the initial HTML document and making that later data request are separate events.

Different arrangements, different tradeoffs

With server-generated pages, the server constructs the event-list HTML. With a browser/API arrangement, the server returns event data and browser code constructs the list. An API may serve both a website and a lobby display, and browser state can support immediate local interactions.

Those benefits bring coordination work. Clients and servers must agree on the data format, and the browser must handle waiting, empty results, and failed requests. A document may load successfully while its subsequent data request fails.

We can also combine these arrangements: an application may deliver useful HTML first and add richer interaction where needed. Adding JavaScript is useful when it serves that interaction, rather than being an improvement by itself. Whichever framework we choose, we still need to account for the network and preserve the application’s data.

We now have three ways to describe how a page gets its content. Next, we will run a small application that makes these distinctions visible: one button changes browser state and another requests saved data.

Check Your Understanding

1. What is the difference between the Internet and the Web?
2. How does serving a prepared HTML file differ from generating HTML for each request?
3. In a browser/API application, which program turns the returned JSON into visible text?
4. Why can a page load successfully even when a later data request fails?
5. What is one benefit and one additional responsibility of moving an interaction into browser code?