3 ms·

> Sure, it's nice to naively import your dependencies from some random URL like it's 2005, but there is a good reason why the JS ecosystem at large has moved aw

> Sure, it's nice to naively import your dependencies from some random URL like it's 2005, but there is a good reason why the JS ecosystem at large has moved away from that. That's not what you do with Deno in practice, though. Typically, you'll import modules from a trusted registry like deno.land/x/ or esm.sh. The nice way about how Deno handles modules is it becomes dead simple to host a private registry. Also, if anything, JS has moved toward this because this is how ES modules work in the browser (which Deno tries to emulate). > Deno seems like a nice "fun" runtime for throwaway weekend projects, but most of the things that make it "fun" come from ignoring complexity that will fall on your feet once you try to do anything more sophisticated. I don't buy this on account of several folks are already using Deno in production, and from my own experience, Deno Deploy was insanely easy to become productive with. Can you be more specific on how Deno ignores complexity? On the topic of package.json, I feel most of its utility can be replaced by import maps and deno.json.

hobofan 4y ago
> Typically, you'll import modules from a trusted registry like deno.land/x/ or esm.sh. Great, with that we've already tremendously increased the attack surface of supply-chain attacks for your normal copy-past install, and moved it into an entirely unmoderated space (unlike npm, which has a process for reporting and removing malware[0]). E.g. there is nothing preventing someone from buying a typo version of those domains (like deon.land, which I just bought), and distributing those to users and have them install malware. E.g. add `import * as flat from "https://deon.land/x/flat@0.0.15/mod.ts https://deon.land/x/flat@0.0.15/mod.ts";` (or any other deno->deon changed import) to your file, and see what happens. > The nice way about how Deno handles modules is it becomes dead simple to host a private registry. There is more to running a registry than just exposing files. And if you want a similarly simplistic registry for NPM, I don't think NPM will prevent you from using the URL of a packages .tar.gz. > several folks are already using Deno in production Just because _some_ people are using it in production doesn't mean it's a good idea. And for many of those projects, you are basically sacrificing ecosystem access. While I'm all for reducing your dependency tree, I know that I wouldn't want to build a project without access to most of them. > Deno Deploy was insanely easy to become productive with So are most edge computing focused solutions nowadays. Cloudflare Workers, which I used for the deon.land gag also only took me 5 mins to set up from scratch. > Can you be more specific on how Deno ignores complexity? Apart from the things above, just take a look at any discussion about supply chain security (especially the major incidents) of the last few years and ask yourself "Does deno have measures to prevent them?", and you'll end up answering most of them with "No". And that was mostly done in the name of simplicity, to help onboarding new developers, with no consideration to what can (and will) happen to the users of those services once they make it into production. While Deno is now adding parts of those features, it is an all aspects still trying to peddle it's simplistic alternatives, and is breeding a community, that want to have it in that insecure way. That's incredibly worrying to me. [0]: https://docs.npmjs.com/reporting-malware-in-an-npm-package https://docs.npmjs.com/reporting-malware-in-an-npm-package
- toastercat 4y ago
  > Great, with that we've already tremendously increased the attack surface of supply-chain attacks for your normal copy-past install, and moved it into an entirely unmoderated space (unlike npm, which has a process for reporting and removing malware[0]). E.g. there is nothing preventing someone from buying a typo version of those domains (like deon.land, which I just bought), and distributing those to users and have them install malware. This is a price of the inherent decentralized idea that the Deno team has. I foresee tooling or other forms of validation in the future to prevent things like this, but until then, just as a team requires discipline to not do things like blindly updating all of their ^ dependencies in Node world, `npm install`ing a package with a gigantic and risky dependency graph, deleting the lockfile, or mistyping the name of a package (`npm install reactt`), some degree of discipline is necessary with Deno as well. > Just because _some_ people are using it in production doesn't mean it's a good idea. Maybe their use cases are different than yours, and maybe the benefits of Deno outweigh the negatives given their circumstances! The ecosystem argument is always silly because if X is popular before Y is, X will have a more vibrant ecosystem. Deno apparently has npm interop, though, I have not used it. > So are most edge computing focused solutions nowadays. Cloudflare Workers, which I used for the deon.land gag also only took me 5 mins to set up from scratch. I am also a fan of Cloudflare Workers. That doesn't change the fact that I am still productive with Deno Deploy. > Apart from the things above, just take a look at any discussion about supply chain security... Thanks, but this is not a specific answer.

