Un système de restriction des permissions est actuellement en cours d'ajout à Node.js.

Ce système permet de restreindre les possibilités du programme d'agir sur le système, notamment:

• système de fichier en lecture/ecriture
• exécuter de nouveaux programmes
• démarrer un worker_thread Node.js

C'est le même système utilisé par Deno pour augmenter la sécurité des applications lancés avec le runtime.

Un article intéressant sur les avantages de Deno.

Il y a de nombreux avantages en DX, notamment le support Typescript directement par Deno mais surtout je découvre un avantage non négligeable en terme de sécurité de la supply chain.

Les scripts (comme les entrées de scripts dans le package.json en Node.js) de Deno sont lancés dans un shell isolé spécial (deno_task_shell) et n'ont accès qu'a leur input, ce qui les empêche d'aller farfouiller sur le système (ce genre de truc https://arstechnica.com/information-technology/2022/03/sabotage-code-added-to-popular-npm-package-wiped-files-in-russia-and-belarus/)

L'approche des dépendances via URL est aussi intéressante, on est capable de charger du code depuis une URL tout en respectant des versions, des checksum, etc.

C'est toujours bien de voir émerger d'autres runtime car cela amène de nouvelles idées et concepts.

Par contre il ne faut pas se voiler la face, il y a très peu de chances que Deno ou Bun puissent remplacer Node.js.

L'industrie a mis des années avant de faire confiance à Node.js et aujourd'hui je vois difficilement les entreprises se tourner vers un nouveau runtime simplement pour des histoires de design ou quelques % de perfs en plus sachant que le coût d'adoption à l'échelle industriel est très élevé.

Deno annoncent quelques changements avec notamment le support des packages JS en provenance de NPM!

Ils annoncent aussi qu'ils souhaitent être le moteur JS le plus rapide.

Je ne serais pas surpris que cela soit poussé par la sortie de Bun.js qui a de très bonnes performances, supporte le typescript et les packages NPM

Un retour d'expérience sur Deno plutôt que Node.js en production