While writing my Vue.js UI Library, Inkline, I had to find a way to make some components work both with and without providing a model value (v-model). While it's not a common scenario, it's something that you'll definitely come across if you're writing a library and you're serious about Developer Experience (DX).

I call them Optionally Controlled Components, because they're supposed to work out of the box without providing a v-model, but will give you complete control over their state if you do provide a v-model.

The Menu Example

One prime example of an Optionally Controlled Component would be a menu that can be opened (expanded) or closed (collapsed). Let's call the component simply MyMenu.

From a Developer Experience perspective, you'll probably want your library user to be able to drop a <my-menu> into their code and start adding collapsible content right away, without having to worry about handling its open or closed state.

Here's what the component would look like without v-model support:

<template>
    <div class="my-menu">
        <button @click="toggleMenu">
            Menu
        </button>
        <menu v-show="open">
            <slot />
        </menu>
    </div>
</template>

<script>
export default {
    name: 'MyMenu',
    data() {
        return {
            open: false
        };
    },
    methods: {
        toggleMenu() {
            this.open = !this.open;
        }
    }
}
</script>

The Optional Model Value

So far so good. Let's consider the following scenario: your user wants to be able to open or close the menu from somewhere else. We know we can open and close the menu internally at this point, but how do we allow the library user to optionally control the state?

There's a future-proof solution I found, that will save you a lot of trouble. Here's what it looks like:

<template>
    <div class="my-menu">
        <button @click="toggleMenu">
            Menu
        </button>
        <menu v-show="open">
            <slot />
        </menu>
    </div>
</template>

<script>
export default {
    name: 'MyMenu',
    emits: [
        'update:modelValue'
    ],
    props: {
        modelValue: {
            type: Boolean,
            default: false
        }
    },
    data() {
        return {
            open: this.modelValue
        };
    },
    methods: {
        toggleMenu() {
            this.open = !this.open;
            this.$emit('update:modelValue', this.open);
        }
    },
    watch: {
        modelValue(value) {
            this.open = value;
        }
    }
}
</script>

Try a basic example out live on CodeSandbox.

You can see above that I've added the usual modelValue prop to provide v-model support in Vue 3, but mainly I've done three things:

• I'm setting the initial value of our internal open state property to be equal to the one provided via v-model. This works wonders, because when there's no v-model it would be equal to the specified default, false in our case.
• I'm emitting an update:modelValue event every time I change the value of this.open internally
• I've added a watcher that ensures I'm always keeping the internal open value in sync with the incoming external modelValue prop.

Conclusion

Awesome, isn't it? It's important to never forget about Developer Experience. Something as small as this can add up to precious hours of saved development time if done correctly and consistently.

I hope you learned something interesting today. I'd love to hear how the Optionally Controlled Components pattern helped you out, so feel free to reach out to me. Happy coding!

P.S. Have you heard that Inkline 3 is coming with Vue 3 support? Read more about it on GitHub.

Testing Vue components is incredibly simple. However, lifecycle methods are almost always overlooked. While testing lifecycle methods isn't difficult, I haven't found too many resources out there that explain how to do this.

Writing the Component

First, let's say we have a component called MyLifecycleComponent.vue. This component calls an initialize method during the mounted lifecycle step:

<template>
    <div>Hello lifecycle component!</div>
</template>

<script>
export default {
    name: 'MyLifecycleComponent',
    methods: {
        initialize() {
            console.log('initialized');
        }
    },
    mounted() {
        this.initialize();
    }
}
</script>

A very basic test would be to check whether the initialize() method gets called during the mounted() lifecycle.

Writing the Test

By default, lifecycle methods are called automatically while the component is being created, therefore they're supposed to be called only once.

What I want to do is to make the lifecycle methods callable inside the tests. The component instance wrapper.vm does not expose lifecycle methods by default, therefore we need to add them when mounting the component wrapper.

let wrapper;

