It can be a good idea to carefully separate out functions with side effects from functions that don't have side effects so that the parts of your program that actually do the IO are all in one place, separated from the pure algorithmic functions. This separation of IO from pure functions is sometimes called an "IO shell".
Code that has its IO separated from its algorithms can be much easier to test, since the algorithms can be tested without setting up the environment to perform IO in the correct places.
[ node-specific ] <-- VAST EXPANSE OF REUSABLE CODE --> [ browser-specific ]
The middle area (which maxogden calls "the awesome") is where we can obtain much more reusability because solutions are much more general-purpose when they aren't tied to a specific IO layer. For example, instead of writing a library that issues xhr requests and parses the responses as streaming JSON, use one library to return streaming xhr responses, and another library to parse streams of JSON. Or better yet, use a library that already exists, like JSONStream for parsing and hyperquest to issue requests and stream responses. If you later decide to move from XHR to using websockets, you can just swap out hyperquest for a streaming websocket module like engine.io-stream or shoe while leaving the json parsing and other streaming glue intact!
Better still, you can perform quick sanity checks on algorithmic code that doesn't touch the DOM directly from node.js in the comfort of your command-line. Even if you don't use node for running services, it can be a valuable tool for automation and testing.
easy to test
maximizing the fun
When something is fun, you will be more motivated to do it! Motivation and fun are intrinsically linked to programmer productivity and the bottom line, so maximizing fun can be serious business!
The next time you are stuck on a complicated bug or feature, imagine if there was a module that would make the task at hand trivial.
Perhaps that module already exists and somebody has been kind enough to publish
it to npm! If you can't find anything, go off and build
that module in a clean new directory in your
Now go off and build that module in an empty directory! When you're done, you will have solved the addressed the application problem or feature without adding much complexity at all!
One huge benefit of using npm for package management is the fine-grained control you get over versioning your dependencies.
Once you've started using lots of modules
To manage all your modules for development and deployment, there are many options.
You can check your node_modules/ directory into git directly, you can use
or setting up a private npm, either by running a couchdb replica yourself or getting a hosted private npm.
Better still, when you want to iterate on the separated module later, you can do so without having to update both the module and the application at once!
with your team,
imagine the module that
Perhaps while writing the
imagine what it would look like if a module existed to make your own problem trivial.
a module or collection of modules that would make problem