👩🏾‍🏫 👩🏼‍🚀 🧖🏼 5 claims to Deno 💃🏿 ⚖️ 🤵

Foreword

I am not part of the deno team. I'm not his fan. I do not follow him. I don’t even really believe in him. But seeing the negative reaction of the community, I just can not help but intervene. In this article, I would like to consider the most common claims against Deno and offer an alternative point of view.

Deno - the killer of NodeJs

This is not true. This way it is promoted only by “deno witnesses”, crazy fans, or hype-hungry translators. As far as I know, even Ryan Dahl himself (Deno author) does not position his development as a replacement or alternative to NodeJs. Rather, his vision is "what may be the same NodeJs in the future." The concept, if you want (we do not scold the concepts of cars or smartphones for their impracticality in modern realities). From Ryan’s point of view, NodeJs has some problems. And he showed the community a certain idea of how these problems could be solved. And you can participate in this. Come to GitHub right now and describe the architectural problems you see. Discuss them. Come up with solutions.

I don't think Deno will ever replace NodeJs. But it can become for him what TypeScript for JavaScript has become.

Import by URL

Many people look at it a bit from the wrong angle. The idea is to drop the global dependency list for the entire project. So that instead of one big package.json you have your own independent list of dependencies in each of your modules / files. I see several advantages in this.

If you need to write some feature, you are not required to look at what dependencies are already used in the project. You are not limited to them. You use what you need.
You can add functionality without looking at legacy. The new modules will have their own dependencies, and the old ones will have their own.
During the migration of a large project to a new version of some dependency, you can change the code base and roll out these changes in parts.

But for this approach, you need the ability to describe the dependencies for each module. Name, version and where to get this dependency. As a result, import with a URL. And that's not even Deno's notion. This is part of the standard . It's just that everyone is used to working as they are used to. But this is not the only way.

But how do I now work without the Internet?

Just like you would work with NodeJs. What Deno, that NodeJs download dependencies in a separate directory. Only in NodeJs do you launch this npm install, and Deno does this automatically the first time you launch it.

It sounds interesting, but I refuse!

No problem. There is such a thing - import maps . And Deno supports him , although not fully. Thus, you can describe synonyms for all dependencies by coming to an analogue package.json. But you will not be limited to this:

Individual modules can still use their own dependency versions, ignoring import map as needed.
The import maps specification suggests the ability to specify multiple sources for download. Deno does not currently support this. But technically it is possible. You could indicate several sources, and if one is not available, the dependency will be downloaded from the other.
```
{
   "imports": {
      "moment/": [
         "https://deno.land/x/moment/",
         "https://raw.githubusercontent.com/lisniuse/deno_moment/master/"
      ]
   }
}
```

Without npm, I can’t deliver the console utility globally!

Well, actually you can . deno installThis is an analog npm install --global. Deno downloads, compiles the required library into a binary, and saves it globally. The difference is that you must give the library some kind of permission. That is, a globally installed package will not get access to the network, or to files, or wherever without your consent.

Strange feeling deja vu

And it is not without thoroughness. Deno is the same NodeJs . I see only a few differences:

Deno rejected backward compatibility. What allowed him to realize the same things, using not his own bike, but the bike described in the specification of the language. I am sure that if some kind of “Node-next” came out without backward compatibility, we would get about the same thing that Deno offers. And NodeJs is gradually moving in this direction: all new ES chips (such as ES-modules, top-level-await, etc.) are gradually being introduced into NodeJs.
Refusal of the general list of dependencies. This can be a plus or minus. It depends on the specific cases. But it cannot be denied that such an architecture has a right to exist.
The idea is to prevent the script from accessing the system without explicit permission.

That's all the differences in my opinion. So I see no reason to hate Deno. Is that his aggressive PR people :)

5 claims to Deno