Dependencies

[00:00:01]
>> All right, let's talk about dependencies for a second. Deno handles dependencies in an entirely different way. It doesn't have a concept of NPM and NPM modules and the way that we've installed things in the past, and you'll see that as we go forward today. Dependencies have been a long point of controversy, for as long as I can remember.

[00:00:23]
I'm sure since computers have existed. And this is true across all languages, all platforms, all runtimes, it doesn't matter if it's NPM, it doesn't matter if it's Maven, it doesn't matter if it's Newgen, everywhere dependencies are just hard. This is one of the hardest problems that people have to solve.

[00:00:40]
And the reason for this is that dependencies almost always take other dependencies, then those dependencies have dependencies. And so what you end up with is this giant, exploded dependency tree where you have to take a million dependencies to do something very, very simple. And all of those dependencies could have bugs or security flaws, right?

[00:01:01]
How do you know that the cross-env package isn't used by a dependency somewhere down the line that you don't even know about? You don't, there's no way for you to know that. So the dependencies manager's job, by dependency manager, like NPM is to keep track of dependencies. And to make sure that if the chain gets updated, your whole project doesn't break.

[00:01:24]
You may have seen a file in Node called the Package lock file. And that's what the Package lock file is attempting to do, is to allow you to lock your dependencies down so that if someone updates a dependency somewhere it doesn't break the project when someone else tries to run it or when you deploy it.

[00:01:39]
So what's wrong with the way Node handles dependencies today? What's wrong with NPM? And how can that be different? Well, there's a couple of different things. One of them is that NPM is the central package repository for Node. Yes, technically anyone can set up a package repository. Many people have private ones for enterprises, secure ones, but by and large it is the place for you where you find a package.

[00:02:09]
Is that a bad thing? Maybe, maybe not. You may recall last year there were some escalating issues with NPM as it tried to generate enough revenue to stay afloat. Serving up packages to every JavaScript developer but which by the way, is the most popular programming language according to multiple surveys.

[00:02:31]
Serving a package to everybody in the world is an expensive operation. People talk about a lot about cloud computing, but what most people don't know about cloud computing is the highest cost. In cloud computing is bandwidth. And bandwidth is how much you move out of the cloud. So if you put data in the cloud and you pull it out, you have to pay for that.

[00:02:53]
And NPM is basically covering these massive bandwidth bills. And that money has got to come from somewhere. And they almost didn't make it. But GitHub stepped in and purchased NPM earlier this year, possibly preventing what could have been the collapse of essentially where all of our Node packages live.

[00:03:10]
Which is kind of a terrifying idea, it's a single point of failure. Again, is that a bad thing? I don't know, maybe, maybe not. It's a philosophical question. It's incredibly convenient to have a central place to look for any code that you might need rather than having it strewn all over the Internet.

[00:03:31]
But it's also probably that single point is why the adaption of Node has been so quick. Because it's so easy to find what you need. But for that convenience, the trade off is a single point of failure and one repository that's now owned by a single corporation, Microsoft.

[00:03:51]
Some people may not feel good about that. And some people are fine with it. The other thing that he talks about in his video is he laments the package.json file. So, this is one of the things that I found to be a bit of a nitpick. But, Ryan's problem with the package.json file is that he feels like that there's a lot of boilerplate in it and that it's bloat.

[00:04:21]
Like it has no point, and for what? And I kind of agree with this. So, let's do this. Let's look at the dependency hell branch and let's do this. Let's just initialize this project for Node or for NPM, rather. So I'm just gonna do NPM init. And when I do that, it just starts asking me questions.

[00:04:59]
So it's like, what's the name? It's deno-exercise. What's the version? I don't even know yet. I'm just trying to get started, I don't know, 0.0.1. The description, exercises for deno, right? And then it just keeps going on, and on, and on. You're like, I don't know what any of this stuff is.

[00:05:16]
Why do I need keywords? Does this really matter? What's the licence? I don't even understand this and then you're like yes. And if you have a package that json fil. And we've all just kind of gotten used to doing this. Like we don't even really think about it.

