7 ms·

> Using URLs means there are no rules enforced How is using a URL different from using a NPM package? In both cases you can specify a module, a version, and ne

> Using URLs means there are no rules enforced How is using a URL different from using a NPM package? In both cases you can specify a module, a version, and need to trust some remote server that it is sending you the correct files. > the code hosted at that URL can change out from under you without any warning The same can and has happened with NPM. See left-pad.

nikisweeting 6y ago
The difference is that NPM as an org has a lot more to lose if they mess up everyones packages or serve incorrect versions than some random person's website. Left pad was promptly fixed! That's an argument for a centralized package manager, not against. If it were hosted on some private server we'd all still be screwed. https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/left-pad
- philips 6y ago
  I think that is a strong argument for a community immutable cache like Go uses though. Not a centralized namespace.
  - nikisweeting 6y ago
    I think go is the perfect example of how not to do module source distribution. Because of their URL dependency system Golang projects work great as static binaries, but they're almost impossible to distribute as source builds via system package managers. A lot of my arguments for why this is a bad thing are already laid out here: https://docs.monadical.com/s/against-curl-sh https://docs.monadical.com/s/against-curl-sh (I don't know how many more replies we have left before we hit the HN nesting limit, but this is a thing I care deeply about and I'm down to keep chatting on Twitter or other forums if anyone here prefers)
    - bobthebuilders 6y ago
      I think what Deno is great because it lets me be decentralized. We did so much with open source only to throw it all away with npm and go back to a centralized corporate entity :(
      - hombre_fatal 6y ago
        package.json supports urls, git urls (and branch + commit ids), even local file paths. If you wanted that, what's stopping you?
        deleted 6y ago
        [deleted]
- mark_and_sweep 6y ago
  > The difference is that NPM as an org has a lot more to lose if they mess up everyones packages How is that important? Most Deno packages are imported from GitHub (or deno.land). Neither NPM nor GitHub want to lose your code. > Left pad was promptly fixed! That's an argument for a centralized package manager, not against. This is not an argument for a central package manager, but an argument for a central package repository. Deno is already a "central package manager". Similar to NPM in Node development, Deno is the default tool to download code in Deno development. Both with Node or Deno, you can download code in other ways, too. Nobody forces you to load code from URLs via import statements or NPM packages via npm install and commonjs require. (Also, when it comes to executing random code from the internet, Deno has a sandbox. Node doesn't.) And yes, well maintained package repositories are great. Whether centrally or decentrally managed repos are better is up for debate, though. In any case, if you want to use NPM packages in Deno, I'd recommend https://www.skypack.dev/ https://www.skypack.dev/. It's "NPM packages from a URL", so, as we have established earlier, it's just as much reliant on trust and potentially unstable as anything in life, but at least their left-pad is patched...
  - nikisweeting 6y ago
    I am not proposing that Deno remove URL support, I think it's great that they allow importing from URL as an option. I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. This would allow full inter-compatibility with the existing packaging ecosystem and allow people to continue using whatever packaging method they prefer.
    - mark_and_sweep 6y ago
      > I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. Import maps allow you to do that, see: https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map...
      - nikisweeting 6y ago
jay_kyburz 6y ago
Using URLs is like having an iframe to somebody else's website on your website.
- Soremwar 6y ago
  Whot? How is that even comparable? It's third party code after all, the same happens when you use a library in any other language
  - jay_kyburz 6y ago
    A library in any other language is saved local and built with your project. My understanding is these are loaded from URLs if they are not in the cache. If a domain changes hands, you could be served anything.
    - laurencerowe 6y ago
      Presumably you’d use deno bundle for a production build so you’re not directly using the source files.
- wperron 6y ago
  Maybe... it depends on the amount of _trust_ that you put in the remote domain. My prediction is that the Deno ecosystem will aggregate around a few, large repositories that will have good guarantees araound immutability and good track records to addressing vulnerabilities. For large projects like React, lodash, eslint whatever, I expect some of them will start hosting their libraries on their own networks, like it used to be when Javascript was only frontend and you would have a script tag importing jQuery directly from jQuery's CDN. The reason it worked was because jQuery was sidely known and trusted.

