Does Deno implement its own TypeScript compiler? Even if it does, it's entirely at the mercy of Microsoft who are the only ones who develop Typescript specs.
Which you import just like you would in a browser.
> Does Deno implement its own TypeScript compiler?
Deno is a JS engine that aims for maximum compatibility with browsers.
While not exactly a second class citizen, losing Typescript (if it comes to that) is something the platform can survive. Ryan is on record saying that adding Typescript support at a very early stage was probably a mistake.[1]
A url. The files are cached. You can always explicitly vendor dependencies and use relative imports (or import maps) if you don't want to rely on random urls.
> Also, if I have more than 10 packages, it makes sense to bundle them
Yes but with ES modules you can just import them straight into the code and there is really no need for a package manager.
> Does Deno implement its own TypeScript compiler? Even if it does, it's entirely at the mercy of Microsoft who are the only ones who develop Typescript specs.
This may be somewhat true. However I am not using typescript so I am not really sure about this.
My point is not really tied to the language typescript which I am sure will continue just fine. What I am much more worried about is all the packages hosted on npm. At any time Microsoft could do something to restrict it in ways I can't control. Highly unlikely that something extreme will happen perhaps, but I don't trust Microsoft enough.
For example, I could easily see them forcing everyone to use github for node packages in the future etc.
> Which url? How do I find this URL? What happens when that package specified dependencies?
Litterally anywhere. On Github, on the Deno webpage, in a slack chat message. It is how the browsers has worked for ages and there's never been any issues with that. If the package has deps Deno will download them too in the same manner.
It also means that if there is any problems or dissatisfaction in how your dependencies are hosted you are free to change it to another hosting solution.
> These are empty words that literally mean nothing. The rest is at the link so as not to have the same conversation in several places.
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. You may think of it as something negative, but I think it's great.
> 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...
You still need packages
> no Microsoft lock-in
Does Deno implement its own TypeScript compiler? Even if it does, it's entirely at the mercy of Microsoft who are the only ones who develop Typescript specs.