beforeEach(() => {
    wrapper = shallowMount(MyLifecycleComponent, {
        methods: {
            mounted: MyLifecycleComponent.mounted
        }
    });
});

It's good practice to mount the component before each test in order to have a clean state. As a rule of thumb, it's best to keep things as simple as possible, that's why we're not testing the actual effect of the initialize method, but whether it has been called.

In order to check whether a method has been called, we use jest.spyOn() to create a spy. The spy contains information on whether the method has been called or not, how many times it has been called, and what it has been called with.

import MyLifecycleComponent from '@/components/MyLifecycleComponent';
import { shallowMount } from '@vue/test-utils';

describe('MyLifecycleComponent', () => {
    let wrapper;

    beforeEach(() => {
        wrapper = shallowMount(MyLifecycleComponent, {
            methods: {
                mounted: MyLifecycleComponent.mounted
            }
        });
    });

    describe('mounted()', () => {
        it('should call initialize method', () => {
            const spy = jest.spyOn(wrapper.vm, 'initialize');
            
            wrapper.vm.mounted();
            
            expect(spy).toHaveBeenCalled();
        });
    });
});

Conclusion

Testing lifecycle methods is hassle free when you know how to do it. All of the code presented here can be found in this repository.

When unit testing, I always aim for a 100% test coverage because it keeps me out of trouble when I refactor my code.

 PASS  tests/unit/MyLifecycleComponent.spec.js
  MyLifecycleComponent
    mounted()
      ✓ should call initialize method (27ms)

  console.log src/components/MyLifecycleComponent.vue:10
    initialized

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        2.051s
Ran all test suites.

Working with events in Vue.js works great out of the box, but what happens if you want to send an event to a specific parent or child component?

The Vue Emitter Design Pattern is the all-around solution for programatic event-based child-parent communication. To provide this functionality, we're going to implement two essential methods: broadcast and dispatch.

Broadcast

Broadcasting means emitting an event from a parent component to all child components that have a specific name. This is useful when you want to update several child components.

To implement broadcasting, we're going to recursively descend the children of the parent component. In order for it to be easy to reuse, we'll write a Vue mixin inside a BroadcastMixin.vue file:

/**
 * Broadcast an event with given params to specific child properties
 *
 * @param componentName
 * @param eventName
 * @param params
 */
function broadcast (componentName, eventName, params) {
    this.$children.forEach(child => {
        const name = child.$options.name;
        if (name === componentName) {
            child.$emit.apply(child, [eventName].concat(params));
        } else {
            broadcast.apply(child, [componentName, eventName].concat([params]));
        }
    });
}

export default {
    methods: {
        broadcast (componentName, eventName, params) {
            broadcast.call(this, componentName, eventName, params);
        }
    }
}

With the code being written as a Vue mixin, using it is as simple as:

import BroadcastMixin from './mixins/BroadcastMixin.vue';

export default {
    name: 'ParentComponent',
    mixins: [
        BroadcastMixin
    ],
    methods: {
        broadcastSomething() {
            this.broadcast('ChildComponent', 'input', 42);
        }
    }
}

Dispatch

Dispatching means emitting an event from a child component to a parent component that has a specific name. This is useful in scenarios where the parent needs to be notified of something happening in a child component.

To implement dispatching, we're going to recursively ascend the parents of the child component until we find the one we're looking for. Again, we'll be using a Vue mixin in order to have reusable code. Here's the DispatchMixin.vue file:

/**
 * Dispatch an event from child to parents of given type
 *
 * @param componentName
 * @param eventName
 * @param params
 */
function dispatch (componentName, eventName, params) {
    let parent = this.$parent || this.$root;
    let name = parent.$options.name;
    while (parent && (!name || name !== componentName)) {
        parent = parent.$parent;
        if (parent) {
            name = parent.$options.name;
        }
    }
    if (parent) {
        parent.$emit.apply(parent, [eventName].concat(params));
    }
}