nikisweeting 6y ago

The difference is that NPM as an org has a lot more to lose if they mess up everyones packages or serve incorrect versions than some random person's website. Left pad was promptly fixed! That's an argument for a centralized package manager, not against. If it were hosted on some private server we'd all still be screwed. https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/left-pad

philips 6y ago
I think that is a strong argument for a community immutable cache like Go uses though. Not a centralized namespace.
- nikisweeting 6y ago
  I think go is the perfect example of how not to do module source distribution. Because of their URL dependency system Golang projects work great as static binaries, but they're almost impossible to distribute as source builds via system package managers. A lot of my arguments for why this is a bad thing are already laid out here: https://docs.monadical.com/s/against-curl-sh https://docs.monadical.com/s/against-curl-sh (I don't know how many more replies we have left before we hit the HN nesting limit, but this is a thing I care deeply about and I'm down to keep chatting on Twitter or other forums if anyone here prefers)
  - bobthebuilders 6y ago
    I think what Deno is great because it lets me be decentralized. We did so much with open source only to throw it all away with npm and go back to a centralized corporate entity :(
    - hombre_fatal 6y ago
      package.json supports urls, git urls (and branch + commit ids), even local file paths. If you wanted that, what's stopping you?
      - deleted 6y ago
        [deleted]
mark_and_sweep 6y ago
> The difference is that NPM as an org has a lot more to lose if they mess up everyones packages How is that important? Most Deno packages are imported from GitHub (or deno.land). Neither NPM nor GitHub want to lose your code. > Left pad was promptly fixed! That's an argument for a centralized package manager, not against. This is not an argument for a central package manager, but an argument for a central package repository. Deno is already a "central package manager". Similar to NPM in Node development, Deno is the default tool to download code in Deno development. Both with Node or Deno, you can download code in other ways, too. Nobody forces you to load code from URLs via import statements or NPM packages via npm install and commonjs require. (Also, when it comes to executing random code from the internet, Deno has a sandbox. Node doesn't.) And yes, well maintained package repositories are great. Whether centrally or decentrally managed repos are better is up for debate, though. In any case, if you want to use NPM packages in Deno, I'd recommend https://www.skypack.dev/ https://www.skypack.dev/. It's "NPM packages from a URL", so, as we have established earlier, it's just as much reliant on trust and potentially unstable as anything in life, but at least their left-pad is patched...
- nikisweeting 6y ago
  I am not proposing that Deno remove URL support, I think it's great that they allow importing from URL as an option. I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. This would allow full inter-compatibility with the existing packaging ecosystem and allow people to continue using whatever packaging method they prefer.
  - mark_and_sweep 6y ago
    > I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. Import maps allow you to do that, see: https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map...
    - nikisweeting 6y ago

jay_kyburz 6y ago

Using URLs is like having an iframe to somebody else's website on your website.

Soremwar 6y ago
Whot? How is that even comparable? It's third party code after all, the same happens when you use a library in any other language
- jay_kyburz 6y ago
  A library in any other language is saved local and built with your project. My understanding is these are loaded from URLs if they are not in the cache. If a domain changes hands, you could be served anything.
  - laurencerowe 6y ago
    Presumably you’d use deno bundle for a production build so you’re not directly using the source files.
wperron 6y ago
Maybe... it depends on the amount of _trust_ that you put in the remote domain. My prediction is that the Deno ecosystem will aggregate around a few, large repositories that will have good guarantees araound immutability and good track records to addressing vulnerabilities. For large projects like React, lodash, eslint whatever, I expect some of them will start hosting their libraries on their own networks, like it used to be when Javascript was only frontend and you would have a script tag importing jQuery directly from jQuery's CDN. The reason it worked was because jQuery was sidely known and trusted.