In the right place at the right time
Recommended by 0 users
The Node.js community is large, inclusive, and excited to enable as many users to contribute in whatever way they can. There’s another web pattern at work here, and it’s probably far more important than whether you use Node or not, and how evented your web applications are. It’s simply this: use different solutions for different problems. Even better, use the right solution for a particular problem, regardless of whether that’s the solution you’ve been using for all your other problems.
The inertia of familiarity
There’s a certain inertia in not just web design, but all of programming. That inertia can be stated axiomatically like this: the more you learn, use, and become good at a certain approach or technique or language, the more likely you are to use that approach/technique/language widely. It’s one of those principles that sounds good until you dig deeply. Yes, it’s good to learn a language or toolkit well, and to employ it widely. But this inertia often causes you to use a tool because you know it, rather than because it’s the right tool.
Look at Ajax, something already discussed. Initially, Ajax provided a solid approach for sending quick requests, without form submissions, to a server. Now it’s become a drop-in replacement for all form submissions. That’s taking a technology, learning it, applying it, and then eventually over-applying it. There’s still a solid place for form submissions — when a form needs to be submitted! As simple as it sounds, there are tends of thousands of web applications submitting forms with Ajax, just because the lead web developer is up on Ajax.
Node’s promise of simplicity
The node-promise project provides a complete promise implementation. Promises provide a clean separation of concerns between asynchronous behavior, and the interface so asynchronous functions can be called without callbacks, and callback interaction can be done on the generic promise interface. The node-promise package provides just a promise implementation, however, promised-io is recommended for more complete promise-based IO functionality. The promised-io include the promise implementation from node-promise, as well as wrappers around the Node’s filesystem and other system I/O APIs for consistent promise-based interaction.
The node-promise module features a promise implementation with:
- Chainable promises
- Promises throw errors if an error handler is not provided
- CommonJS promise proposal  compliant
- Immutable once fulfilled to reduce possible side-effects
- Promises can be used securely (as separate resolver/promise pairs in ocap situations)
- Backwards compatibility where possible (addCallback, addErrback, emitSuccess, and emitError should still behave as expected)
There’s one last note worth making. When you take this broad approach to programming, you’ll often find that you’re not having to go as deeply into each toolkit, API, and framework you use. By using your tools for what they’re best at, you don’t need to be able to staple with hammers or measure with drills. Using tools for their intended purpose typically means you use the core capabilities more. So while you’re creating generalists — programmers that know lots of things — you are also reducing the need for specialists — programmers that know one or two things really, really well. Of course, every pointy-haired boss also realizes that those specialists are really, really expensive and hard to find.
Your biggest challenge is the continual move to a web that is made up of smaller pieces, talking more often, and the combination of what can seem like a dizzying array of technologies. However, taking the core features of 100 technologies is always going to serve you better than taking 100% of one technology and trying to solve 100 problems. Node and evented I/O isn’t a solution to every problem, but it sure is a solution to some important problems.