export default {
    methods: {
        dispatch (componentName, eventName, params) {
            dispatch.call(this, componentName, eventName, params);
        }
    }
}

To use the above Vue mixin, import it and add it to the mixins array:

import DispatchMixin from './mixins/DispatchMixin.vue';

export default {
    name: 'ChildComponent',
    mixins: [
        DispatchMixin
    ],
    methods: {
        dispatchSomething() {
            this.dispatch('ParentComponent', 'input', 42);
        }
    }
}

Conclusions

I've used this design pattern quite a lot in Inkline, my Vue.js UI/UX Framework. Make sure you check it out if you haven't already.

An use case where I found it to be of tremendous importance was reinitializing an array of values based on child components. To make sure that the array data is always in sync, child components would call a synchronize event whenever they would get mounted or destroyed.

The Vue Emitter Design Pattern will prove itself particularly useful when creating reusable related components that can have any level of nesting. I'd love to hear your thoughts down below.

Npm scripts are my absolute favorite feature of npm. They're a much easier, more flexible alternative to task runners.

So, what is a npm script? A npm script is, well, exactly what the name says. It's a command-line script that is run through npm. It facilitates the use of locally installed dependencies without making them available system-wide.

This allows you to write common application routines without the need for too many configuration files. The common way to do this used to be using Gulp or Grunt, or even using bash scripts. Lately, a lot of developers are moving over to npm scripts because of how simple and flexible they are.

How to write npm scripts

When you talk about npm, you talk about package.json, of course. The package.json file has a scripts field where you define all the routines.

If you don't recall from the previous tutorial, the package.json file is your package's configuration file, generated after running npm init.

// File: package.json

{
    "name": "my-package",
    "description": "This is a sample project for the Node.js Simplified Tutorial.",
    "version": "1.0.0",
    "main": "index.js",
    "scripts": {
        ...
    },
    "dependencies": {
        ...
    },
    "devDependencies": {
        ...
    }
}

The part we're interested in now is the "scripts" field. That's where we define named command-line scripts that pass through npm.

Your first script

Let's go ahead and add a very simple script called hello, that writes an output to the command line terminal. To do so, write the name of the script and the command associated to it in quotes.

The script we're writing is a plain bash script:

// File: package.json

{
    ...
    "scripts": {
        "hello": "echo 'Hello npm scripts!'"
    }
}

Next, any npm script you write can be executed using the npm run command.

npm run hello

The start script

Perhaps the most popular npm script ever is the start script:

{
    ...
    "scripts": {
        "start": "node index.js"
    }
}

As you've seen above, starting a command is done using the npm run command. The start script, however, is a built-in script and we can optionally ommit the run keyword for it.

npm start

Script composition

One common use for npm scripts is as an alternative to task runners. Npm scripts make it easy for you to execute long lines using simple commands.

In my experience, one of the best things about using npm scripts is script composition. This means that npm allows you to compose large npm scripts out of multiple smaller ones, allowing you to use npm run my-script inside of another script.

Let's take a look at the dev npm script I wrote here:

{
    ...
    "scripts": {
        "start": "node index.js",
        "webpack": "webpack --config config/webpack.config.js",
        "dev": "npm run webpack && npm start"
    }
}

If you are not very comfortable with terminal commands, what you need to know is:

• running npm scripts in series is done using a double ampersand &&, the second command executing after the successful execution of the first one.
• running npm scripts in parallel is done using a single ampersand & (on UNIX-based systems) or the concurrently package, with the two commands executing at the same time.

Running npm run dev will run both the start and the webpack scripts I've defined above. Yup, you can do that and it's awesome!

Script execution hooks

Npm scripts have before and after script events which I call script execution hooks. They're basically other scripts that will be executed before or after the script you're running. Hooks can be added by simply prepending the pre (before) and post (after) keyword to your npm script name.

Let's say that, for example, you have a script called count. If you'd like to add a pre-execution hook to it, you would call it precount. If you'd like to add a post-execution hook, you would call it postcount. Simple, isn't it?

