Networked apps, 1991 to now: CGI, JS, responsive, workers

Networked apps, 1991 to now: CGI, JS, responsive, workers begins with a practical question: how can a reader inspect the dated layers of networked applications without confusing a provider promise with a field observation?

Method for this question

The history of networked applications runs from server-side CGI in 1993, through JavaScript in the browser in 1995, Ajax in 2005, responsive web design in 2010 and service workers in 2015. Each step moved work to a different place: first to the server, then into the page, then into the connection itself, and finally into the device. The pattern is not a straight line of replacements. Older layers stayed in use, and most production systems today still run all of them at once.

A French-language documentary file, history of networked apps, covers this same arc across three periods: 1990 to 1999, 2000 to 2009 and 2010 to 2025, with a glossary and a note on local SEO in Montluçon. It is written for students, developers and people curious about technical history, which is a reasonable audience for a timeline that is still being extended.

What did CGI change in 1993?

The Common Gateway Interface, documented in 1993, gave a web server a standard way to hand a request to an external program and return whatever that program printed. Before it, a server mostly returned files that already existed on disk. After it, a URL could correspond to a calculation: a form submission, a database lookup, a counter, a search.

The important detail is where the work happened. CGI ran on the server, in a separate process, usually started fresh for each request. That model is simple to reason about and expensive to scale, because process startup and interpreter loading are paid on every hit. It also shaped early security practice, since user input now reached a program rather than a static path.

Later interfaces, from FastCGI to application servers and long-running workers, kept the same division of labour and removed the per-request process cost. The division itself, server holds the data and the logic, browser holds the form, has never gone away.

When did JavaScript reach the browser?

JavaScript arrived in the browser in 1995. Its first jobs were small: validate a form before sending it, swap an image on hover, open a window. The point was to avoid a round trip to the server for something the client could decide locally.

That shift introduced a second place where application logic could live, and with it a second set of problems. Two code paths had to agree on the same rules. A validation written in JavaScript could be bypassed, so the server still had to check. Browser differences meant the same script behaved differently across engines, which is why libraries and, later, standardised DOM APIs mattered so much.

By the end of the 1990s the browser was no longer a viewer. It was a runtime, and the argument over how much logic belonged in it had already started.

What to record

• the year each layer appeared
• what moved to the server or the browser
• the standard that defined it
• what still runs from the older layer

How did the browser become a platform?

The 2000 to 2009 period is when the browser stopped being treated as a document viewer with scripting attached and started being treated as a platform. Two things drove that. First, browser engines were reworked and, in several cases, shared or forked, which narrowed the gap between what a page could rely on in one browser and another. Second, the pieces needed for background requests were already present, and in 2005 the pattern of updating a page without a full reload was formalised under the name Ajax.

Ajax did not invent a new capability so much as name a combination: an asynchronous request, a data format, and a script that updates part of the page. The practical effect was that a web application could feel continuous. A user could type, and results could appear, without the page going blank and rebuilding.

That continuity has a cost that is easy to forget. State now lives in two places, the server and the running page, and they can disagree. Session handling, back-button behaviour, error states and partial failures all become design problems rather than accidents. The 2000s produced the vocabulary for those problems, and most of it is still in use.

What did mobile and offline change after 2010?

Responsive web design, described in 2010, answered a layout question: one set of content, many screen sizes. It replaced separate mobile sites and device detection with fluid grids, flexible images and media queries. The consequence for networked applications was that the same URL now had to work on a phone, a tablet and a desktop, and the network conditions behind those devices were not comparable.

Service workers, arriving in 2015, answered the network question. A service worker is a script that sits between the page and the network, and it can serve a cached response when the network is slow, absent or unreliable. That is what makes a web application usable offline, and it is also what makes caching a deliberate design decision rather than a browser default.

Together, responsive design and service workers moved part of the application onto the device. The server still holds the data of record, but the device now holds a copy, a cache policy and a queue of pending work. Anyone operating this kind of system has to think about version skew, cache invalidation and what happens when a user acts on data that is three hours old.

A realistic failure pattern

Is the older layer still running?

Yes, and this is the part that timelines tend to hide. A single request in a modern application can pass through a service worker, a JavaScript framework, an HTTP API, an application server and a database, with CGI-style process handling somewhere in the chain for a legacy endpoint that nobody wants to touch.

Each layer was added because the one below it could not do something. CGI could not keep state cheaply. Browser JavaScript could not reach the server without a reload. Ajax could not survive a dropped connection. Responsive design could not make a page load without a network. Service workers could not decide what the server should know. The stack is a record of unsolved problems, not a tidy progression.

For anyone maintaining systems today, that matters in a practical way. When something breaks, the question is which layer owns the failure: the cache, the script, the request, the process or the data. Naming the layer correctly is most of the diagnosis.

Errors and boundaries

A note on dates and sources

The dates above are the ones commonly attached to each development, and they mark publication or formalisation rather than first use. CGI was in use before its 1993 specification, and Ajax-like behaviour existed before the 2005 name. Treating a date as the moment a technique appeared everywhere is the most common error in technical timelines.

A useful check is to read the primary specification or the original article alongside any summary, including this one. The World Wide Web Consortium publishes the standards that govern much of what is described here, and its specification index is the place to confirm what a given version of a technology actually required.

The same dated habit of naming a year and a version applies when a project needs pictures of the ground rather than a browser. Choosing satellite imagery for an Asia project turns on resolution, revisit and licence, and the questions are practical: which sensors pass overhead, what free archives allow, and which countries fly their own Earth observation satellites. That is the subject of the dated web platform, a companion page to this timeline, written for teams who must pick an image before they commit.

What this does not prove

The dates mark when a technique was introduced and standardised, not when every site adopted it.

The Domain Host USA desk uses the documented fact, field observation, provider statement and editorial recommendation labels so readers can see what kind of sentence they are reading.

This note connects to the Infrastructure Field Desk, where the sample method and dated observations remain visible. Continue through Websites & WordPress for related decisions rather than treating one check as a complete review.