The main difference between NPM and Bower is the approach for installing package dependencies. NPM installs dependencies for each package separately, and as a result makes a big package dependency tree(node_modules/grunt/node_modules/glob/node_modules/…), where there could be several versions of the same package. For client-side JavaScript this is unacceptable: you can’t add two different versions for jQuery or any other library to a page.
With Bower each package is installed once(jQuery will always be in the bower components/jquery folder, regardless of how many packages depend on it) and in the case of a dependency conflict, Bower simply won’t install the package incompatible with one that’s already installed.
Node Inspector is a debugger interface for Node.js applications that uses the Developer tools formerly WebKit Web Inspector. We can use node-inspector to debug grunt task. Node-inspector has the command node-debug, which launches node in a debug state and opens the browser to the node-inspector page, stopping when it hits the first debugger line or set breakpoint.
CommonJS is a project to define a common API and ecosystem for JavaScript. A part of CommonJS is the module specification. Node.js is a server-side JavaScript runtime and implements modules based on the CommonJS Module spec.
AMD (Asynchronous Module Definition) is another specification for modules. RequireJS is probably the most popular implementation of AMD.
One major difference from CommonJS is that AMD specifies that modules are loaded asynchronously – that means that modules are only loaded as they are needed, as opposed to loading all modules up front.
AMD is generally more used in client-side (in-browser) JavaScript development due to this, and CommonJS Modules are generally used server-side. However, you can use either module spec in either environment – for example, RequireJS offers directions for running in Node.js and browserify is a CommonJS Module implementation that can run in the browse.
A server side platform. An open source runtime environment. Used by LinkedIn, Yahoo! and PayPal. A platform that helped drop page load times and, according to PayPal development team, reportedly doubled the number of requests it handled per second. Today Node Js. is brought out to be one of the most useful application tools that provides “event driven architecture, optimizes an application capability and is able to handle thousand of concurrent connections with minimal overhead on a single process.” It’s a hot new commodity that we all want to get our hands on, or do we?
Introducing…
It’s really hard to find a professional in Node js… It’s so new that it’s limitations and security holes haven’t yet been discovered. However, HR departments already demand more experience than the platform has existed. So what’s the fuss about?
Unlike backend languages, Node js is all about non-blocking I/O operation that helps in ‘push technology’. It’s getting popular among developers to have 2-way connectivity i.e., both client and server can initiate communication and exchange data. The upside is to process multiple parallel requests (connections) on a single-thread by using non-blocking I/O calls. Node assigns separate threads for each connections using fewer resources and is able to switch between them with less delay. That makes it incredibly attractive for many ultra large websites. Node.js brings it best when the application is heavy data-driven (ajax based), especially if the app is a Single Page App with many requests per second that demands quick JSON responses. Such setup helps in processing on client-side; community loves it for developing Real time apps like Stock Exchange or Twitter-esque sites.
Same goes for the Java frameworks that are coming out for Node js. One of the cool things about Express, for instance, is it runs as the web server itself. It’s really different from Php and others as it loads your whole application in memory and then it sits as the server waiting for http request to come through and then responds to it. It never touches your file system, it just sits in your memory – which is why it s so blazingly fast.
The challenge
Whereas Node js is great for short quick demands on the server/chats… it’s not so great for the web apps that require a lot of memory from your computer. It’s not as efficient for anything that involves relational database and not a good fit for CPU intense apps like Language Translator etc. CPU intensive computations dramatically slow down Node js responsiveness.
And the flip side of it’s non blocking I/O operation: Node.js may not be used to fetch/deliver large sized files like video/combined assets.
EXAMPLE
Finally, end-end JS/HTML implementation in a single programming language is a sweet deal due to the ability to easily port logic across. It’s faster, lighter, more scalable. Which also means that very few UI developers lean towards learning Node js.
At this point “to learn or not to learn” is the matter of whether you’re a Java/C++ developer and whether your application is right for the Node js implementation (read: heavy data-driven and not memory greedy.) Or at least for HR department sake – until now becomes then.
