😼 🛫 🛶 5 réclamations à Deno 🌝 😼 👩🏿‍🔧

Préface

Je ne fais pas partie de l'équipe deno. Je ne suis pas son fan. Je ne le suis pas. Je ne crois même pas vraiment en lui. Mais vu la réaction négative de la communauté, je ne peux pas m'empêcher d'intervenir. Dans cet article, je voudrais examiner les réclamations les plus courantes contre Deno et offrir un point de vue alternatif.

Deno - le tueur de NodeJs

Ce n'est pas vrai. De cette façon, il n'est promu que par des «témoins de déni», des fans fous ou des traducteurs avides de battage médiatique. Pour autant que je sache, même Ryan Dahl lui-même (auteur de Deno) ne positionne pas son développement comme un remplacement ou une alternative aux NodeJs. Au contraire, sa vision est «ce qui pourrait être les mêmes NodeJ à l'avenir». Le concept, si on veut (on ne gronde pas les concepts de voitures ou de smartphones pour leur impraticabilité dans les réalités modernes). Du point de vue de Ryan, NodeJs a quelques problèmes. Et il a montré à la communauté une certaine idée de la manière de résoudre ces problèmes. Et vous pouvez y participer. Venez dès maintenant sur GitHub et décrivez les problèmes architecturaux que vous voyez. Discutez-en. Trouvez des solutions.

Je ne pense pas que Deno remplacera jamais NodeJs. Mais cela peut devenir pour lui ce que TypeScript pour JavaScript est devenu.

Importer par URL

Beaucoup de gens le regardent sous un mauvais angle. L'idée est de supprimer la liste de dépendance globale pour l'ensemble du projet. Ainsi, au lieu d'un gros package.json, vous avez votre propre liste indépendante de dépendances dans chacun de vos modules / fichiers. J'y vois plusieurs avantages.

Si vous avez besoin d'écrire une fonctionnalité, vous n'êtes pas obligé de regarder quelles dépendances sont déjà utilisées dans le projet. Vous n'êtes pas limité à eux. Vous utilisez ce dont vous avez besoin.
Vous pouvez ajouter des fonctionnalités sans regarder l'héritage. Les nouveaux modules auront leurs propres dépendances, et les anciens auront les leurs.
Lors de la migration d'un grand projet vers une nouvelle version d'une certaine dépendance, vous pouvez modifier la base de code et déployer ces modifications par parties.

Mais pour cette approche, vous devez pouvoir décrire les dépendances de chaque module. Nom, version et où obtenir cette dépendance. Par conséquent, importez avec une URL. Et ce n'est même pas la notion de Deno. Cela fait partie de la norme . C'est juste que tout le monde est habitué à travailler comme il est habitué. Mais ce n'est pas le seul moyen.

Mais comment puis-je maintenant travailler sans Internet?

Tout comme vous travailleriez avec NodeJs. Que Deno, que les NodeJs téléchargent les dépendances dans un répertoire séparé. Ce n'est que dans NodeJ que vous lancez cela npm install, et Deno le fait automatiquement la première fois que vous le lancez.

Cela semble intéressant, mais je refuse!

Aucun problème. Il y a une telle chose - importer des cartes . Et Deno le soutient , mais pas complètement. Ainsi, vous pouvez décrire des synonymes pour toutes les dépendances en arrivant à un analogue package.json. Mais vous ne serez pas limité à ceci:

Les modules individuels peuvent toujours utiliser leurs propres versions de dépendance, en ignorant le mappage d'importation si nécessaire.
La spécification d' importation des cartes suggère la possibilité de spécifier plusieurs sources à télécharger. Deno ne prend actuellement pas en charge cela. Mais techniquement, c'est possible. Vous pouvez indiquer plusieurs sources, et si l'une n'est pas disponible, la dépendance sera téléchargée de l'autre.
```
{
   "imports": {
      "moment/": [
         "https://deno.land/x/moment/",
         "https://raw.githubusercontent.com/lisniuse/deno_moment/master/"
      ]
   }
}
```

Sans npm, je ne peux pas fournir l'utilitaire de console à l'échelle mondiale!

Eh bien, en fait, vous pouvez . deno installCeci est un analogue npm install --global. Deno télécharge, compile la bibliothèque requise dans un binaire et l'enregistre globalement. La différence est que vous devez donner à la bibliothèque une sorte d'autorisation. Autrement dit, un package installé à l'échelle mondiale n'aura pas accès au réseau, ni aux fichiers, ni ailleurs sans votre consentement.

Étrange sentiment de déjà-vu

Et ce n'est pas sans minutie. Deno est le même NodeJs . Je ne vois que quelques différences:

Deno a rejeté la compatibilité descendante. Ce qui lui a permis de réaliser les mêmes choses, en utilisant non pas son propre vélo, mais le vélo décrit dans les spécifications de la langue. Je suis sûr que si une sorte de «Node-next» sortait sans compatibilité descendante, nous obtiendrions à peu près la même chose que Deno offre. Et NodeJs évolue progressivement dans cette direction: toutes les nouvelles puces ES (telles que les modules ES, le niveau supérieur attendent, etc.) sont progressivement introduites dans les NodeJs.
Refus de la liste générale des dépendances. Cela peut être un plus ou un moins. Cela dépend des cas spécifiques. Mais on ne peut nier qu'une telle architecture a le droit d'exister.
L'idée est d'empêcher le script d'accéder au système sans autorisation explicite.

Voilà toutes les différences à mon avis. Je ne vois donc aucune raison de détester Deno. Est-ce que ses relations publiques agressives :)

5 réclamations à Deno