Blog Post

Node.js and the JavaScript Age

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

Editors Note: This post was published on Friday, April 8 on the Metamarkets Group Blog by CTO Mike Driscoll. Metamarkets is a portfolio company of True Ventures, which is also an investor in GigaOM. Om Malik is also a venture partner at True. The Metamarkets post follows.

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:

  1. 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.
  2. 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.
  3. 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 Document Object Model, using Javascript. AJAX achieved this, but when your server-side LAMP templates are 10 percent HTML and 90 percent 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.

Image courtesy of Flickr user GE Healthcare.

7 Responses to “Node.js and the JavaScript Age”

  1. clausewitz

    I’ve been in or around this business throughout these ten-year cycles, and yes, I am now migrating my LAMP stack to Node.js and CouchDB: I believe they are the future of web coding, along with HTML5. But then, I have believed several now-fading technologies were the future. When will we next encounter another similar shift? Will we stabilize in a javascript universe? Or is this track another dead end? Is it leading somewhere else entirely?

    Interior to the suggested large scale cycles we can see smaller epicycles, representing significant turn-overs of web coding discipline within that larger framework. Just think of the rapid uptake experienced by XML, CSS, Ajax, Flash, JSON, and even the magical *group psychology* transition from perceived “toy” javascript to “advanced” javascript, enabling our current trajectory. Ten-year cycles hardly do the velocity and nuance of this change process justice.

    These subsidiary changes happened in one to three years, despite ineluctable institutional friction. Some approaches stuck, and others did not. But now Microsoft has finally stepped out of the way, and perhaps equally important, the old-school semanticists at W3C have yielded to the young turks of WHATWG. The brakes are off. Everything feels like we are in for a free-wheeling ride.

    Even though “school trained” software engineers should have a leg up on catching the drift, they rarely surpass the “very bright high school hacker” types who come on board with no preconceptions. Depending on our disposition, we can label this acceleration and unpredictability of change good or bad. Depending on where we sit on the adoption curve, we are that far from writing obsolescent code on delivery. And that curve may soon become, essentially, exponential.

  2. I think it would be better if you give a broader perspective on UI development rather than focusing on the falicies of the Web.

    1990-1996 was actually very event-driven from a UI perspective via X/Motif, Visual Basic, VC++, etc…

    1997-2004ish was the HTML/LAMP/Java age. Were you have static, HTML driven UIs like you mentioned.

    2005-present is the move BACK TO EVENT DRIVEN UIs! Nothing new here! Nothing revolutionary here!

  3. node.js is great and the architecture support heavy concurrency. However, let’s not forget that this is not new – there is nothing ground breaking on the OS level that is different or new. Select/epoll based servers have long been there.
    Also, I think this is a pretty weak argument : “Since we’re currying Javascript functions on the server-side, we ought to write in Javascript. “. Why is that?

  4. DarrylS

    Sorry if this is a silly question but I am curious if node.js is used to, as you say ‘ship the application to the client’? Or do you use a traditional web server (even nginx) used to do that and node.js only handles the stream events as part of the client interacting with the app? Wouldn’t such a separation of responsibilities impose some same origin limitations?

  5. Ben Nash

    I recently started learning Ruby on Rails and was introduced to Sinatra and then Node.js and I’m very impressed with all these new parts of the new stacks.

    Thanks for the article.

  6. Hamranhansenhansen

    The problem is that JavaScript could be the new XHTML: too fragile for the Web. One JavaScript error and everything breaks. Bad browser? Everything breaks. What we want to do for academic purity rarely works on the Web.