I continue to receive Flux implementations, which isn't a bad thing because they're adapting at a rapid pace. Flox (GitHub: foss-haas/flox, License: MIT, npm: flox) by Alan Plum is lightweight and seems easy to learn -- the readme has a nice introduction to the architecture.
It's loosely based on Flux, with a pared down pragmatic approach which I like. For example, Flox doesn't provide waitFor. Instead you should use services, which I thought made sense.
If you're interested in Flox, read through the example in the readme. It also ships with pretty detailed Mocha/SinonJS tests.
Speaking of services, what do you do when you want to easily switch dependencies or configuration values for different environments, like tests? pioc (GitHub: pago/pioc, License: MIT, npm: pioc) by Patrick Gotthardt is a dependency injection container that is aimed at Node but can be used with browsers through Browserify.
pioc's goal is to help you write loosely coupled modules:
pioc is very smart about how and when to initialize your services. It supports constructor injection, property injection, static values and even module inheritance with all the parts that are needed to make it work.
The API allows you to define modules, which are known as service definitions. These services are resolved by providers. Services can be bound as values or lazily evaluated objects. By default objects are treated as singletons, which is the most common usage.
If you're confused by all of this then try to imagine how to handle loose coupling for database modules. If you wanted to switch your database's configuration for the test or staging environments, then DI can help because you can inject different configuration values at runtime. Also, the database module would be treated as a singleton, so you can safely refer to it in multiple places in your project without accidentally creating new instances or connections.
Patrick's example is actually MongoDB, and this works well as a showcase of pioc's features.
There's an open beta for npmE, the npm Enterprise programme. This allows you to sign in to a private, hosted repository, which can be used to distribute private modules. They're prefixed with your company name, like this:
npm install @myco/somepackage
Then you can load them with the prefix as follows:
We plan on building a web-UI for controlling various aspects of an npmE installation: adding and removing packages from the whitelist, configuring authentication/authorization strategies, managing organizations and teams.
Snapshot.js (GitHub: Wildhoney/Snapshot.js, License: MIT, Demo) by Adam Timberlake is a WebSocket-based Node application for sorting, paginating, and filtering data served using WebSockets.
It uses Express and the crossfilter module, which is a multidimensional filtering library:
dm.js (GitHub: gobwas / dm.js, License: MIT, npm: dm) by Sergey Kamardin is a module for dependency injection. It's service based, so you'd have to build applications using that pattern to take advantage of it.
The dm module itself implements the "service locator" pattern. That means it knows how to find a given service and configure it. It supports asynchronous adapters, so you could use it with jQuery.Deferred, Q.js, and promises with Harmony. It can load modules with either AMD or CommonJS, so it'll work with Node modules.
This might sound like a huge amount of effort if you're not used to dependency injection, but if you come from a Java/C#/C++ background then you might find it easier to design Node applications this way.