6 ms·

The more I learn about how it imports external/third-party code [1] the more I like it. It's got none of the hangups of NPM. No package.json nonsense (there are

The more I learn about how it imports external/third-party code [1] the more I like it. It's got none of the hangups of NPM. No package.json nonsense (there are great script runners if you need them), and no cruft when importing external code (e.g. no need for yarnclean). The registry they do maintain is unique and immutable, which I was not sold on until I had this discussion [2]. I do still think they need some more guidance around how that works, and some contingencies in the event of bad actors, but it's just as good as NPM's registry imho. Native TS is a nice convenience for projects which call for it, and compiling is much more streamlined than bolting it onto a project yourself. It's worth noting that it does support plain JS, just the ESM flavor. And last but not least is the stdlib, which roughly aims to prevent the need for a million one-line packages spread out across the registry. Network throughput performance is impressive to say the least, and with leveraging Rust I can only see that getting better. The more I learn about Deno the more that I'm liking it. [1] https://deno.land/manual/linking_to_external_code https://deno.land/manual/linking_to_external_code [2] https://github.com/denoland/deno/discussions/11809#discussioncomment-1219406 https://github.com/denoland/deno/discussions/11809#discussio...

spankalee 5y ago
It's quite a bit worse than npm. Without bare module specifiers (like `import {html} from 'lit-html'`) to act as an abstraction over location you have to import directly from a URL, but what URL? Packages either have to be self-hosted, or very often npm packages are loaded via CDNs. There are several CDNs that host the same packages (unpkg, Skypack, jspm, jsDelivr/esm.run) so there's no single canonical URL to load anything from and each module that loads a package could load from a different CDN, or simply load a slightly different but compatible version, causing multiple copies of the packages to be loaded. There's a huge benefit to abstracting over package names, and Deno mostly throws it all away. It does support import maps, but you'd need tooling that doesn't fully exist yet to crawl and dedupe a module graph and at that point it'd basically be npm but a lot slower with no registry to use for metadata.
- andrew_ 5y ago
  > It's quite a bit worse than npm. That's a rather subjective take. The rest of your comment can be fulfilled by `trex` https://nicedoc.io/crewdevio/Trex https://nicedoc.io/crewdevio/Trex. Perhaps it's been a while since you took a good look at how the ecosystem has evolved. I just started giving Deno a hard look last week and I've already found answers for needs like this.
  - spankalee 5y ago
    Aren't most takes on here subjective? I don't think we label most posts with "Only my opinion, but..." event though that applies to almost everything here. Anyway... Trex doesn't do anything about transitive dependencies and package deduplication, what my critique is about.
nightpool 5y ago
I was just having this discussion with a friend of mine this morning. How is this not the exact same mistake Go made when it was released in 2015? They spent years and years walking back the issues that "go get" had in favor of a real, actual package manager. I know Deno encourages users to use versioned imports, which works around some of the bigger problems that Go had, but creates a lot more problems in terms of upgrading transitive dependencies. How is this a step forward?
- whateveracct 5y ago
  Ignoring hard problems for short-term gains is an easy way to get market share.
  - lucacasonato 5y ago
    We don't ignore these problems. We find web compatible ways to solve them. If you had done just about 3 seconds of research before posting, you would have noticed we have support for import maps[1]. These elegantly solve the issue in a way that also works in the browser. No node_modules needed :-) [1]: https://deno.land/manual@v1.13.1/linking_to_external_code/import_maps https://deno.land/manual@v1.13.1/linking_to_external_code/im...
    - spankalee 5y ago
      Import maps are great if you know all the mappings you want to make. That requires that you know every way that conceptually the same packages are imported in the entire transitive module graph, which is hard enough on its own, but also requires crawling the whole live module graph to discover all the imports. I don't see how this isn't just npm-but-worse.
      - whateveracct 5y ago
        It'll eventually evolve into npm-but-different once Deno gains more adoption and its users learn they need a real package manager. And the cycle continues.
ramesh31 5y ago
>Okay so it's coupled to Microsoft's take on Javascript. What about Flow or any of the other compiles-to-Javascript languages? What's wrong with using Babel with sourcemaps? This is kind of like saying "Oh it supports Javascript? So now I'm tied to Netscape's take on browser scripting?" at this point. Typescript has won the JS compiler wars and become the defacto standard for the community.
- spankalee 5y ago
  Which slightly incompatible version of TypeScript though? edit to add: I'm serious. JavaScript tries very hard to not have backward breaking changes. TypeScript does have breaking changes at about ever minor release. The TypeScript team manages the project as a versioned tool, not as a distributed environment like the web. afaik, Deno hasn't really solved this problem, so there's a chance your code breaks when Deno upgrades its TypeScript version.
  - oatmealsnap 5y ago
    That's always a concern, though. Node has breaking changes, too.
  - Vinnl 5y ago
    It's a somewhat relevant concern, but also less so because breaking changes in TypeScript are usually semantic (type-checking) ones and most of the times make it error on bugs (i.e. code that hopefully isn't in your codebase already, and if it is, you'll want to take it out). Deno doesn't do type checking, it just strips TypeScript's type annotations, which they're far more careful about breaking. Even so, they could limit such breakage to major Deno versions with other breaking changes, if necessary. Not sure if they do.
  - deleted 5y ago
    [deleted]