{
    ...
    "scripts": {
        "precount": "echo '1'",
        "count": "echo '2'",
        "postcount": "echo '3'"
    }
}

Now, when running npm run count, npm will actually execute three scripts, in the following order: precount, count, postcount. The displayed output will be 1 2 3.

Built-in npm scripts

There's a number of special scripts that npm treats differently, such as the start script you've seen above. The built-in scripts are used for basic commands, as well as for some pre (before) and post (after) script execution hooks.

Note: The built-in scripts can be executed without the run keyword.

npm start

Keep in mind that most built-in npm scripts come with a default behaviour. However, you can override the behaviour or add a custom command to be executed alongside the command's default behaviour.

• install: Installs the package and all its dependencies.
  The built-in npm script hooks for npm install are: preinstall, postinstall
• uninstall: Uninstalls the package.
  The built-in npm script hooks for npm uninstall are: preuninstall, postuninstall
• start: Starts the package execution.
  The built-in npm script hooks for npm start are: prestart, poststart
• stop: Stops the package execution.
  The built-in npm script hooks for npm stop are: prestop, poststop
• restart: Restarts the package execution. Default runs the stop and start scripts.
  The built-in npm script hooks for npm restart are: prerestart, postrestart
• prepare: Runs before the package is packed and published, and on local npm install without any arguments.
• publish: Publishes the package to npm.
  The built-in npm script hooks for npm publish are: prepublish, prepublishOnly, postpublish
• version: Runs after bumping the package version.
  The built-in npm script hooks for npm version are: preversion, postversion
• shrinkwrap: Locks down dependency versions for publication.
  The built-in npm script hooks for npm shrinkwrap are: preshrinkwrap, postshrinkwrap
• pack: Creates a tarball from a package.
  The built-in npm script hooks for npm pack are: prepack, postpack
• test: Runs the tests of the package.
  The built-in npm script hooks for npm test are: pretest, posttest

I'm sure that not all of them will be useful to you, but some will be nice to know for when you're creating your own package.

What's next?

Now that you've learned about the utility of npm scripts, it's time to create your first real Node.js application.

As always, I'd love to hear your opinion about this article! Make sure to leave a comment down below.

Every Node.js project starts with a package.json file.

In the previous part of the Node.js Simplified Tutorial series, you learned about exporting and requiring Node.js modules. Here, I'll talk about npm, an indispensable tool in your Node.js experience.

Node's package manager, suggestively named npm, is a very powerful tool used to share your code as packages. Not only that, but it allows you to reuse code written by other developers inside your own package, as dependencies. Each package is identified using a package.json file.

The package.json file is used for specifying important details about your project such as its name, description, version, entry file, production dependencies, and development dependencies. You can even define command line scripts to be run through npm, slowly eliminating the need for task runners.

Creating a npm package

Creating your first package is as simple as writing a single command line. Open up your terminal, go to your project's root folder and run the following command:

npm init

This is going to ask you to provide basic details about your npm package. The name and description you provide here are the ones that will be used when publishing the package to npm. Don't worry about the entry point for now: the default is index.js and you'll see why that is in the following section.

name: (project) my-project
version: (1.0.0) 1.0.0
description: This is a sample project for the Node.js Simplified Tutorial.
entry point: (index.js) index.js
test command: 
git repository: https://github.com/alexgrozav
keywords: nodejs
author: Alex Grozav
license: (ISC) ISC

After you're done , the command will generate a file called package.json that will contain all the details you provided. This will be the configuration of your npm package.

Your package.json file should look like this:

{
  "name": "my-project",
  "version": "1.0.0",
  "description": "This is a sample project for the Node.js Simplified Tutorial",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/alexgrozav"
  },
  "keywords": [
    "nodejs"
  ],
  "author": "Alex Grozav",
  "license": "ISC"
}

