- cross-posted to:
- programming
- javascript
- cross-posted to:
- programming
- javascript
One of the great advantages of Deno is the absence of a package manager, this section is practically monopolized by two corporations (MS with npm and FB with yarn); Deno has shown itself to be a more independent ecosystem with respect to its counterpart, Node. Do you think that this decision taken by the core team was the right one? would you have preferred it to become a foundation instead of a company? Will it become a more independent solution or will it end up like Node with OpenJS? being a front entity for a few big techs that lobby the ecosystem?
You must log in or register to comment.
Can some explain what deno does? From what I understand it’s meant to be a drop in alternative to node. Also why does it not have a package manager? How do you get dependencies then?
Basically it’s an improved Node.js (created by the same developer of node).
Main features/differences:
- Build with Rust.
- Secure by default. No file, network, or environment access, unless explicitly enabled.
- Supports TypeScript out of the box.
- Ships only a single executable file.
- Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt).
- Has a set of reviewed (audited) standard modules that are guaranteed to work with Deno: deno.land/std.
- There is no concept of a package manager as external modules are imported directly into local modules.
It’s not a drop-in alternative, it has a drastically different standard library and APIs
It’s still JavaScript/TypeScript, so code that manipulates data structures or parses strings or whatever will be fine, but code that touches I/O or other OS stuff pretty much needs a rewrite
Dependencies work kinda’ similar to in Go: you have full URLs (or relative URLs) in your
import ... from ...statements, and thedenoruntime goes and fetches them (or reads them from a cache if you’ve instructed it to pre-cache things, like you might if building a docker image or something)
