By on September 20, 2010 12:24 am

Promises are a well-established mechanism for modeling future or asynchronous actions. Promises allow asynchronicity while maintaining the core programming principles of composability and encapsulation. Writing asynchronous code in JavaScript can often be a confusing exercise due to the extensive need for callbacks, but promises help to define composable units of asynchronicity to encapsulate actions and reliably separate caller and callee’s concerns.


Promised-IO utilizes promises as an abstraction for I/O operations on top of Node, Narwhal/Rhino, and the browser (where possible). This serves two purposes. First, this package provides the benefits of promise usage: clean separation of concerns and proper encapsulation of eventual values. Second, Promised-IO provides a consistent normalized interface for I/O that will work on multiple platforms without sacrificing any of the advantages of asynchronous I/O, making it easy to build modules that can be used by developers on many platforms.

Nodules: Better Module/Package Handling for Node.js

By on September 15, 2010 5:25 am

Nodules is a module loader for Node that provides a powerful set of features for application development and distribution. Nodules was written to solve the two major missing pieces of functionality I needed for efficient application development: flexible dependency resolution and module reloading. Nodules runs on top of Node’s simple base module loader, and nicely compliments the base loader with additional functionality. Furthermore, it provides this functionality using idiomatic asynchronous techniques, a smart package layout, and powerful module reloading.

Real-time Comet Applications on Node with Tunguska

By on July 19, 2010 4:34 am

Node is a server-side JavaScript platform that is known for being well suited for Comet-style applications that utilize long-lived connections to allow applications to send messages from the server to the browser asynchronously. In fact, the beginning of the front page of starts out with an example of a web application that delays for a couple seconds before sending a response without any type of blocking; the code is asynchronous and efficient.

However, building a real-life real-time application involves more than just a platform that gives you asynchronous communication, there are a number of other important techniques to understand. We will look at these techniques and introduce project Tunguska that provides some helpful tools to assist in building applications. While a number of Comet projects out there attempt to provide a black box solution to Comet, Tunguska recognizes that most real-time applications involve deep integration into the application and its security, messaging, and data structures. Consequently Tunguska is a set of tools for building real-time applications rather than a closed black box that can’t easily be integrated with. Let’s look at some of these tools.

Asynchronous CommonJS Modules for the Browser (and Introducing Transporter)

By on July 16, 2010 12:15 am

Modules are an integral architectural piece of robust application development since they allow individual components to be developed with proper dependency management. Modules can specify dependencies and these can be automatically resolved and loaded to bring various pieces together automatically. In application development this is vastly more scalable and easier than having to track all the different dependencies and manually load modules or insert script tags.

The CommonJS module format is increasingly ubiquitous as the de facto module format for JavaScript. However, if CommonJS modules, by themselves, are directly executed, they require synchronous loading of modules. Synchronous loading is known to be very problematic in the browser since it locks the browser user interface, requires eval-based compilation of scripts which confuses debuggers, and is less efficient than using standard script tags.

JSGI vs Connect for Node Middleware

By on June 11, 2010 4:08 pm

JSGI (JavaScript gateway interface) is the broadly adopted standard for server-side JavaScript web applications and middleware. JSGI is designed specifically for ease of use in asynchronous, evented environments, and consequently JSGI has been a perfect fit building applications on Node. JSGI-Node has existed for sometime as lightweight JSGI server/adapter for running JSGI-based applications on Node. However, “Connect” was recently released as a new alternate middleware system for Node. This spurred me to make sure JSGI-Node was optimized, and compare the Connect middleware design to JSGI.

Pintura JSGI Modules

By on March 4, 2010 1:18 am