The package.json file does a lot more than provide basic package details. It's the place where you specify the development and production dependencies that your package has, but we'll get back to that later in this article.

For now, it's easiest to think of every Node.js project as a package and to think of every package as a module.

Requiring a npm package

In my previous tutorial you've learned how Node.js handles require statements for relative paths. You can also require npm packages in the same way.

It's important to understand that when you require a package you will actually require the file specified in the main field of your package.json file. This is same as the entry point you specified during the npm init step.

const myPackage = require('package-name');

After path resolving, Node.js will require the file specified in the main field of the package-name/package.json file or, if the main field isn't specified, it will look for an index.js file:

const myPackage = require('package-name/index.js');

Adding package dependencies

Undoubtedly, the best thing about creating your own npm package is that you can specify, install and then use other developer's packages. This saves up a lot of time, with the npm registry offering more than 600,000 packages for you to use.

When I was learning Node.js, I didn't understand the difference between production and development dependencies very clearly. Here's what is different:

Installing dependencies for production

Production dependencies are the ones that your package actually depends on. These dependencies will need to be installed alongside your own package in order for it to run. Don't worry though, npm handles the dependencies for you.

What this basically means is that, when someone else installs your package, the production dependencies you specify will be automatically installed together with it.

npm install --save lodash

Note: You can use the -S shorthand instead of --save.

Installing dependencies for development

Specifying development dependencies is perfect for installing packages that help you get to the final version of your package, but do not directly affect the functionality of your package.

Development dependencies usually provide you with capabilities such as testing, compiling, bundling, and other things needed during development only.

npm install --save-dev gulp

Note: You can use the -D shorthand instead of --save-dev.

Installing packages globally

Global packages are made available system-wide. You should only install packages globally if they offer a command line executable or if their documentation suggests you to do so.

Typically, you will need install test runners, testing frameworks, task runners, languages, and bundlers globally.

npm install --global gulp-cli

Note: You can use the -g shorthand instead of --global.

The node_modules folder

Every time you install a local dependency, npm downloads and installs the package and its dependencies inside a folder called node_modules, where you can find and explore all of your package's dependencies.

After each saved installation, your production or development dependencies will be listed inside the package.json file under dependencies and devDependencies, respectively:

{
    ...
    "dependencies": {
        "lodash": "^4.17.5"
    },
    "devDependencies": {
        "gulp": "^3.9.1"
    }
}

If you want to install all the dependencies of an existing package, simply run the install command without any argument:

npm install

Publishing your package to npm

When you're ready to share your package with the world (if you want to, of course), you can publish your package to the public npm repository.

• First, make sure you're logged into npm using the login command. This will ask you for your npm username, password, and email.

npm login

• Next, make sure you have specified a unique name, valid repository url, and semantic version in your package.json. Publish your package by running the publish command:

npm publish

• Now your package is available for installation to other developers using the name you've specified.

npm install --save your-package-name

Lately, good npm package names have been pretty scarce, like domains, because everyone is trying to reserve a nice name for themselves.

What's next?

Now you're ready to create packages, install dependencies and perhaps, even give something back to the open source world someday.

In my Power of NPM Scripts article, I've written about the now-popular npm scripts and how they work. They're a great addition to your workflow, and you won't need to rely on a task runner such as gulp or grunt anymore.

When I started learning about Node.js modules, I remember being confused about them.

Modules are self-contained entities that provide distinct functionality, allowing them to be changed, added, or removed as needed in order to form a complete system.

Modules are essential for splitting your code into reusable components. They're such a simple concept, yet the underlying mechanism is so complex.

First thing you'll need to know is that all the dependencies in Node.js are handled using two core built-in objects:

• The require object ― available across your Node.js application as a function
• The module object ― because each file represents a module, it is local and individual to each file

The module object is usually used for exporting things from a file, and the require function is used for importing the exported things into a file.

Module exports

You can think of exporting as choosing what values (just about anything) you're making available from the current file within another file. You define what gets exported using the module.exports object.