- deleted 5y ago
  [deleted]

spankalee 5y ago

It's quite a bit worse than npm. Without bare module specifiers (like `import {html} from 'lit-html'`) to act as an abstraction over location you have to import directly from a URL, but what URL? Packages either have to be self-hosted, or very often npm packages are loaded via CDNs. There are several CDNs that host the same packages (unpkg, Skypack, jspm, jsDelivr/esm.run) so there's no single canonical URL to load anything from and each module that loads a package could load from a different CDN, or simply load a slightly different but compatible version, causing multiple copies of the packages to be loaded. There's a huge benefit to abstracting over package names, and Deno mostly throws it all away. It does support import maps, but you'd need tooling that doesn't fully exist yet to crawl and dedupe a module graph and at that point it'd basically be npm but a lot slower with no registry to use for metadata.

andrew_ 5y ago
> It's quite a bit worse than npm. That's a rather subjective take. The rest of your comment can be fulfilled by `trex` https://nicedoc.io/crewdevio/Trex https://nicedoc.io/crewdevio/Trex. Perhaps it's been a while since you took a good look at how the ecosystem has evolved. I just started giving Deno a hard look last week and I've already found answers for needs like this.
- spankalee 5y ago
  Aren't most takes on here subjective? I don't think we label most posts with "Only my opinion, but..." event though that applies to almost everything here. Anyway... Trex doesn't do anything about transitive dependencies and package deduplication, what my critique is about.

nightpool 5y ago

I was just having this discussion with a friend of mine this morning. How is this not the exact same mistake Go made when it was released in 2015? They spent years and years walking back the issues that "go get" had in favor of a real, actual package manager. I know Deno encourages users to use versioned imports, which works around some of the bigger problems that Go had, but creates a lot more problems in terms of upgrading transitive dependencies. How is this a step forward?

whateveracct 5y ago
Ignoring hard problems for short-term gains is an easy way to get market share.
- lucacasonato 5y ago
  We don't ignore these problems. We find web compatible ways to solve them. If you had done just about 3 seconds of research before posting, you would have noticed we have support for import maps[1]. These elegantly solve the issue in a way that also works in the browser. No node_modules needed :-) [1]: https://deno.land/manual@v1.13.1/linking_to_external_code/import_maps https://deno.land/manual@v1.13.1/linking_to_external_code/im...
  - spankalee 5y ago
    Import maps are great if you know all the mappings you want to make. That requires that you know every way that conceptually the same packages are imported in the entire transitive module graph, which is hard enough on its own, but also requires crawling the whole live module graph to discover all the imports. I don't see how this isn't just npm-but-worse.
    - whateveracct 5y ago
      It'll eventually evolve into npm-but-different once Deno gains more adoption and its users learn they need a real package manager. And the cycle continues.

ramesh31 5y ago

>Okay so it's coupled to Microsoft's take on Javascript. What about Flow or any of the other compiles-to-Javascript languages? What's wrong with using Babel with sourcemaps? This is kind of like saying "Oh it supports Javascript? So now I'm tied to Netscape's take on browser scripting?" at this point. Typescript has won the JS compiler wars and become the defacto standard for the community.

spankalee 5y ago
Which slightly incompatible version of TypeScript though? edit to add: I'm serious. JavaScript tries very hard to not have backward breaking changes. TypeScript does have breaking changes at about ever minor release. The TypeScript team manages the project as a versioned tool, not as a distributed environment like the web. afaik, Deno hasn't really solved this problem, so there's a chance your code breaks when Deno upgrades its TypeScript version.
- oatmealsnap 5y ago
  That's always a concern, though. Node has breaking changes, too.
- Vinnl 5y ago
  It's a somewhat relevant concern, but also less so because breaking changes in TypeScript are usually semantic (type-checking) ones and most of the times make it error on bugs (i.e. code that hopefully isn't in your codebase already, and if it is, you'll want to take it out). Deno doesn't do type checking, it just strips TypeScript's type annotations, which they're far more careful about breaking. Even so, they could limit such breakage to major Deno versions with other breaking changes, if necessary. Not sure if they do.
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]