Pintura is a REST-style web framework that provides a comprehensive solution for Ajax-based thin-server applications. However, Pintura has a very modular design, and many of the modules in Pintura are extremely useful as standalone JavaScript/CommonJS components that can be used with Node, Narwhal and other projects. Let’s look at the JSGI middleware modules. JSGI middleware modules are designed to be used in a JSGI HTTP request handling stack, adding functionality to a web application. An example of using a JSGI middleware: = MiddleWare( // wrapped my application with middleware
     ... my JSGI application ...

CommonJS Utilities

By on March 2, 2010 10:02 am

CommonJS Utils is a collection of general purpose CommonJS-compliant modules. These modules can be used on Narwhal, Node, and other CommonJS platforms. The modules include:

  • json-schema.js – This is a JSON Schema validator module. It can be used to validate data structures using JSON schema definitions. For example:
    var validate = require("json-schema").validate;
    var data = {name: "Test"};
    var schema = {
      properties: {
         name: {type: "string"},
         age: {type: "number"}
    var validation = validate(data, schema);
    validation.valid -> false
    validation.errors -> indicates that age was not provided
    data.age = 30;
    var validation = validate(data, schema);
    validation.valid -> true

    This module also supports using standard native constructors as type definitions. The schema above could be written
    more briefly:

    var schema = {
      properties: {
         name: String,
         age: Number

Getting Started With Pintura

By on January 25, 2010 1:07 am

Pintura is a REST-style web framework that utilizes a layered approach to application development that facilitates straightforward, well-designed rich internet applications. Pintura forms the core web framework for Persevere 2.0, and consists of a powerful data modeling and persistence framework called Perstore, in combination with a REST-style web framework. You can read more about the goals and principles behind Pintura, but here we will look at how to get started writing applications.

Pintura-based applications normally consist of server-side data models with three layers: data stores, store models, and model facets. On top of this, different representation handlers (for serializing data to different formats) can be defined, but Pintura comes with a good set of these (including JSON, JavaScript, multipart, and Atom), so usually that is not necessary. This provides a well-structured separation of concerns, distinguishing storage configuration (data stores), core data logic (models), varying capabilities of access to the data (facets), and data serialization (representations). Perhaps the easiest way to understand this approach to take a look at an example application.

Introducing Pintura

By on January 22, 2010 2:43 am

Pintura is a CommonJS/JSGI-compliant, server-side JavaScript-based framework for building rich Internet application with the REST architectural style, thin storage-oriented server design, and the consistency of end-to-end JavaScript. The Pintura framework forms the core of Persevere 2.0, and is the first framework built to run on multiple CommonJS platforms like node.js, Narwhal/Jack, and Flusspferd/Zest. It utilizes a layered approach to application development that facilitates straightforward, modular web applications.

Pintura is not a traditional MVC web server framework, which often conflate presentation and interaction concerns across the client and server, but rather follows the REST prescription of maintaining simple storage and serialization oriented server also known as thin server architecture or SOFEA. Pintura is designed to cleanly separate the concerns of presentation and interaction on the client, and storage and model logic concerns on the server. This design fits perfectly with comprehensive JavaScript frameworks like Dojo, General Interface, Cappuccino, YUI, and ExtJS that provide client-side MVC. In particular, Dojo has excellent support for standards-based JSON REST interaction that matches perfectly with this server-side framework.

CommonJS/JSGI: The Emerging JavaScript Application Server Platform

By on January 19, 2010 2:25 am

CommonJS (formerly known as ServerJS) has become the essential hub around the development of server side JavaScript (SSJS). SSJS for years has suffered from fragmentation, but the CommonJS project has provided the momentum to bring different frameworks together and start building interoperable modules. SSJS is ripe with potential; JavaScript has been soaring in popularity and the ECMAScript 5 specification was recently accepted. JavaScript has proven itself as the language of the web’s client-side (even ActionScript is a derivative of JavaScript). The opportunity to use the same language on both client and server is certainly most realistic and viable with JavaScript as it avoids the need for translation.


CommonJS has focused on developing critical APIs for building reusable modules, particularly for server-side JavaScript environment. The server-side is generally based around database interaction, file I/O, HTTP serving, and the generation of data formats and HTML, whereas the client-side is based around DOM manipulation and the browser object model. There are certainly APIs that can be used on both sides, and JavaScript on the client and server invites the reuse of APIs where possible. The WebWorker, Indexed Database, and XHR APIs are promising to be enormously beneficial on the server side, and with excellent client server consistency. But still the server side requires special attention, and CommonJS is bringing the needed standards and conventions.