[00:05:29]
We just accept that this is the case. But do we really need all this? Now sometimes we do. Things like VS Code is taken to using some of these properties. So that if you publish a VS Code extension, it looks at the version and the description some of these things to determine metadata about your published extension.

[00:05:51]
But for the most part, this is boilerplate stuff that we don't want. Now, I should point out that you can, if you didn't know this, what you can do instead, this is for free, you can just do. So you can do npm init-y. And that will just give you all the defaults and create the package.json file for you and fill it all in based on what it can tell.

[00:06:14]
But this is his primary hang up with this package.json files that he feels like it's just gotten out of hand and that it's mostly extraneous, unnecessary information. The other problem is that the package.json file configures to what we would call the bloat of configuration files in repos. And this is become a real topic of controversy in the JavaScript community, the project that contain this course is a Gatsby project.

[00:06:48]
And look at all of the config files that are in the root directory of this thing. There's a package, and a package lock, and a Gatsby config, and a prettier, and a gitignore. And it's just the explosion of config files, it's just becoming a real problem. It's common to have dozens of them in your root directory.

[00:07:07]
And so the package.json is just another one of those. The other thing that he talks about is the Node modules folder. And the Node modules folder has become notorious for just being exceptionally large. You have no idea how many dependencies you're getting self into and often the folder just balloons into a laughable size.

[00:07:32]
So let me show you how this happens. So some packages, let's install something very common. So, let's install Axios. By the way, I didn't know until like three years ago that you don't have to type install, you can just type dash I. See what I mean about not knowing things, that's me, the other guy.

[00:07:52]
I don't know that you can do just dash just I there. And this one install Axios. So let's take a look. So what did we get when we did that? We got Axios, okay? Which we asked for but then we also got follow redirects. Now I have no idea why Axios needs that.

[00:08:07]
I don't have a problem with that, right? That's fine. Clearly, Axio salts some reason to use that and not rewrite that code themselves. Okay, that's not a big deal. Now let's do something else. Let's install React Scripts. Now React Scripts is the library that React uses when you do a Create React App.

[00:08:29]
This is the core, this is the main module, all that's built on if you were to create an app with Create React App. And what's gonna happen here is it's gonna pull down that React Scripts and all of the dependencies that React Scripts needs. And you can see this is taking a little bit of time.

[00:08:49]
And it's a lot faster than it used to be. But we used to have this joke that you could run NPM install, and then go make lunch, call your mother, watch some TV, come back and NPM install would be done. Now it's a lot faster now. But the reason why it's so slow and it takes so long is that it is pulling down a massive amount of packages.

[00:09:08]
And in fact, when this thing is done, this Node module's folder is gonna be somewhere in the neighborhood of 350 megabytes worth of JavaScript. And that's just a ton of code and there will be so many modules inside this Node modules folder that we will no longer have any idea what any of them are for or why they're there.

[00:09:29]
This has just become something that we've accepted as just sort of a general truth that the Node modules folder is enormous. And that's just how it is. And Ryan just sort of feels like that's a problem. And you can see here, because I don't have a gitignore, even VS Code is like there's so many files in this project.

[00:09:50]
I can't even track them all. And that's because this is the Node modules folder now. Look at it, look at this, right? And this is why we make jokes about how we're pulling down all of the Internet to build a website. It It just feels incredibly heavy. Now this is not a shot at React by any stretch.

[00:10:10]
React is a phenomenal thing. It's just to point out it is a ubiquitous problem. It is the situation in Node. And so the way that Deno thinks about dependencies is completely differently. It doesn't have a Node modules folder. It handles them in an entirely different way. In cases where you need to deploy a Node app to your server, the NPM install has to happen there as well.

[00:10:39]
So many of you have probably accidentally checked in your Node modules folder, and it just takes forever. Or you tried to publish it on accident, it takes forever. And so you have to publish your project and then run an NPM install on the server. And that's an extra step and can take a while.

[00:10:55]
What Deno really wants, what it really wants is for you to be able to compile your Deno project into a single executable, that you can then deploy like an EXE, something about it. You have a JavaScript project, you compile it, it's an EXE, you send it off to a server and it runs, whether Deno is installed or not.

[00:11:17]
So that's what Deno really wants to do here. That's the long-term vision.