How Asynchronous JavaScript Promises Work

The Promise object in the proposed ECMAScript 6 specification makes performing asynchronous operations easier. Not necessarily Ajax requests, but local function calls. These functions themselves may or may not depend on an external resource, but the key to promises is that the API looks and behaves the same. Promises, out of the box, are asynchronous. Let's illustrate the idea with some code:

Wrapping Functions In Web Workers

It's commonplace, now that JavaScript has matured, and is continuing to mature, to implement heavy-duty data-crunching operations in the front-end. For instance, rather than calling an API to reduce a large set, it's easier to just reduce it in the browser. The wins are that you don't have to support an API to do this, and there's no network overhead. However, there's a new kind of overhead in that the browser will eat up valuable seconds while performing these long-running tasks. And since JavaScript code is single-threaded, these tasks diminish DOM responsiveness.

Tornado and Blob Chunking

The Tornado web framework is a great choice for implementing an application that can anticipate lots of client connections. It's claim to fame is that it can support thousands of concurrent users. And it does all of this in a single-threaded IO loop. Which can block on certain IO operations — like serving large blob objects.

The trick with Tornado is to understand where this blocking behavior occurs, and how that contrasts to the threaded-approach of handling many client connections concurrently. With a threaded-approach, the concept of a request handler, the code the application developer writes to fulfill user requests, doesn't need to do anything special. The framework takes care of maintaining thread management for any given request. With IO loops, we need to be conscientious of the fact that only one request handler is handled at any given time. So the trick is this — exit from the request handler as quickly as possible.

Diesel Web

Diesel Web is a Python web application framework containing very simplistic components. Rather than focusing on providing a rich set of application components, the focus is on raw performance. With this aspect of the web application taken care of, developers can focus on functionality, with the more freedom than most other frameworks can offer.

The performance offered by Diesel Web is achieved through non-blocking, asynchronous IO. This is different from most other web application frameworks in that most use the thread pool pattern. In the thread pool pattern, a main thread listens for incoming requests and passes control to a thread in the pool. Once the request has been handed off to the thread inside the pool, the main thread can then go back to listening for requests and doesn't need to worry about blocking while processing individual requests. This is the common way that concurrency is achieved in web application frameworks.

The asynchronous IO approach taken by Diesel Web scales better than the thread pool approach because there aren't any locking and synchronization primitives that accumulate overhead. IO events dictate what happens at the OS level and can thus scale better. The real benefit to using this approach would become apparent with thousands of users.

One other topic of interest with Diesel Web is the complete lack of dependencies, which is always a good thing. The framework appears to be striving for simplicity, another good thing, and doesn't really need much help from external packages. Basic HTTP protocol support is built in and that is really all that is needed as a starting point. It will be interesting to see if many other larger applications get built using this framework.