In the right place at the right time - Node.JS

+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 the 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 deeper. 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 upon Ajax.

Learn more about our Node.JS Training Videos to get ahead in your career.

In the same vein, it’s possible to get excited about Node — probably because you buy into all the splendid and wise observations you’ve been reading — and then use it everywhere. Suddenly, you’re replacing all your PHP and Perl back-ends with Node. The result? A mess. In fact, you’ll be forced to have several web forms do just what Node isn’t meant for: submit big chunks of data to JavaScript on the server via Node, and force that JavaScript to either send back a chunk of JSON that’s got to be parsed or eval()ed or send back a full-blown HTML page or an HTTP redirect.

                                             Checkout Node.JS Interview Questions

But that’s simply not what Node is best at. It’s great at micro-requests; at evented I/O. Use Node for quick communication between a web page and a server. Use form submissions to send big chunks of data to the server. Use PHP and Perl to do heavy database lifting and generate dynamic HTML pages. Use the Node to provide a means for server-side JavaScript to run and handle small requests. Throw in Rails and Spring and servlets and whatever else you need. But make your decisions based upon the problem you’re solving, rather than what you happen to know best at the time.

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 [1] 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)

Learn Node.JS Tutorial

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.

Learning Node might take a little effort, but it’s going to pay off. Why? Because you’re afforded solutions to your web application problems that require only JavaScript to solve. That means your existing JavaScript expertise comes into play. And when you do need to use PHP or Perl — because it’s the right solution for a particular problem — you don’t need a PHP or Perl guru. You need to know the basics, and those needs can be expanded when the problem requires expansion. Stretching comes at the behest of new problems, rather than stretching poor solutions thinly.

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.

Explore Node.JS Sample Resumes! Download & Edit, Get Noticed by Top Employers   Download Now!