what is it? how does it work? and why it matters
Node.js has a massive ecosystem. It’s completely open-source and is used by more than 11 million developers worldwide.
NPM is an acronym that stands for Node Package Manager. It is a JavaScript library registry that is accessible via the CLI. It’s the space where the cool kids go to publish their open-sourced projects, share helpful tools, and manage packages a project may use.
NPM is no doubt popular but, still, not everyone appears to be aware of it.
Yes. NPM’s main usage is to install packages and this article will go over the basics of getting started. You don’t need to be an advanced pro to get a project moving with the help of NPM. Rather, these tips and tricks will help speed up your workflow and give you access to a large resource pool of open-sourced packages.
But before we begin….
In short, a package is basically a folder containing all the code you need for a particular feature. It can be a pluggable module or library of scripts that do something.
That something can be anything you can dream, think, and imagine. How about a real world example?!
Cheerio.js is a fast, flexible, and lean implementation of core jQuery designed specifically for the server.
Cheerio parses markup and provides an API for traversing/manipulating the resulting data structure. It does not interpret the result as a web browser does.
Here is what a popular code snippet from the cheerio.js API looks like:
request.get('https://news.ycombinator.com/', (err, request, body) => {
if (err) { return next(err); }
const $ = cheerio.load(body);
const links = [];
$('.title a[href^="http"], a[href^="https"]').slice(1).each((index, element) => {
links.push($(element));
});
res.render('api/scraping', {
title: 'Web Scraping',
links
});
});
You can find more snippets here
One thing all packages have in common is that they’re all JavaScript based.
Projects are often created by developers tapping into the plethora of open-sourced projects for solutions that other developers have developed. Sharing code is how code communities grow and NPM is one of the reasons why JavaScript has propelled its way forward in popularity, especially among the new generation of developers.
So why does it need to be managed?
Imagine a world where you have more than a dozen compulsory packages that are used throughout your JavaScript project. Now imagine having to go source and download every single package from wherever the source developer is hosting it.
The source developer has to deal with hosting cost — and if the package download reaches a high enough volume, that cost will increase proportionately.
However, with NPM, there is no cost to hosting unlimited public packages. The cost of privacy is low enough that your weekly dose of a Starbucks venti coffee probably costs more.
Basically, it’s free to make things free through NPM.
It’s good to note that for NPM to work, you’ll need to go and download node.js onto your machine.
A local installation is basically downloading all the files you need into your project’s folder. Your packages list sits inside a json file called package.json and when the command to install is called, NPM will go to the registry and download everything stated in this list.
To install everything, use the following command in your CLI:
npm install
If you don’t already have it, a folder called node_modules will also appear in your project’s folder. Most of the time, you can just ignore the folder — but don’t delete it. Just keep it there. Node.js will take care of everything for you after that.
To install packages that aren’t already in your package.json list, you can use the following command in your CLI:
npm install [package-name-here]
When you add the --save flag at the end of the command above, it’ll also save the package name and current version into your package.json file.
It’s also good to note that you should not add the node_modules folder as part of your version control systems like GIT or SVN. Instead, just share your package.json file.
Keep in mind that the node_modules folder is heavy. It’s so heavy that if you’re working in a team and you’re downloading the node_modules folder without node.js to coordinate everything, it can take a very long time to push and pull code from your code versioning spaces.
Use npm install instead to deal with all the packages you’ve accumulated over the course of your application’s creation process.
Let’s say you’re running multiple projects that are using the same node modules. However, you have to download and store these node modules, which can take up space on your local machine.
If only you had the ability to consolidate and point its usage to a shared space…
Well, you’re in luck — a global installation does just that.
The only thing that you need to note is that when you create global installations, the packages aren’t added to your project’s package.json file, so this is something you need to be aware of.
To save your package in the global space, use the following command:
npm install -g [package-name-here]
And that’s basically it. The -g flag lets NPM knows that you want to install it in the global space, so it won’t appear inside your project’s node_module folder.
As you would have noticed by now, the base command for npm is basically npm add followed by the package name.
However, there’s a little bit more to using NPM than just adding new packages. Here’s a list of common commands that are available with NPM.
This will let you install the package in the global space and make it accessible to your application from a common area. If you have it in the global space, you don’t need to install it in your local directory to make things work.
npm install [package-name-here] -g
Most packages are small in size but it can add up over time. To clear out some space, or conflicting modules, you can use uninstall to get rid of the downloaded package.
npm uninstall [package-name-here] -g
Sometimes, conflicts in packages can happen, or you just don’t need them anywhere. Here’s how you uninstall a local package via npm.
Go to the root of your project’s folder and use the following command:
npm uninstall [package-name-here]
Sometimes, you’re just not sure if you’ve got a particular package or not. You can search for it using the following command:
npm search [package-name-here]
It’s not too bad if you just have a few global packages installed. However, over time, it’s easy to build up this space with more than a few dozen packages — especially if you’ve been playing and experimenting with code.
Here is the command that will give you a list of all the globally installed packages.
npm ls -g
Need more details on what’s been installed? Use the following command and your CLI will print out more details about each package installed such as dependencies, versions, sources and any other information available against the package.
npm ls -gl
Same idea as listing all the global packages — but at a local level. Go to the root of your project’s folder and run the following command:
npm ls
This will give you more details on all the local packages installed within a particular project directory. Go to the root of your project’s folder and run the following command:
npm ls -l
Every now and then, packages get updated to fix bugs or to work properly with the latest releases of other frameworks and libraries that they might be used in.
However, updating everything individually can be a tedious task. npm comes with the ability to update everything all at once. Here’s how you do it for globally installed packages.
npm update -g
The same concept of updating all packages can also be applied to local packages. Just drop the -g tag that tells npm to target the global space.
Be sure to go to the root of your project’s folder and run the following command:
npm update
Go to the rood of your app’s directory and create a new package.json file. You can create one via the CLI using the following command:
touch package.json
Your file should look something like this:
{
"name": "your app name"
, "version": "0.0.1"
, "private": true
, "dependencies": {
"express": ">=2.5.0"
, "jade": ">= 0.16.4"
, "mongoose": ">=2.3.10"
}
}
Or add whatever dependencies you need for your application needs. Then all you have to do is run npm install and viola! You don’t have to manually run npm install [your-package-name] for every single dependency.
And that’s basically it on how to use NPM.
If you’re just consuming npm packages and using them for your projects, the knowledge here is enough. Most of the time, these commands will suffice and anything else sits in the realm of intermediate and power users.
The battle is on. The warriors enter the arena to the loud cheers of frontend developers around the ring. In the right corner, React, introduced in May 2013 by Facebook. In the left is Angular, an open source project born in September 2016 and maintained by Google. The bell rings. It’s on.
But is it really a fair fight? What is it that sets the two apart? And who should you be betting on in 2020 and beyond?
Before we dive in, it’s worth taking a moment to check on what our mighty warriors have been up to these past 12 months. Have they been slacking? Or training non-stop to be the best in the JavaScript frontend arena?
Released in February 2020, Angular 9.0.0 has been long awaited by Angular devs. Angular 9.0.0 introduces a bundle of additions and fixes to Angular. Among other improvements, Angular 9 replaces the ViewEngine (VE) compiler with Ivy, Angular’s next-generation compilation and rendering pipeline.
First, Ivy offers significantly improved performance. Second, Ivy includes a streamlined toolset for debugging, testing, and building large and complex web applications. It also helps reduce bundle sizes, especially for larger applications.
With Angular 10 just around the corner performance remains one of the top priorities for framework developers.
So, on one side of the ring, Angular is focusing on improved performance and reduced package size. On the other side of the ring, the latest React updates are focused on bug fixes and plugging potential security vulnerabilities. In addition, React 16+ attempts to improve asynchronous programming capabilities.
Released in February 2020, React 16.13.0 includes numerous deprecation warnings for unsafe methods and components, as well as bug fixes, naturally. In terms of new features, the latest additions were already introduced in React 16.9.0, released in August 2019. The new features were focused on improved testing of asynchronous code and measuring performance.
Now that we’re all up to speed on the latest developments, we can take a deep breath, and dive in.
The first and main difference between Angular and React is in standalone capabilities and scope. Angular is a full-featured MVC (Model-View-Controller) framework while React is a lightweight JavaScript UI component library.
In this sense, pitting Angular against React in the arena is akin to a Judoka facing a Sumo wrestler. Each has advantages over the other. But with each bringing a different approach and technique the winner is anyone’s guess.
What this means for you, as a web app developer, is that you need to consider the components and features you will need to have out of the box. Angular packs most of what an average web app needs on-install, and includes capabilities React does not, like built-in routing and dependency injection. React, on the other hand, is not as demanding in terms of structure and approach. Though it lets you offload less-critical functionality to other libraries, it also means adding dependencies and complexity to the project code.
Angular was the first major framework to fully adopt TypeScript – a superset of JavaScript and statically typed language. You can write Angular applications in both JavaScript and TypeScript, but TypeScript is often the choice of programmers looking to make their code more compact and easier to debug than pure JavaScript.
React is based on JavaScript ES6+ and JavaScript XML (JSX) – a template language running on top of JavaScript. What makes JSX (supported also in Vue.js) unique is that it stores markup and logic in a single file. While some may find issues with this approach, JSX has a strong typing system to statically analyze code. This makes it especially friendly to new developers and those of us prone to typos (read: everyone).
It’s worth noting that while you can use TypeScript in React, it is not natively supported.
One of the most significant technical differences between React and Angular is how each manages changes in document contents, layout, and structure. While Angular makes use of a Real (HTML) DOM (Document Object Model), React uses a Virtual DOM.
This difference in approach is perhaps one of the reasons why so many frontend developers prefer React over Angular. The virtualization of the DOM makes for significantly better runtime performance.
(Source: https://illustrated.dev/react-vdom)
With a real DOM, like in Angular, the entire tree structure of HTML tags needs to be updated whenever there are any changes. React instead creates a new virtual DOM whenever change is detected, and compares it to the “real” DOM. If the two differ, only then is the real DOM modified where the alterations were made.
The developers managing the Angular open-source project had no choice but to take note of this issue. More and more developers were switching to React to improve app performance. So action was taken. In the recently made official Angular compilation and rendering pipeline Ivy, you can implement an iterative DOM. This approach, while quite different from React’s DOM virtualization, can potentially save up to 30% runtime memory, especially with large Angular applications.
Data binding is a technique to synchronize UI and logic. React uses one-way data binding (sometimes called Downward Binding) and Angular uses two-way data binding.
The comparison between React and Angular in UI and business logic synchronization and data binding makes for a perfect representation of just how different the approaches are.
In Angular, changes to input in the UI can make changes to the model / component state and vice versa. In React, when you update the model /component state, the change will be rendered in the UI element. Modifying the UI element, however, will not affect the model / component state. You can change this functionality in React by using callbacks or state management libraries like Redux.
Bidirectional data binding may mean less code and less complexity in data flows. On the other hand, Angular can force the developer to be extremely careful and keep two-way data binding within a component. Without such care, you may find yourself with components in undesirable states and multiple sources of truth. These have a tendency to turn into long nights of bugchasing.
(Source: https://www.cleveroad.com/blog/angular-vs-react)
This is just one of the many ways Angular tends to push developers into designing and coding their applications in a certain way. In contrast, React provides flexibility, but also depends on other libraries to enable added functionality. This dependency can, in turn, turn cumbersome with a growing stack of technologies, libraries and components that require constant upkeep.
This is not a popularity contest. Sure, when you compare frontend libraries, frameworks or even toothbrushes, odds are you will opt for the most popular and highly rated one. Toothbrushes and herd psychology aside, there are good reasons to consider the availability (and relevance) of both community support and official documentation. It helps if the documentation is good, or at the very least complimented by well-written tutorials and an active community on topical forums.
In this sense popularity does count and React is by far the more popular than Angular no matter what metrics you use. It has more stars and followers on GitHub, more downloads, and is listed as more beloved than Angular/Angularjs in stackoverflow’s 2019 developer survey by quite a margin. 74.5% of developers surveyed loved React, while only 57.6% expressed their affection for Angular/Angularjs.
Why is this significant? As you well know, pretty much all developers of all proficiency levels turn to Google and community forums with questions. This is in fact true for most professions today: when you’re not sure how to do something, Google it and/or ask in the right places online.
With more users asking questions and answering them on the Internet, you have a better chance of Googling up a solution to your problem. In that sense, React has an edge over Angular. Having a larger user-base is not the only advantage React has. Being a Facebook project, it is frequently updated and documentation is available quickly.
Angular is managed by Google, which adds credibility to its reputation. However, since it is less favored by developers you may find yourself relying on available documentation that is insufficient for most.
For a developer considering which of the two they should learn there is an endless list of comparisons and discussion. If those aren’t enough, you can always add to them and ask the community what the right solution is for your specific requirements. We don’t need to tell you that at the end of the day, what matters is what you prefer as a developer, and what each project requires.
At this point, the Judoka and Sumo fighters in our metaphorical arena are giving us weird looks. Of course they are. The real battle here is not in the ring. It is between the frontend developers around the ring.
It’s worth noting that the differences we listed are only a handful of the properties that differentiate React from Angular. From licensing to backward compatibility and approaches to native app development – there are more differences than similarities, really. Especially when you consider that both are essentially used for the same goal – web application development. Very different means to an end.
If we had to pick a winner, it would be you, the web developer. Why? Because understanding the most significant points of distinctions between Angular and React puts you in a perfect position to select the fighter you want at your side as you tackle your next project.