Server-side JavaScript a decade before Node.js with Netscape LiveWire
Tags: javascript, webdev, history
Published: 2021-09-12 15:08:21

---
title: Server-side JavaScript a decade before Node.js with Netscape LiveWire
published: true
description: An overview of Netscape LiveWire, one of the very first server-side implementations of JavaScript
tags: javascript, webdev, history
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uj8sc40sas6meoejie65.jpg
---
The year is 1996. JavaScript is less than a year old, making its grand public debut with the release of Netscape Navigator 2.0 to [a both intrigued and somewhat bewildered web development community](https://webdevelopmenthistory.com/1996-javascript-annoyances-and-meeting-the-dom/ "1996: JavaScript Annoyances and Meeting the DOM - webdevelopmenthistory.com"). We are at the very beginning of what would become ["The First Browser War"](https://en.wikipedia.org/wiki/Browser_wars#First_Browser_War_(1995%E2%80%932001) "More about the First Browser War on Wikipedia"): how JavaScript evolved and grew in that context is a story often told, **but did you know that JavaScript was also used as a server-side scripting language as early as 1996?**

Today we're going to have a look at **Netscape LiveWire**, an extension of *"Netscape Enterprise Server"* that made **writing server-side JavaScript applications possible more than 10 years before it was cool.**

---

## The dawn of server-side J(ava)Script

While Netscape and Microsoft were distributing their browser free of charge, both companies were also in the business of  selling enterprise-level software to companies and institutions looking for a *"one stop shop"* solution to their web server and web development needs. This constituted an important part of Netscape's business model, and something Microsoft invested in as part of their [newfound interest for the internet](https://www.wired.com/2010/05/0526bill-gates-internet-memo/ "May 26, 1995: Gates, Microsoft Jump on 'Internet Tidal Wave' - wired.com").

We therefore had Microsoft on one side with the *"Internet Information Services"* (IIS) suite, featuring their [*"Active Server Pages"* (ASP)](https://en.wikipedia.org/wiki/Active_Server_Pages) server-side scripting technology, and *"Netscape Enterprise Server"* with its **LiveWire** application development solution on the other.

While ASP did support **JScript** _(Microsoft's early implementation of JavaScript)_, it was only one of the 3 languages supported, alongside **VBScript** and **PerlScript**. Netscape chose a different approach and went *"all in"* with server-side JavaScript, which was the centerpiece of LiveWire. 

---

## How did LiveWire's server-side JavaScript work?

Looking back at [how LiveWire worked](https://docs.oracle.com/cd/E19957-01/816-6411-10/contents.htm "Official Server-side Javascript 1.2 documentation") from today's perspective is both fascinating and slightly disorientating. We're only a decade - but galaxies away - from **Node.js** and its event loop-based, single threaded model. Netscape's server-side implementation of JavaScript was much more of an HTML preprocessor than a multi-purpose runtime, not dissimilar to early-days PHP in some of its inclinations.

### Everything starts with the `<server>` tag

LiveWire introduced a `<server>` tag, the likes of ASP's `<%` and PHP's `<?php` delimiters, used to determine which parts of a given HTML file contained JavaScript logic that needed to be processed on the server before being sent to the client. A global `write()` function was used conjointly to _"print"_ content on the page.

```html
<!-- Welcome to mid-90s HTML. 
Tags are SCREAMED, because everybody is very excited about THE INTERNET. -->
<HTML>
  <HEAD>
    <TITLE>My awesome web app</TITLE>
  </HEAD>
	<BODY>  
    <H1>
      <SERVER>
      /* This tag and its content will be processed on the server side,
      and replaced by whatever is passed to `write()` before being sent to the client. */
      if(client.firstname != null) {
        write("Hello " + client.firstname + " !")  
      }
      else {
        write("What is your name?")
      }
      </SERVER>
    </H1>
    
    <FORM METHOD="post" ACTION="app.html">
      <P>
        <LABEL FOR="firstname">Your name</LABEL>
        <INPUT TYPE="text" NAME="firstname"/>        
      </P>
      
      <P>
        <INPUT TYPE="submit" VALUE="Send"/>
      </P>
    </FORM>
  </BODY>  
</HTML>
```

To prevent unnecessary cluttering of the HTML files, backquotes could be used as a shorthand for the combination of `<server>` and the `write()` function, making for a smaller footprint:

```html
<!-- Long form: -->
<H1><SERVER>write("Hello " + client.firstname + " !")</SERVER></H1>

<!-- Short hand: -->
<H1>`"Hello " + client.firstname + " !"`</H1>
```

### The `jsac` compiler and `.web` files

LiveWire apps required a compilation step. [Using the `jsac` compiler](https://docs.oracle.com/cd/E19957-01/816-6411-10/appdev.htm#1046520 "More about the jsac compiler in Netscape LiveWire's documentation"), users had to merge all of the app's HTML and JavaScript resources into a single `.web` file. The idea was that every HTML file added to this bundle was to become an entry point for the app, accessible via a url, while loose JavaScript files were meant to be shared resources, allowing to define global functions that could be used in `<server>` calls across multiple HTML files. 

The resulting `.web` files contained bytecode that could then be executed by Netscape's JavaScript runtime, waiting for HTTP requests to come in.

```bash
# Example: Compiling a LiveWire app made of a single HTML file.
jsac -i app.html -o app.web

# Example: Compiling a LiveWire app made of multiple HTML and JS files.
# The `-f` option targets a file containing references to all the files that need to be bundled together.
jsac -f files_list.txt -o app.web 
```

Netscape's runtime was **multi-threaded** and allowed for sharing objects between threads of a given application. Shared objects could be accessed and modified by any thread, which made it easy to share state between clients but also came with important thread safety risks. [A locking mechanism was available, but not automatically enforced](https://docs.oracle.com/cd/E19957-01/816-6411-10/sessmgmt.htm#1012796 "More about LiveWire's thread locking mechanism in the official documentation").

---

## What were some of its core features?

LiveWire was built for *"enterprise"* customers, and some of the architectural decisions that were made could be explained by this constraint. 

There was for example a clear focus on **database connectivity**, **interoperability with Java classes** **and native libraries** _(LiveConnect and `jsacca`)_, all of which making it easier for potential clients to integrate LiveWire into their existing infrastructure and codebases, at least in theory.

Netscape's server-side JavaScript implementation also came with APIs for **session management**, **forms processing**,  **file system access**, and even **sending emails** in later versions, which made of LiveWire a seemingly complete and viable solution for backend development.  

---

## Was LiveWire a success?

LiveWire was a very interesting and innovative piece of software, but never came come close to becoming the gold standard of *"professional"* server-side development of the late nineties. While it is hard to pinpoint a single reason why that was the case, here are a few clues, in no particular order:

- **Having to compile and bundle everything, including HTML content, made for a somewhat cumbersome developer experience**. [This review of LiveWire's development cycle by Philip Greenspun](https://philip.greenspun.com/wtr/livewire.html) describes these woes in great detail. LiveWire's direct competitor, Microsoft ASP, didn't require a compilation step.
- **JavaScript was a very young language at the time.** It still had to prove itself, and hadn't yet become popular enough to have a large pool of developers and libraries available. 
  This [article by R. Allen Wyke from 1999](http://sunsite.uakom.sk/sunworldonline/swol-08-1999/swol-08-webmaster.html "JavaScript comes of age - 1999 article by R. Allen Wyke") is a good example of how, even a few years later, JavaScript had to be advocated for. 
- **Netscape didn't necessarily invest as much as its competitors**, and LiveWire quickly lagged behind in terms of features. [This 1997 article from the Chicago Tribune](https://www.chicagotribune.com/news/ct-xpm-1997-07-18-9801160234-story.html "July 1997 article from the Chicago Tribune comparing Netscape LiveWire to its competitors") shows how LiveWire started to lag behind the competition, a year after its launch.

---

## What did LiveWire become? 

*"Enterprise-grade"* software means long term support. Through successive acquisitions, [_"Netscape Enterprise Server"_ was rebranded multiple times](https://en.wikipedia.org/wiki/Oracle_iPlanet_Web_Server#Release_History) and merged with other technologies, which explains why [LiveWire's documentation](https://docs.oracle.com/cd/E19957-01/816-6411-10/contents.htm "Netscape server-side Javascript documentation on docs.oracle.com") can be found on Oracle's website. 

It is a bit difficult to trace exactly how LiveWire evolved in that context, and figure out when exactly it was discontinued. 

**Its legacy is an interesting one:** while it is not hard to find comments on the internet about how seemingly hard and unpleasant it was to work with this technology [(1)](https://stackoverflow.com/questions/18350910/netscape-enterprise-server-and-server-side-javascript-ssjs-vs-node-js/26321883#26321883 "Stackoverflow post about LiveWire") [(2)](https://philip.greenspun.com/wtr/livewire.html#:~:text=Reader's%20Comments "A 1998 comment about how 'LiveWire development [...] is pretty lame'") [(3)](https://philip.greenspun.com/wtr/dead-trees/53012.htm#:~:text=Netscape%20LiveWire "Message from a user detailing frustrating issues encountered while working on a LiveWire project"), it remains an important  piece of JavaScript's history, as it was one of the very first attempts at making the language live outside the browser and compete on the *"for business"* market of software development solutions.