> Litterally anywhere. On Github, on the Deno webpage, in a slack chat message.
So, Instead of convenience I now have to hunt for some urls somewhere.
> It is how the browsers has worked for ages
1. Deno is not a browser
2. For ages any website would try and host those libs themselves (or bundle them... and host themselves).
From development point of view having to hunt down urls "in slack messages" is a nightmare.
> If the package has deps Deno will download them too in the same manner.
In which manner? How does Deno know that a dependency X lives at url Y that was posted in a Slack channel somewhere?
> It also means that if there is any problems or dissatisfaction in how your dependencies are hosted you are free to change
How am I free to change it if a package I depend on specifies it dependency at a url x, and that package's dependencies specify them at url Y?
> What do you mean it doesn't mean anything? It means that there is not one single place where you have to get your dependencies from.
Right now with npm I'm not getting my dependencies from a single place called npmjs.org. I'm getting from a company-provided package repository. How does that work with "any random url you got from Slack"?
BTW. Developers arguing that package management is bad is a new thing to me.
> So, Instead of convenience I now have to hunt for some urls somewhere.
Well yes.. but usually that is true for npm packages as well when one search for documentation or source code.
> Deno is not a browser
It tries hard to immitate the browser context and does so very successfully IMO.
> From development point of view having to hunt down urls "in slack messages" is a nightmare.
Well, that was just an example. I am just pointing out the concept of decentralization. You don't have to be reliant on npm and their systems.
> In which manner? How does Deno know that a dependency X lives at url Y that was posted in a Slack channel somewhere?
Since each dependency is an url, it will fetch all deps and download them in order to cache it. Pretty much how npm works as well, except that npm in reality only fetches from the npm registry even if I think it's possible to add github repos to the package.json.
You also don't need a package.json which is great especially for smaller scripts.
> Developers arguing that package management is bad is a new thing to me.
It's not inherintly bad. I personally prefer to not be reliant on an american mega corporation which is known for it's anti-competitive practices and woke agenda. Their interest will certainly not align with mine.
> How am I free to change it if a package I depend on specifies it dependency at a url x, and that package's dependencies specify them at url Y
Well in that specific case you would need to download the entire tree and host it yourself. Then you can change the url.
I mean, if you're happy with node and npm. Continue to use it. You don't have to switch to Deno but I am convinced it's the future for server side javascript. It's just... nicer in general.
> but usually that is true for npm packages as well
It's not true in a very, very, very big and important detail: once I found the packages, I do any of `npm/yarn/pnpm install package-name`, and it resolves the package, and all its dependencies
> Since each dependency is an url, it will fetch all deps and download them in order
How is each dependency a url when it's decidedly not? Or is deno silently re-writes all `package.json`s?
> You also don't need a package.json
Oh. Now you don't need a package json. So... How does Deno resolve dependencies for a package?
> I personally prefer to not be reliant on an american mega corporation which is known for it's anti-competitive practices and woke agenda.
Instead you rely on something that literally relies on megacorps for Rust, V8, Typescript.
> Well in that specific case you would need to download the entire tree and host it yourself.
Wow. So much convenience. I'm simply astounded. How is this a good thing again?
> I am convinced it's the future for server side javascript. It's just... nicer in general.
So far you've done literally nothing to show how it's nicer. For a developer it's a major pain in the butt: resolve dependencies manually, download them manually, grep+replace urls...
So, Instead of convenience I now have to hunt for some urls somewhere.
> It is how the browsers has worked for ages
1. Deno is not a browser
2. For ages any website would try and host those libs themselves (or bundle them... and host themselves).
From development point of view having to hunt down urls "in slack messages" is a nightmare.
> If the package has deps Deno will download them too in the same manner.
In which manner? How does Deno know that a dependency X lives at url Y that was posted in a Slack channel somewhere?
> It also means that if there is any problems or dissatisfaction in how your dependencies are hosted you are free to change
How am I free to change it if a package I depend on specifies it dependency at a url x, and that package's dependencies specify them at url Y?
> What do you mean it doesn't mean anything? It means that there is not one single place where you have to get your dependencies from.
Right now with npm I'm not getting my dependencies from a single place called npmjs.org. I'm getting from a company-provided package repository. How does that work with "any random url you got from Slack"?
BTW. Developers arguing that package management is bad is a new thing to me.