module.exports = {
  greeting: 'Hello Node.js!'
};

Using module.exports vs exports

Something I've encountered when looking at other projects is the keyword exports by itself. The two are one and the same object, exports being a simple reference to module.exports.

Node.js makes the exports variable available behind the scenes by doing the following:

var exports = module.exports = {};

Module importing

Whenever you require a file, Node.js goes through a series of actions that will ensure your file is loaded properly:

• Resolving the path ― First, Node.js determines the absolute path of the file you're requiring, relative to the file that you're importing in.
• Loading the file ― Next, Node.js determines what type of content the file contains. You can also require .json files and Node.js knows how to differentiate the two based on the provided file extension.
• Scoping the code ― The require and module objects are local to the file they're in. Each individual file has it's own scope.
• Evaluating the code ― Next, the Virtual Machine evaluates the loaded code inside the newly created scope, limited the file where you're importing it in.
• Caching the file ― To achieve better performance, Node.js caches the loaded file. Once you've require a file, it will be ready to be reused.

const importedModule = require('./path/to/file');

Resolving module paths

During the path resolving step, Node.js gives you a lot of flexibility. It's important that you understand the difference between requiring paths and requiring packages.

You should keep in mind that you don't need to specify the .js extension, because Node.js's path resolving mechanism adds it automatically.

Another thing I found very useful when writing Node.js applications is that you can specify a folder path in your require statement, and then the index.js file inside the specified folder will be targeted.

require('./path/to/file');

The require statement above, used with a relative path, will be resolved for you in one of the following ways:

// The path refers a .js file
require('/home/user/path/to/file.js'); 

// The path refers to a folder
require('/home/user/path/to/file/index.js');

If the specified path is nor a relative or an absolute path, it will be treated as a npm package. You'll learn more about creating and requiring npm packages in the next tutorial.

require('package-name');

Export and require in action

Understanding how module exports and imports work together is essential towards understanding Node.js. The way Node.js handles modules work is fairly complicated, but the interface for using modules is not complicated at all.

When I started out, I understood what require() does. What I didn't know, however, was about the existence of the module.exports object and how it interferes with requiring modules. One thing I really take pleasure in doing is learning through practical examples, so let's write a simple program.

Let's write a small file called greetings.js, where we'll export a simple function for saying hello.

// File: greetings.js

function sayHello (name) {
  console.log('Hello ' + name);
}

function sayGoodbye (name) {
  console.log('Goodbye ' + name);
}

module.exports = {
  sayHello: sayHello,
  sayGoodbye: sayGoodbye
};

Next, let's import and use the greeting inside an index.js file. Make sure to place the two files in the same folder.

// File: index.js

const greetingsModule = require('./greetings');

greetingsModule.sayHello('Node.js');
greetingsModule.sayGoodbye('Node.js');

Last but not least, run the program as you've learned in the previous tutorial.

node index.js

What's next?

This is merely an introduction to how module exporting and importing works. There's a lot more to learn about it, and I'll try my best to bring you up to speed with the best practices on the topic.

I've covered fundamental functionality such as requiring npm packages and creating your own package in All About NPM Packages. Make sure you read it!

Installing Node.js is very straightforward. In this tutorial you'll learn how to install it using nvm, the Node Version Manager.

In the first part of the Node.js Tutorial series, you've learned what Node.js is and why you should learn it. Since you're reading this, I assume you've decided that Node.js is worth learning. It'll be quite a beautiful journey, I assure you!

If you want to get started right away, download and install the Node.js binaries by visiting the official Node.js Downloads page. However, if you want to do it the right way, keep reading to learn about nvm.

Installing nvm

If you want to add more Node.js versions to use for different applications, or to simply keep your Node.js environment organized, I'd recommend installing nvm. Here's how to install it for your specific operating system:

MacOS and Linux
Follow the steps specified in the nvm GitHub repository, or run the following command in your command line Terminal:

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

