4 ms·

Deno fans, how are you using this language? I think they have some interesting ideas, but it increasingly just integrates Node.JS features, and from a casual o

by nawgz 4y ago

Deno fans, how are you using this language? I think they have some interesting ideas, but it increasingly just integrates Node.JS features, and from a casual observer's viewpoint I'm not entirely sure I understand what their initial goals were and if they have drifted far from them. It looks like compromised principles from where I sit, which can often be a bad thing - especially because package.json was one of the best parts of NodeJS and so it looks like their principles were made without a plan. Thoughts?

llanowarelves 4y ago
Start off by doing things the deno-"native" way and it's very fun. Most or all of the js tooling woes go away. It starts as just a .ts file that works. I love it for small CLI utilities. There are some quirks[0] but it's well designed UX overall. Stuff like node stdlib support is a necessary evil for some things. Like sharp (libvips binding) and nestjs didnt work at all before that iirc. And alternatives a lot of work to make. 0: https://github.com/denoland/deno_std/discussions/2102 https://github.com/denoland/deno_std/discussions/2102
hobofan 4y ago
> especially because package.json was one of the best parts of NodeJS and so it looks like their principles were made without a plan Yes, that's very much my impression as well. Their approach to package management feels very much like throwing out the baby with the bathwater. 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. And while the npm ecosystem has some problems, npm (and preferably pnpm) is a package manager of a quality that few other programming languages have. 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.
- buzzerbetrayed 4y ago
  I still have never understood why people consider the lack of package management in Deno a plus. It sounded interesting to me when I very first watched the deno sales pitch back in the day. But when I tried to use it for something non trivial it was so clearly worse to me. To each their own I guess
  - toastercat 4y ago
    Deno doesn't lack package management, but it does lack a CLI like npm. There are community CLIs (like trex), however.
- toastercat 4y ago
  > 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
petre 4y ago
> It looks like compromised principles from where I sit, which can often be a bad thing Or they're not fundamentalists. I don't like package.json either, but I couldn't care less if it gets more people using Deno.
- nawgz 4y ago
  > I don't like package.json either I think you're seeing it from the wrong perspective. I, as an ardent NodeJS user (hooray UI development), think NodeJS has a lot of problems. Less now, but a lot. Any list of pros and cons for NodeJs looks a bit like this: Pros: * Package management Cons: * JavaScript The fact that the deno guys were like "yeah, this whole NodeJS thing sucks, let's throw it all out", only to never have an answer for easy package management, looks incredibly foolish from my perspective. NodeJS might be the single best language for package management today. I agree with the point that adding support for it is pragmatic, but I am asking the question: how was such a pragmatic thing thrown out in the first place for "principled" reasons? Those principles look very foolish to me, both then and especially now.
  - petre 4y ago
    The problem is that npm package management is so stupidly easy that it creates other problems like dependency creep and supply chain attacks. Perhaps the Deno team wanted to do away with this but could not or maybe bother with it later on.

by nawgz 4y ago

llanowarelves 4y ago

Start off by doing things the deno-"native" way and it's very fun. Most or all of the js tooling woes go away. It starts as just a .ts file that works. I love it for small CLI utilities. There are some quirks[0] but it's well designed UX overall. Stuff like node stdlib support is a necessary evil for some things. Like sharp (libvips binding) and nestjs didnt work at all before that iirc. And alternatives a lot of work to make. 0: https://github.com/denoland/deno_std/discussions/2102 https://github.com/denoland/deno_std/discussions/2102

hobofan 4y ago

> especially because package.json was one of the best parts of NodeJS and so it looks like their principles were made without a plan Yes, that's very much my impression as well. Their approach to package management feels very much like throwing out the baby with the bathwater. 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. And while the npm ecosystem has some problems, npm (and preferably pnpm) is a package manager of a quality that few other programming languages have. 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.

buzzerbetrayed 4y ago
I still have never understood why people consider the lack of package management in Deno a plus. It sounded interesting to me when I very first watched the deno sales pitch back in the day. But when I tried to use it for something non trivial it was so clearly worse to me. To each their own I guess
- toastercat 4y ago
  Deno doesn't lack package management, but it does lack a CLI like npm. There are community CLIs (like trex), however.
toastercat 4y ago
> 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

petre 4y ago

> It looks like compromised principles from where I sit, which can often be a bad thing Or they're not fundamentalists. I don't like package.json either, but I couldn't care less if it gets more people using Deno.

nawgz 4y ago
> I don't like package.json either I think you're seeing it from the wrong perspective. I, as an ardent NodeJS user (hooray UI development), think NodeJS has a lot of problems. Less now, but a lot. Any list of pros and cons for NodeJs looks a bit like this: Pros: * Package management Cons: * JavaScript The fact that the deno guys were like "yeah, this whole NodeJS thing sucks, let's throw it all out", only to never have an answer for easy package management, looks incredibly foolish from my perspective. NodeJS might be the single best language for package management today. I agree with the point that adding support for it is pragmatic, but I am asking the question: how was such a pragmatic thing thrown out in the first place for "principled" reasons? Those principles look very foolish to me, both then and especially now.
- petre 4y ago
  The problem is that npm package management is so stupidly easy that it creates other problems like dependency creep and supply chain attacks. Perhaps the Deno team wanted to do away with this but could not or maybe bother with it later on.