DEV Community

Cover image for Understanding Node.js
Dubymar Tollinchi
Dubymar Tollinchi

Posted on

Understanding Node.js

When the majority of us started learning about web development, the first thing we came across was HTML. Then we learned about CSS to make our websites prettier and visually satisfying. When it was time to make our websites interactive and dynamic, we started diving into the amazing world of JavaScript. But back in the day, JS was used just to code the client-side, meaning that it could only be used in the browser. To interact with the server we needed to use other server-side languages such as Python, Ruby, or PHP. Until Node was born.

But, what is Node and how does it work? Node is a runtime environment that allows us to run JavaScript on a physical machine, rather than in the browser. At the same time, it is open-source, whereby millions of developers can create libraries and modules that can be downloaded for us to use.

Node uses V8, which is Google Chrome's JavaScript engine. Both the browser and Node use JavaScript as their programming language, but unlike the browser, with Node, we don't interact with the DOM. We have innumerable APIs that Node provides through their modules, which will allow us to program the server-side without learning any other language.

To get started with Node, we first have to download it to our computers from its website. Packages are available for all major platforms, and it's very easy to install. Select the correct operating system and once being installed, click next all the way through the end, and that's it!


npm stands for Node Package Manager, and as it is self-explanatory, it manages all modules with the necessary dependencies for our project. Nowadays, there are more than 350,000 packages declared in Node.js.

To start using node, first, we go to our project and create a package.json (if it's not already part of the project). After that, we go to our terminal and type npm install or npm i, then Node goes to and downloads all dependencies and creates a folder named node_modules where it's all stored. At the same time, it stores all names and versions of those dependencies in the package.json file.

This package.json can do many different things, unrelated to one another, and it has no requirements other than following the JSON (JavaScript Object Notation) format. Some basic declarations that we can make in our package.json file are:

  "name": "my-project",
  "version": "1.0.0",
  "description": "A JS project",
  "main": "src/main.js",
  "private": true,
Enter fullscreen mode Exit fullscreen mode

Now let's take a look at something interesting:
In our package.json we specify the packages' version in our project, as well as the minimum being used and the new versions to be installed.

  1. If we type ~0.1.0, it will update patch releases, like 0.1.1, but not 0.2.0.
  2. If we type ^0.1.0, it will get updates that don't change the leftmost non-zero, like 0.1.1, 0.1.2, but not 0.2.1.
  3. If we type 0.2.1, that is the exact version that we will always use.

In the case that we do not type the specific version that we will use, when someone on the other side of the world tries to download the project and run npm i, the latest versions will be downloaded, which will result in a project with different versions of dependencies. This was a very specific problem that package.json left unsolved, but now we have something called package-lock.json.

Package-lock.json stores the current versions that our project is using, and installs the right one from when running npm i. In case we want to update the dependencies' version, we run npm update and it will update them in the package-lock.json.

Top comments (0)