The mid-1990s baseline: the browser as a document viewer (with ambitions)

In the mid-1990s, most sites were built around server-rendered HTML. The “API surface” of the web wasn’t a set of JavaScript interfaces like we think of now. It was primarily:

• HTML forms as the primary input mechanism
• HTTP requests as the only reliable way to compute and persist anything
• CGI scripts (and similar server-side programs) as the dynamic engine

Users typed into a form, clicked Submit, and the browser navigated to a new page. Even when the “application” concept started to emerge, the interaction model was still dominated by full-page reloads.

1995: JavaScript arrives—and the main-thread problem is born

By the time JavaScript appeared in browsers (first as an embedded scripting language intended for lightweight interactivity), it introduced an important architectural reality: the script ran in the same thread of execution that handled UI and rendering. In modern terms, we’d call that the “main thread.”

Even in this early period, developers could feel the constraint. If a script performed too much work in one go—string parsing, large loops, naive animation, or repeated DOM-related operations—browsers could appear to stall. In 1995–1998, CPUs were slower, JavaScript engines were young, and performance headroom was limited. That made blocking behavior more visible than it might be today.

This is a key historical point in web API evolution: the moment the browser became programmable, developers immediately ran into the question of where computation should happen. At first, the only realistic answer was “not in the browser—do it on the server.”

CGI and forms: the original “background processing” was offloading to the server

From 1995 through 1998, one of the most common patterns for “doing work” was a form POST (or GET) to a server endpoint that ran a CGI program. CGI wasn’t a web API in the JavaScript sense, but it was an integration contract that shaped how the web behaved:

• The browser collected input through <form> elements.
• It sent data over HTTP to the server.
• The server did the heavy lifting (validation, search, calculations, database access).
• The browser displayed the new HTML response.

From a user experience perspective, this pattern acted like “background processing,” except the “background” was really just “somewhere else,” and the UI was not responsive during navigation. The limitation wasn’t just speed; it was control. The browser couldn’t easily keep the current page interactive while requesting and processing new information.

That lack of control is exactly what later APIs—first incremental DOM scripting techniques, later asynchronous networking, and eventually Web Workers—would try to improve.

Early dynamic integration: scripts, frames, and the search for non-blocking UX

The 1995–1998 web experimented with a handful of techniques that hint at a future where work could happen “off to the side” while the user kept reading or clicking:

• Client-side validation with JavaScript to avoid round trips (fast, but limited, and could still freeze the page if done poorly).
• Frames to update one region of a page without replacing the whole window (a UI workaround rather than true background processing).
• Plug-ins and applets (like Java applets) that ran in their own execution environments, sometimes feeling “separate” from the page’s script runtime.

These weren’t Web Workers, and it would be inaccurate to pretend they were. But they revealed a consistent developer desire: keep the page responsive while something else computes or loads.

Frames in particular are a revealing artifact. If one frame was loading, another frame could sometimes remain visible. This gave an early taste of partial updates, even though the underlying model was still document navigation and the scripting model still wasn’t designed around safe concurrency.

Browser scripting APIs (1995–1998): small knobs, big expectations

In this era, the “web API history” story isn’t about a neat set of standardized interfaces—it’s about browsers exposing just enough hooks to make developers ambitious. JavaScript could read and write certain document properties, handle events, and manipulate limited page elements (depending on browser and version). The result was a new class of problems:

• Long tasks: code that runs too long before yielding control back to the browser.
• Unpredictable performance: different browsers and machines behaved very differently.
• Compatibility friction: scripts written for one browser’s model might break in another.

Developers didn’t yet have a robust vocabulary for “main thread,” “event loop,” or “concurrency hazards,” but the symptoms were there. The browser could become unresponsive. Animations would stutter. Input would lag. And the only universally safe “escape hatch” was to do less in the browser and more on the server.

The conceptual bridge: from “don’t compute in the browser” to “compute without blocking”

If you draw a straight line from 1995–1998 to modern Web Workers, the line is not “workers existed in early Netscape.” The line is more subtle:

1. Browsers became programmable (JavaScript and events).
2. Programmability created workload (validation, effects, data manipulation).
3. Workload revealed blocking behavior (UI freezes).
4. Developers invented coping strategies (server offload, smaller scripts, frame-based UI tricks, plug-in runtimes).
5. The platform eventually standardized better answers (asynchronous APIs, then dedicated background execution like Web Workers).

The mid-1990s era matters because it set expectations: users wanted interactivity, and developers wanted computation. The web could not remain a static document system. But making it dynamic introduced the need for non-blocking behavior.

Why Web Workers are a web API history milestone—even though they came later

Web Workers (standardized much later as part of the broader HTML platform evolution) are best understood as a response to a problem that existed from the start of browser scripting: single-threaded UI plus arbitrary script equals fragile responsiveness.

From a historical standpoint, Web Workers represent a turning point in web APIs because they formalize a safe-ish model for parallelism:

• Workers run in a separate context from the main page.
• Communication happens via message passing rather than shared DOM access.
• The main UI thread stays available for input, layout, and painting.

Those design choices make more sense when you remember the chaos of early scripting compatibility. The platform learned—slowly—that giving every script full access to everything while also allowing parallel execution would be a recipe for race conditions and inconsistent behavior. Message passing is, in part, a lesson learned from years of “dynamic web” experimentation.

If you want the modern canonical reference for the Web Workers API, MDN’s documentation is a solid starting point: Web Workers API on MDN.

Lessons for modern developers looking back at 1995–1998

Looking at this era through a Web Workers lens can improve your intuition about web APIs today:

• API constraints shape architecture. If the browser can’t do background work, you either do less, or you push work elsewhere (server, plug-in, separate document).
• “Dynamic web” started as navigation plus scripts. CGI and forms were the integration points; JavaScript added client-side polish but not true concurrency.
• Performance is a product feature. Even simple interactivity can become unusable if long-running tasks block the UI—an issue visible even with the small scripts of the late 1990s.

When you build modern web automations or performance-sensitive UI, it’s worth remembering that the web’s earliest dynamic systems were built under much harsher constraints. If you enjoy digging into the practical side of automation and implementation details, you may also like some of the experiments and write-ups at https://automatedhacks.com/.

FAQ: Web Workers and the 1995–1998 web

Did Web Workers exist in 1995–1998 browsers?

No. In 1995–1998, browsers were just beginning to support scripting, and there was no standardized background thread API comparable to Web Workers.

How did developers handle “background” tasks in the mid-1990s?

Most heavy work was moved to the server using CGI and form submissions. Some experiences used frames or plug-in runtimes to approximate partial updates or separate execution contexts, but these were workarounds rather than a standardized browser API for background processing.

Why do Web Workers use message passing instead of letting workers modify the DOM?

Separating workers from direct DOM access helps avoid concurrency issues and keeps rendering predictable. Historically, the web learned that mixing unrestricted shared state with parallel execution would cause reliability and compatibility problems.

What problem do Web Workers solve that early JavaScript couldn’t?

They allow CPU-intensive computation to run without blocking the main UI thread, improving responsiveness. Early JavaScript ran on the same thread as the UI, so heavy work could freeze the page.