hobofan 4y ago

> Typically, you'll import modules from a trusted registry like deno.land/x/ or esm.sh. Great, with that we've already tremendously increased the attack surface of supply-chain attacks for your normal copy-past install, and moved it into an entirely unmoderated space (unlike npm, which has a process for reporting and removing malware[0]). E.g. there is nothing preventing someone from buying a typo version of those domains (like deon.land, which I just bought), and distributing those to users and have them install malware. E.g. add `import * as flat from "https://deon.land/x/flat@0.0.15/mod.ts https://deon.land/x/flat@0.0.15/mod.ts";` (or any other deno->deon changed import) to your file, and see what happens. > The nice way about how Deno handles modules is it becomes dead simple to host a private registry. There is more to running a registry than just exposing files. And if you want a similarly simplistic registry for NPM, I don't think NPM will prevent you from using the URL of a packages .tar.gz. > several folks are already using Deno in production Just because _some_ people are using it in production doesn't mean it's a good idea. And for many of those projects, you are basically sacrificing ecosystem access. While I'm all for reducing your dependency tree, I know that I wouldn't want to build a project without access to most of them. > Deno Deploy was insanely easy to become productive with So are most edge computing focused solutions nowadays. Cloudflare Workers, which I used for the deon.land gag also only took me 5 mins to set up from scratch. > Can you be more specific on how Deno ignores complexity? Apart from the things above, just take a look at any discussion about supply chain security (especially the major incidents) of the last few years and ask yourself "Does deno have measures to prevent them?", and you'll end up answering most of them with "No". And that was mostly done in the name of simplicity, to help onboarding new developers, with no consideration to what can (and will) happen to the users of those services once they make it into production. While Deno is now adding parts of those features, it is an all aspects still trying to peddle it's simplistic alternatives, and is breeding a community, that want to have it in that insecure way. That's incredibly worrying to me. [0]: https://docs.npmjs.com/reporting-malware-in-an-npm-package https://docs.npmjs.com/reporting-malware-in-an-npm-package

toastercat 4y ago
> Great, with that we've already tremendously increased the attack surface of supply-chain attacks for your normal copy-past install, and moved it into an entirely unmoderated space (unlike npm, which has a process for reporting and removing malware[0]). E.g. there is nothing preventing someone from buying a typo version of those domains (like deon.land, which I just bought), and distributing those to users and have them install malware. This is a price of the inherent decentralized idea that the Deno team has. I foresee tooling or other forms of validation in the future to prevent things like this, but until then, just as a team requires discipline to not do things like blindly updating all of their ^ dependencies in Node world, `npm install`ing a package with a gigantic and risky dependency graph, deleting the lockfile, or mistyping the name of a package (`npm install reactt`), some degree of discipline is necessary with Deno as well. > Just because _some_ people are using it in production doesn't mean it's a good idea. Maybe their use cases are different than yours, and maybe the benefits of Deno outweigh the negatives given their circumstances! The ecosystem argument is always silly because if X is popular before Y is, X will have a more vibrant ecosystem. Deno apparently has npm interop, though, I have not used it. > So are most edge computing focused solutions nowadays. Cloudflare Workers, which I used for the deon.land gag also only took me 5 mins to set up from scratch. I am also a fan of Cloudflare Workers. That doesn't change the fact that I am still productive with Deno Deploy. > Apart from the things above, just take a look at any discussion about supply chain security... Thanks, but this is not a specific answer.