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?

  • ksynwa
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    3 years ago

    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?

    • dinomugOPM
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      3 years ago

      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.
    • jokeyrhyme
      link
      fedilink
      arrow-up
      1
      ·
      3 years ago

      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 the deno runtime 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)