When people talk about Jamstack today, the conversation usually starts with modern tooling: static site generators, Git-based workflows, and CDNs fronting prebuilt HTML. But the deeper idea behind Jamstack—ship a pre-rendered site that was assembled from remote data earlier—is older than the term itself by decades.

This chapter (49 in our chronological history of web APIs) looks at the years 1990–1994, when the Web was young and HTTP was still evolving. The popular story is that the early Web was “just documents.” That’s true in spirit, yet it overlooks an important detail: the early Web’s document delivery model was also an interface model. The request/response pattern, URLs as stable identifiers, and servers that could generate responses programmatically became the conceptual scaffolding for web APIs—and for the build-time data fetching that Jamstack would later make mainstream.

To connect these dots responsibly, we need to be precise: nobody in 1991 was saying “build-time API consumption.” However, people were already doing a recognizable version of it: fetching remote resources over HTTP, transforming them, and publishing static outputs so that browsing was fast and simple.

1990–1992: HTTP as a Minimal Interface, Not Just a Transport

In the earliest period of the Web—roughly 1990 through the early 1990s—HTTP and URLs were designed for retrieving hypertext documents. Early HTTP was famously minimal: a client asked for a resource and the server returned it. Even if the content was “just text,” that exchange formed a programmable contract:

• Addressability: a URL identified a resource consistently enough to be bookmarked, shared, and re-requested.
• Uniform interaction: a small set of operations (initially centered on retrieval) behaved similarly across servers.
• Automation friendliness: because the protocol was simple, scripts could fetch content as easily as browsers could.

These properties matter for API history because “API-ness” isn’t only about JSON payloads or formal schemas. It’s about dependable interfaces that software can call. The early Web provided that model by default.

This is where the first faint outline of Jamstack-style thinking appears. If you can fetch a resource via HTTP predictably, you can also fetch it ahead of time and bake it into a site. In today’s language: you can consume a remote interface at build time.

1993: Browsers Popularize HTTP, and Developers Start Treating URLs Like Endpoints

By the time graphical browsers like NCSA Mosaic helped popularize the Web (notably in the early 1990s), developers and organizations were publishing more content and experimenting with ways to expose information through the same HTTP interface.

Not everything was called an “API,” but the behavior looks familiar:

• Servers published machine-consumable outputs such as plain text listings, indexes, and structured-ish content embedded in HTML.
• Teams built scripts that retrieved multiple pages and stitched them into curated navigation, “what’s new” pages, or mirrored archives.
• Early gateways bridged other systems into the Web, letting users query something non-HTTP using a web page as the front door.

Those gateways are especially relevant. Even when the final output was HTML for humans, the server was effectively translating between systems—exactly what many web APIs do now, just with different payload formats and fewer conventions.

1993–1994: CGI and the First Widely Recognized Pattern for “HTTP In, Computation Out”

One of the most important steps toward web APIs in this era was the rise of CGI (the Common Gateway Interface). CGI made “dynamic” responses commonplace: an HTTP request could invoke a program, which could then generate an HTTP response on demand.

Even if you never wrote a CGI script, you felt its impact: instead of a server only returning files, it could return computed results. Query strings (the ?key=value portion of a URL) became a simple way to pass inputs. That’s close to an API call in spirit: input parameters go in, computed data comes out.

From a Jamstack perspective, CGI also introduced an interesting split:

• On-demand mode: generate a page at request time for every user.
• Prebuilt mode: run the same program on a schedule (or manually), write the output to disk, and serve it as static HTML.

That prebuilt mode is a direct ancestor of build-time API consumption. The “API” might have been a CGI endpoint, a gateway, or even a remote set of pages scraped over HTTP. The method was similar: pull remote data, transform it, publish static artifacts.

Build-Time Consumption in an Era Before “Build Pipelines”

It’s tempting to assume build-time workflows required modern CI systems, but early Web teams had their own versions of build steps. They were often crude by today’s standards, yet the intent was the same: do expensive work ahead of time so the live site is fast and dependable.

Common early patterns included:

• Mirroring and aggregation: fetching remote resources periodically and republishing them locally to improve reliability and speed.
• Static index generation: generating directory listings, navigation hubs, or “catalog” pages from a set of files or upstream sources.
• Scheduled regeneration: running scripts on a timetable to keep content fresh while still serving static outputs.

If that sounds like Jamstack, it should. Jamstack formalizes the approach (and upgrades it with CDNs, immutable deploys, and dedicated API services), but the core optimization—move work from request time to build time—was already being discovered in the early 1990s.

Why This Matters for Web API History (Not Just Web History)

Web API history is often told as a straight line from “static pages” to SOAP to REST to GraphQL. That sequence is useful, but it can hide the earlier truth: the Web’s first interface was already a programmable interface. HTTP made it natural to retrieve resources automatically, and CGI made it natural to compute results from request parameters.

Once you see that, Jamstack’s build-time API consumption looks less like a modern invention and more like a refined return to early instincts:

• Stability over cleverness: keep the serving layer simple; do complex work elsewhere.
• Cacheability and replication: distribute static outputs widely because they’re easy to copy and hard to break.
• Interfaces over implementations: a URL is a contract; how the server produces the bytes can change without breaking clients.

If you’re building modern systems and want to think more clearly about automation, deployment, and data fetching, it helps to study these early constraints. They explain why build-time approaches keep reappearing whenever performance and reliability matter.

For more practical writing on automation-minded development (including ideas that align with build-time thinking), you can browse Automated Hacks.

A Modern Lens: HTTP Documentation as the Long-Running “API Surface”

One reason early web interfaces scaled into today’s API ecosystem is that HTTP stayed learnable. Even as features expanded beyond the early “retrieve a resource” model, the basics remained consistent enough that developers could build tools, libraries, and conventions on top.

If you want a concise, authoritative refresher on HTTP concepts that underpin both early web interfaces and modern web APIs, MDN’s overview is a solid reference: Web/HTTP overview.

Seen through that lens, Jamstack is essentially a disciplined way to exploit HTTP’s strengths: treat remote services as composable interfaces, fetch what you need before deploy, and keep runtime delivery predictable.

What Changed After 1994 (Preview of the Next Chapters)

By the mid-1990s, more interactive web features started to solidify: richer HTML capabilities, more common use of forms, broader commercial adoption, and a growing need for standardized behavior across servers and browsers. Those pressures pushed the Web from “documents with links” toward “applications with interfaces,” and web APIs became easier to name as a distinct thing.

But the key takeaway for 1990–1994 is simple: the Web began with an interface that could be automated, and developers quickly learned to precompute results and serve them statically. Jamstack didn’t invent that strategy—it inherited it.

FAQ

Did Jamstack exist in 1990–1994?

No. The term and the modern toolchain came much later. This chapter uses “Jamstack” as a modern lens to describe an older pattern: prebuilding content from remote sources and serving static outputs.

Were there “web APIs” in the early Web?

Not in the standardized, JSON-centric sense we often mean today. But there were programmable HTTP interfaces: predictable URLs, machine-fetchable resources, and CGI programs that accepted parameters and generated responses.

What’s the connection between CGI and APIs?

CGI established a widely used pattern where an HTTP request could trigger a program and return computed results. That’s an important stepping stone between static document delivery and modern API endpoints.

How is build-time API consumption different from runtime consumption?

Build-time consumption fetches data before deployment (or on a schedule) and bakes it into static assets. Runtime consumption fetches data on user requests. The early Web experimented with both, often prebuilding to keep serving fast and simple.