Windows
The windows version requires you to Download and Install the executable from the nvm-windows GitHub repository.

Using nvm

To list the versions of Node.js available to install, run the following command:

nvm ls-remote

This is going to give you a long list of available Node.js versions. I usually choose to install one of the LTS (Long Term Support) versions, which are proven to be stable and have all the latest bug fixes.

For this tutorial, we'll install version 12.14.0 (LTS: Erbium).

nvm install 12.14.0

To check if the chosen node version has been installed properly, run:

node --version

This will return the version number of the currently active Node.js binary. If everything is working, it should say 12.14.0.

Switching between versions

If you've installed multiple versions using nvm, you can switch between them using the nvm use command:

nvm use 12.14.0

Getting started ― Hello world!

Now that your Node.js is up and ready to be put to use, we can write and run a small test program, to make sure that you're ready for the next part.

Let's start by creating a file called index.js. Open up your IDE (Atom, Sublime, VS Code, or WebStorm), create a new file and save it with the name index.js.

Once you’re done with that, write your first line of Node.js:

// File: index.js

console.log("Hello Node.js!");

Let's run the program! To execute your Node.js file, go back to your command line terminal and navigate to the directory in which you've saved the index.js file. Once you're there, run:

node index.js

You can see that it will log Hello Node.js! to the terminal.

What's next?

Well, that was simple! If you've read around about Node.js, you've surely come across require() statements, used to include code from other files into your application's entry point (the index.js file).

Next, head over to Understanding Node.js Modules where you'll learn about modules, how they work, and why they're so important.

Introducing a truly understandable Node.js tutorial series for beginner and intermediate developers.

Whether you're just starting out or you already have some Node.js experience, this tutorial will guide you through all you need to know to find your way trough any existing Node.js project, as well as writing your own Node.js projects from scratch. Except for having some experience with Javascript, there's no prior knowledge needed.

I'm writing this tutorial series because when I started out, everything about Node.js seemed so complicated. The code sample on the official website made it seem like it's some complicated server language, and I didn't know how it compares to what I previously knew. Having come from PHP and Ruby, it felt like I wouldn't be able to write the same things using Javascript. Fortunately, nothing could be further from the truth.

In this tutorial you'll learn what Node.js is, what it isn't, how it's going to help your development career and how you can use it to be more productive in your web development projects. Let's start!

What is Node.js?

Node.js is V8, the JavaScript engine running inside Google Chrome, bundled together with a couple of libraries for I/O (Input/Output) operations. Basically, it's what Chrome is using to interact with files on your computer using code written in Javascript.

Where does all the confusion come from? Node.js isn't any special variation of Javascript, it is just plain, modern Javascript, but it's running everywhere instead of just your browser.

When running Javascript in the browser, you're enclosed in a sandbox environment that doesn't allow you to interact with files on your computer, ensuring a secure browsing environment for the site's visitors, while executing Javascript using Node.js is meant to behave like a standard programming language.

Node.js became so popular because it allows you to use Javascript on both front-end and back-end. This way, every developer in your team can understand what’s happening on the entire stack, and make changes if necessary.

Why should you learn Node.js?

The two big mainstream uses are web application servers and asset pipeline automation.

Node.js uses an event-driven, non-blocking input/output model. Node.js scales flawlessly, and works perfectly for high-throughput server-side applications. Translated into simple English, this means that Node.js can be used to write applications that can handle large numbers of concurrent requests.

However, Node.js may not provide everything you need from a language out of the box. Many times you'll find yourself needing additional functionality, that you'll usually find available as a nicely maintained open source package. If you enjoy building things out of reusable blocks, then Node.js is definitely the for you. I sure do.

Node.js Goodies

More reasons to learn Node.js are Express, npm, and Webpack.

Express is a modular application server for Node.js that allows you to write scalable web applications. Express focuses on code reusability and development costs, giving you a strong foundation for your application. It's lightweight and super fast.

