Paul Chien's blog

What is Node.js?

Paul Chien's picture

JavaScript has traditionally only run in the web browser, but recently there has been considerable interest in bringing it to the server side as well, thanks to the CommonJS project. Other server-side JavaScript environments include Jaxer and Narwhal. However, Node.js is a bit different from these solutions, because it is event-based rather than thread based. Web servers like Apache that are used to serve PHP and other CGI scripts are thread based because they spawn a system thread for every incoming request. While this is fine for many applications, the thread based model does not scale well with many long-lived connections like you would need in order to serve real-time applications like Friendfeed or Google Wave.

Node.js, uses an event loop instead of threads, and is able to scale to millions of concurrent connections. It takes advantage of the fact that servers spend most of their time waiting for I/O operations, like reading a file from a hard drive, accessing an external web service or waiting for a file to finish being uploaded, because these operations are much slower than in memory operations. Every I/O operation in Node.js is asynchronous, meaning that the server can continue to process incoming requests while the I/O operation is taking place. JavaScript is extremely well suited to event-based programming because it has anonymous functions and closures which make defining inline callbacks a cinch, and JavaScript developers already know how to program in this way. This event-based model makes Node.js very fast, and makes scaling real-time applications very easy.

Pyramid Introduction

Paul Chien's picture

Pyramid is a general, open source, Python web application development framework. Its primary goal is to make it easier for a developer to create web applications. The type of application being created could be a spreadsheet, a corporate intranet, or a social networking platform; Pyramid’s generality enables it to be used to build an unconstrained variety of web applications.
The first release of Pyramid’s predecessor (named repoze.bfg) was made in July of 2008. We have worked hard to ensure that Pyramid continues to follow the design and engineering principles that we consider to be the core characteristics of a successful framework:

Pyramid takes a “pay only for what you eat” approach. This means that you can get results even if you have only a partial understanding of Pyramid. It doesn’t force you to use any particular technology to produce an application, and we try to keep the core set of concepts that you need to understand to a minimum.

Pyramid concentrates on providing fast, high-quality solutions to the fundamental problems of creating a web application: the mapping of URLs to code, templating, security and serving static assets. We consider these to be the core activities that are common to nearly all web applications.

Pyramid’s minimalism means that it is relatively easy for us to maintain extensive and up-to-date documentation. It is our goal that no aspect of Pyramid remains undocumented.

Pyramid is designed to provide noticeably fast execution for common tasks such as templating and simple response generation. Although the “hardware is cheap” mantra may appear to offer a ready solution to speed problems, the limits of this approach become painfully evident when one finds him or herself responsible for managing a great many machines.

Pyramid is developed conservatively and tested exhaustively. Where Pyramid source code is concerned, our motto is: “If it ain’t tested, it’s broke”. Every release of Pyramid has 100% statement coverage via unit tests.

As with Python, the Pyramid software is distributed under a permissive open source license.

Design Patterns in JavaScript

Paul Chien's picture

 The fact that JavaScript is so expressive allows you to be very creative in how design patterns are applied to your code. There are three main reasons why you would want to use design patterns in JavaScript:

  1. Maintainability: Design patterns help to keep your modules more loosely coupled. This makes it easier to refactor your code and swap out different modules. It also makes it easier to work in large teams and to collaborate with other programmers.
  2. Communication: Design patterns provide a common vocabulary for dealing with different types of objects. They give programmers shorthand for describing how their systems work. Instead of long explanations, you can just say, “It uses the factory pattern.” The fact that a particular pattern has a name means you can discuss it at a high level, without having to get into the details.
  3. Performance: Some of the patterns we cover in this book are optimization patterns. They can drastically improve the speed at which your program runs and reduce the amount of code you need to transmit to the client. The flyweight and proxy patterns are the most important examples of this.

There are two reasons why you might not want to use design patterns:

  1. Complexity: Maintainability often comes at a cost, and that cost is that your code may be more complex and less likely to be understood by novice programmers.
  2. Performance: While some patterns improve performance, most of them add a slight performance overhead to your code. Depending on the specific demands of your project, this overhead may range from unnoticeable to completely unacceptable.

Implementing patterns is the easy part; knowing which one to use (and when) is the hard part. Applying design patterns to your code without knowing the specific reasons for doing so can be dangerous. Make an effort to ensure that the pattern you select is the most appropriate and won’t degrade performance below acceptable limits.

[1] Ross Harmes and Dustin Diaz (2008). Pro JavaScript Design Patterns

Enter Ext JS: The Best of JavaScript Libraries

Paul Chien's picture

A long time ago in a galaxy far, far away (more precisely, early 2006, the planet Earth), a gentleman by the name of Jack Slocum developed a set of extension utilities to the YUI library. These utilities rapidly gained popularity within the YUI community and were quickly organized into an independent library called YUI-Ext. In fall 2006, Jack released the .33 version of this new library under the terms of the Berkeley Software Distribution (BSD) license.

After a while, before 2006 was over in fact, the name of the library was changed to Ext, because it was starting to develop independently of YUI at that point. In fact, support for other libraries was beginning to be developed within Ext.

In 2007, Jack formed a company to further advance the development of Ext, which at some point thereafter began to be known as Ext JS. On April 1, 2007, Ext JS 1.0 was released.

In a short period of time, Ext JS evolved from a handy set of extensions to a popular library into what many people, including yours truly, feel is the most mature JavaScript UI development library available today.

Ext JS is focused on allowing you to create great user interfaces in a web app. In fact, it is best known for its top-notch collection of UI widgets. It allows you to create web apps that mimic the look and feel of desktop native applications, and it also allows you to mimic most of the functionality those applications provide. In short, Ext JS enables you to build true RIAs.

It’s not all about widgets, though, as we’ll see. There are a lot of useful utility-type functions in Ext JS as well. Need some Ajax functionality? Check. Need some string manipulation functions? It’s got those too. Need a data abstraction layer? Ext JS has you covered.

[1] Frank W. Zammetti (2009). Practical Ext JS Projects with Gears