Fork me on GitHub

Anyone who has been won over to the power and efficiency of node.js knows the power of asynchronous programming. However, the vast majority of the programming we have all done has been in procedural languages and we have found ourselves adept at writing classes, methods and functions, but we find that this is not enough when the world goes asynchronous. Anyone who's experimented with node.js has probably suffered a case of callback-itis or pulled their hair out when they're juggling more than one EventEmitter. What is needed is a structured way to think about the system and its constituent parts that is both simple enough to be usable, but has real power behind it too.

Luckily, there are state machines. These sound dull and boring, and I'm sure many have suffered building silly examples on CS courses. This has often given state machines a bad name and meant that they have been relatively ignored and haven't developed as far as, or been as widely adopted, as object-oriented procedural idioms. There are a number of fields that do use them, such as game houses, embedded and mobile phone programming, but we think it is time that their is a wider adoption of their use and that node.js is the perfect environment for it.

Not all state machines are alike. There are a couple of fundamental types of SMs (Mealy and Moore machines), but these are so restrictive that they are best left for the theoreticians. Luckily, there are machine types that are more suited to the practically minded - these are typically founded on Harel Statecharts, and the particular type inspired us was the capabilities of the machine as defined within UML2. These UML machines provide a much more liberal environment than the classical machines and, after some practice, become a natural way to think about asynchronous systems.

When we had to produce some node.js software and after some initial experiments, we decided that we needed the structure that SMs allowed. Hence we started to implement a framework in which to write state machines and use these to generate the system. What started out as a simple system that handled the basic core of SMs (entry and exit functions, guards and actions), soon developed as we discovered there were various state patterns that repeated (so we added the notion of plug-ins to allow these to be easily repeated), that we wanted to support multiple levels of machines and that occasionally we wanted to draw them. We are now confident that state machines (ignite.js) and JavaScript/node.js are very good allies.

Progress is now far enough for us to have the framework well enough thought out, implemented and documented for us to share it with the community. Although these are still early days (this should be considered a pre-alpha release), we hope you find it useful.