You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 16, 2020. It is now read-only.
Deno is a new javascript/typescript runtime from the creator of node.js
One big difference between Deno and Node is the module system and package manager, or lack of one.
Deno has no manifest file (node uses package.json) or lockfile (package-lock.json), instead preferring to import third party code by directly referencing it by url, much like with a <script> tag in the browser:
import{serve}from"https://deno.land/[email protected]/http/server.ts";asyncfunctionmain(){constbody=newTextEncoder().encode("Hello World\n");forawait(constreqofserve(":8000")){req.respond({ body });}}main();
The initial user experience is very slick, deno automatically downloads and locally caches imported urls but from a reproducibility point of view it struggles from the same issues as Go has traditionally struggled with:
pointing at the tip of a master branch means every commit to that branch may result in breaking changes being pulled in without checking first.
urls stop working altogether stopping the running of the program altogether
pointing directly to a source file lacks useful metadata about the project:
license
changelog
a way of discovering other versions of the same package
man-in-the-middle attacks, with no integrity checking you can't be sure that what you just downloaded is exactly the same as before
One problem that it copies from node.js is that a dependency tree may contain multiple versions of the same library, but unlike node it doesn't have a good way to flatten the tree because the urls and version numbers are hardcoded within each dependency.
Deno does have a registry service but it currently redirects http requests to the upstream source rather than caching the result. I suspect the registry will end up heading along a similar path as the notary service being developed for the Go ecosystem.
There was an issue opened about adding IPFS support but has since been closed: denoland/deno#428
oof. Not any time soon.
I can conceive of it happening some day, years in the future. But IPFS is not very good right now. And Deno is not very good right now. We cannot dedicate time to that at this point.
Closing tho I'm open to the idea. Will be open to discussing further in 2020.
The text was updated successfully, but these errors were encountered:
Deno is a new javascript/typescript runtime from the creator of node.js
One big difference between Deno and Node is the module system and package manager, or lack of one.
Deno has no manifest file (node uses package.json) or lockfile (package-lock.json), instead preferring to import third party code by directly referencing it by url, much like with a <script> tag in the browser:
The initial user experience is very slick, deno automatically downloads and locally caches imported urls but from a reproducibility point of view it struggles from the same issues as Go has traditionally struggled with:
One problem that it copies from node.js is that a dependency tree may contain multiple versions of the same library, but unlike node it doesn't have a good way to flatten the tree because the urls and version numbers are hardcoded within each dependency.
Deno does have a registry service but it currently redirects http requests to the upstream source rather than caching the result. I suspect the registry will end up heading along a similar path as the notary service being developed for the Go ecosystem.
There was an issue opened about adding IPFS support but has since been closed: denoland/deno#428
The text was updated successfully, but these errors were encountered: