There are times in life, when you begin doing something without fully understanding it, simply because, at that point, you didn’t have the luxury to dig deeper, go further and be in a position where you could explain to a 5 year old, what it is really like to do what you were doing.

I have been in this position several times. A lot of times, software development for me has been a journey of reverse engineering, or figuring things backwards. Do it first, based on snippets read here and there online and then connecting the dots gradually as you spend more time doing similar things. Sounds familiar? Probably, the life of every other software engineer on the planet working on a target deadline.

So I decided to jot things down in plain simple words, that can help others in here. This time it is node and npm.


Nobody ever explained what node was to me when I started. I remember starting like: “To install angular you need to install node. And with node, comes npm, the package manager”.

I was oddly uneasy about the things that I didn’t know about, however, there wasn’t enough time to search and figure it all out then.

Node is a javascript runtime environment! A fascinating piece of work by Ryan Dahl. You can read a brief history of node at its website. It is a at its essense, a browser’s javascript engine packaged or embedded into a command line executable.

The advantage: you can now use javascript to not just write code that runs on your website in the browser, but you can also develop, server side applications in it! Javascript just went full stack.

As you can read in the history of node, this wasn’t a new idea, it just clicked purely because of timing, the maturity of javascript was just right when node came out that it got widely adopted and some of the largest companies then switched to it. Primarily because, everything written as a node app, would be inherently asynchronous and most of the web, thrived on asynchrony, make a request, while we wait for it, do something else, etc. You didn’t have to write complicated code to do this either. Node application are well suited for i/o based scenarios, but not great at cpu intensive applications.

That means, javascript got widely adopted, making it the most popular programming language on the web, always topping the charts in stackoverflow’s annual survey results.


As javascript adoption grew widely, people started developing applications of all kinds and some of them were utilities that could be used by other applications. There was instantly, a need to be able to share and reuse code. This is what led to npmjs. A platform to view js packages that you could use in your project and where you could publish your next useful js package.

This move, enriched the node and javascript ecosystem. However, do remember, npmjs, is not one that has much gate-keeping. Anyone can publish any package, any time. So you have to be careful what you choose to depend on. And because of this very lack of gatekeeping and quality control, not all packages, strictly follow or adhere to semver, hence could lead to breaking your application unintentionally, which I experienced first hand at my earlier firm. There are ways to avoid this sort of a situation, only if you know what npm had to offer and what those meta information really meant, which neither me, nor my coworkers at the time knew, as we had just jumped from building fully .NET applications to building a mix of .NET and rich front-end based applications.

npmjs being the web portal that hosted all these wonderful, utilities for your consumption, also lets you have a command line interface to interact with it, that comes with your standard node installation. This is rightly so that you can make the best use of what’s already available out there instead of reinventing the wheel.


That’s a quick introduction, a couple of paragraphs that could have filled the huge hole in a busy software engineer’s life, where the priority is getting things done.

We’ll delve into some code and commands in the next post.