Three months ago, we decided to tear down the framework we were using for our dashboard, Python’s Django, and rebuild it entirely in server-side JavaScript, using node.js. (If there is ever a time in a start-ups life to remodel parts of your infrastructure, it’s early on, when your range of motion is highest.)

This decision was driven by a realization: the LAMP stack is dead. In the two decades since its birth, there have been fundamental shifts in the web’s make-up of content, protocols, servers, and clients. Together, these mark three ages of the web:

I. 1991-1999: The HTML Age.

The HTML Age was about documents, true to Tim Berners-Lee’s original vision of a “big, virtual documentation system in the sky.” The web was dominated by static, hand-coded files, which web clients crudely formatted (with defaults that offend even the mildest of typographiles). Static documents were served to static clients.

II. 2000-2009: The LAMP Age.

The LAMP Age was about databases. Rather than documents, the dominant web stacks were LAMP or LAMP-like. Whether CGI, PHP, Ruby on Rails, or Django, the dominant pattern was populating an HTML template with database values. Content was dynamic server-side, but still static client-side.

III. 2010-??: The JavaScript Age.

The JavaScript age is about event streams. Modern web pages are not pages, they are event-driven applications through which information moves. The core content vessel of the web — the document object model — still exists, but not as HTML markup. The DOM is an in-memory, efficiently-encoded data structure generated by JavaScript.



LAMP architectures are dead because few web applications want to ship full payloads of markup to the client in response to a small event; they want to update just a fragment of the DOM, using JavaScript. AJAX achieved this, but when your server-side LAMP templates are 10% HTML and 90% JavaScript, it’s clear that you’re doing it wrong.

To recognize this means shifting our view of the server from a document courier (HTML Age), or a template renderer (LAMP Age), to a function and data shipper. The principal role of the server is to ship an application to the client (JavaScript), along with data (JSON), and let the client weave those into a DOM.

The secondary role of the server is to listen in on a stream for events (a new edit, a message, or ticker change) and efficiently push responses back to clients.

For both of these roles, node.js is an ideal serving architecture. Since we’re currying JavaScript functions on the server-side, we ought to write in JavaScript. We can shift computation from server to client with little impedance (for example, we no longer need to maintain two sets of our custom string formatting libraries).

With regard to responding to event streams, node.js is ideal. Its asynchronous, non-blocking architecture means it’s incredibly fast. It uses HTTP 1.1, keeps its connections open, and a single server can handle thousands of open connections at once.

Finally, it’s worth considering that events are simply packets of data, and the emerging lingua franca of data on the web is JSON. This is what client-side applications receive when a ticker moves, or a message arrives. This is, again, a native format for node.js.

The JavaScript age brings us closer to a web that is not a global digital library, but a global digital nervous system, whose implications we are only beginning to apprehend.