Node's package manager "npm" is a very powerful tool that can be used to share your code as packages. Not only that, but it allows you to reuse code written by other developers inside your own package, as dependencies. Just imagine having more than 600,000 packages at your fingertips.

Surely, everyone developer has heard at least once about Webpack by now. Webpack is a build tool that puts all of your assets, including CSS, Javascript, images, and even fonts, in a dependency graph. Webpack lets you use require() in your source code to point to local files, and decide how they're processed in your final bundle. If you're building a complex front-end application with many static assets that require processing, then Webpack will give you great benefits.

Still not convinced?

Node.js and Javascript have been voted as the most popular development framework and programming in the 2018 StackOverflow Developer Survey.

For the sixth year in a row, Javascript is the most commonly used programming language. It's amazing how popular the Node.js stack has become and you shouldn't be missing out!

What you already need to know

As you might have thought, there are some prerequisites before you can start learnng Node.js. When I started out, I had a strong programming and web development background, so the learning curve was almost non-existent.

1. Javascript ― Node.js is basically server side Javascript, so knowing Javascript is an absolute must. If you're familiar with other programming languages, learning Javascript will be fairly straightforward.

2. HTTP ― If you're building web applications, you will need to understand HTTP client and server paradigm. You'll do just fine with some basic understanding and knowing what verbs like GET, POST, PUT, and DELETE are used for.

3. Asynchronous Programming ― JavaScript is asynchronous in nature and so is Node.js. For example, Node.js will not wait for a HTTP request's response to arrive before executing the next line of code, and you'll rely heavily on callback functions.

Besides these, I'd recommend trying to understand what the concept of REST is and how it works, and reading up about the Node.js Event Loop. It might all seem like a lot to learn, but in reality they're simple concepts with fancy names.

What's next?

You'll learn how to create our own package and add dependencies to it later in this tutorial. Next, head over to Installing Node.js the Right Way, to install Node.js, write and run your first Node.js "Hello world!" program.

Welcome to a place of creative thinking and ambitious ideas!

I am Alex Grozav, and this article is the first piece of my little corner of expressivity. I'm a self-thaught artist and developer who is writing open source projects to make the web a better place in his free time.

I'm overly passionate about what I do. It's not about what moderately exciting 9-to-5 job you have, whether you work at Google, Apple, or Microsoft. It's not even about how much you enjoy coding, or how much work you put into your tasks.

It's about what you do with your free time. It's about whether you ever felt the need to stay up until late at night, finishing an idea you had for this small project of yours, born out of dreams slightly bigger than you can carry. You're pretty sure it's not going to work this time either, yet you do it anyway, because that's who you are.

I know you, because it takes one to know one.

I'm a creative overthinker

I love making my ideas come to life. It's the one thing I know best and the one thing I enjoy the most about my career choice. I think, I design, I overthink, I code, and then, I test. To me, every web project is a beautiful mix of code, math and creativity, and having something that I created in its entirety, makes me always give it my best.

Unlike most people, I read mostly news about Technology and Web Development, the two things I'm most enthusiastic about. I hate reading news about violence and useless celebrities, because there's an exaggerated amount of both.

I'm the kind of person whose brain gets stupidly excited when it reads about breakthroughs in Medicine and Technology, because the thought that mankind is getting closer to the harmonious future we see in movies makes me feel good. I believe that, as developers, we're building towards a substantial part this future, one commit at a time.

This used to be my portfolio

This site used to have countless hours of work featured in its pages. I used to sell HTML Templates on Themeforest and JavaScript plugins on CodeCanyon. This website is the place where I used to host and preview them.

Hundreds of sales, hundreds of comments, so little time to maintain all of them. When all you want to do is create something better every time you start writing code, you always end up enjoying your new project more than your old one.

In the end

I have turned it into a blog because sharing my code, designs, videos, reviews, creative thoughts and ideas will be far more valuable to my readers than anything else I made could have been.