Web technology stacks – from LAMP to Janos

[2011-11-11] dev, nodejs, javascript, webdev
(Ad, please don’t block)
The classic stack of small- to medium-scale web technologies is LAMP (Linux, Apache, MySQL, PHP). With the rise of JavaScript and NoSQL databases, another stack is poised to replace it: Janos (client-side JavaScript, Node.js, NoSQL database).

LAMP – the incumbent

Linux and its accompanying software made it cheap for startups to run a web server. The LAMP stack comprises the following components:
  • Linux: Unix, free.
  • Apache: a web server.
  • MySQL: a relational database
  • PHP: a programming language for web back ends.
LAMP transformed the internet industry by making previously expensive technology available for free.

Janos – the challenger

JavaScript’s client-side popularity triggered many interesting developments. The Janos stack (which is short for JaNoNoS) is one of the results:
  • Client-side JavaScript
  • Node.js
  • A NoSQL database (such as MongoDB or CouchDB)
Comments:
  • The importance of client-side JavaScript. Client-side JavaScript is much more important to the stack than many people realize. It changes the paradigm from client-server to something whose nature is more distributed: On one hand, clients perform more computations and might even communicate with other clients. On the other hand, servers are less responsible for the application logic and mostly become a data tier. An example: FunctionSource assembles its page dynamically in the browser, via JavaScript. As a result, clicking a link usually means that only a part of the page has to be replaced instead of sending the complete page from server to client. There is also a fallback – if a browser does not support JavaScript, the assembling code is executed on the server and the result sent to the client.

    The next step is already in development: With browsers gaining offline functionality such as embedded databases, the data tier is more about syncing databases than about the server managing the data and the client displaying it.

  • Same language on client and server. Not having to switch languages when going from server to client is a big plus. You can reuse much code (validation code, domain logic, etc.) and don’t have to mentally switch between two languages during development. The ability to execute client-side code on the server enables fallbacks if a client does not support JavaScript (see example in the previous item).
  • Data – a confluence of events. It is very fortunate for JavaScript programmers that two things have become popular: JSON as a data transfer format (for web services etc.) and NoSQL databases. Both are perfect fits for JavaScript: JSON uses JavaScript syntax. Schema-less databases make things as flexible on the database side as they are on the programming language side; you get the advantages of object-oriented databases without their messiness.
  • Where is the operating system in the acronym? I initially thought that the stack should include a “U” for a Unix-based operating system. But the truth is that operating system matters remarkably little, now that Node.js has a proper Windows port.
In production systems, Node.js is often used as a complement to more mature servers. But that is slowly changing. Furthermore, it is already a terrific system for smaller projects.

Another proposed acronym

@evanpro tweets:
PSST! #node.js apps backed by a NoSQL database are now known as the #nono stack. Pass it on!
But while that name sounds nice, it does not mention a key ingredient of the stack: client-side JavaScript.