4 ms·

the comparison doesn't make sense. typescript inherently has advantages over javascript (well, unless Javascript officially supports types which isn't happening

the comparison doesn't make sense. typescript inherently has advantages over javascript (well, unless Javascript officially supports types which isn't happening anytime soon (https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations)). deno does not have any inherent advantages over node if they continue to support node functionality. I won't be surprised if package.json support is next. literally the purpose and sole advantage of deno was that they did not have node cruft. things like speed are not inherent advantages. it's true deno is written in rust, but node is basically v8, which has its own advantages.

paulddraper 3y ago
> deno does not have any inherent advantages over node if they support node Could you be more specific about how this harms deno? It is just "cruft"?
- endisneigh 3y ago
  for one the security model is incompatible with node APIs. as a result even with this post, deno doesn't support all npm packages. however if deno were to support all npm packages, it would necessarily basically have to implement the entire node api, including support for pre async/await (aka callbacks). this is but a single example. deno was able to ignore all of that because compatibility was not an original design decision
  - paulddraper 3y ago
    > for one the security model is incompatible with node APIs No it isn't. > deno was able to ignore all of that So maintaining a Node.js stdlib (or subset thereof) is more work for the Deno team. I agree, but that seems a weak argument for harming a Deno user.
    - endisneigh 3y ago
      > No it isn't. sure it is. how could deno maintain its security model and implement all of the node apis? part of why it works is because there's a standard lib and there's no way to obscure usage and thus circumvent the permissions. unless your answer is that --allow-run is the solution. even with the OP post, they don't even support child_process with deno deploy, which is why, but clearly they can't support everything and still maintain security, which is the point. consider just the c++ embedder apis. how exactly would deno deal with that with respect to permissions?
      - bartlomieju 3y ago
        Bartek from the Deno team here, let me clarify a few things. > for one the security model is incompatible with node APIs. All Node.js APIs are polyfilled using Deno APIs and as such these Node.js API are subject to the same permission model as regular Deno programs. > however if deno were to support all npm packages, it would necessarily basically have to implement the entire node api, including support for pre async/await (aka callbacks) We're not aiming for 100% compatibility, though we managed to polyfill a hefty amount of built-in Node modules, including ones that are callback based. > consider just the c++ embedder apis. how exactly would deno deal with that with respect to permissions? This is the same situation as with Deno's FFI API. You need to pass `--allow-ffi` flag to enable usage of `Deno.dlopen` (or `require("./foo.node")` for N-API extensions). That said when you load dynamic libraries all bets are off - we can't control what the dynamic library can do and you effectively open up your whole system. Still, you can't load such libraries unless `--allow-ffi` flag is passed. Hope this clears up some things.
        endisneigh 3y ago
        > We're not aiming for 100% compatibility, though we managed to polyfill a hefty amount of built-in Node modules, including ones that are callback based. yeah, I'm aware of this. my point was that you couldn't 100% compatibility without compromising. fwiw it's a good thing. node can be a security nightmare if your team is not disciplined about dependencies. w.r.t to node apis, technically you are like you say polyfilling them. and with that implementation differences hopefully allow you to continue to polyfill.
  - tracker1 3y ago
    I think, in general the requests are largely to support specific, and generally popular npm modules. People wrigin software running under Deno aren't generally asking for "all" of node's API, but enough to where at least the most popular modules out of npm actually work. I think we're largely at that point now. Haven't tested it, but one of the modules I had a lot of trouble importing when MS-SQL was a major database I interacted with was `mssql` backed by `tedious`. I'm at least able to `import mssql from 'npm:mssql';" now. I don't have many other good/complex imports that weren't working before or were lacking suitable deno alternatives. Back when trying to use the likes of esm.sh and similar, it used to blow up spectacularly.

paulddraper 3y ago

> deno does not have any inherent advantages over node if they support node Could you be more specific about how this harms deno? It is just "cruft"?

endisneigh 3y ago
for one the security model is incompatible with node APIs. as a result even with this post, deno doesn't support all npm packages. however if deno were to support all npm packages, it would necessarily basically have to implement the entire node api, including support for pre async/await (aka callbacks). this is but a single example. deno was able to ignore all of that because compatibility was not an original design decision
- paulddraper 3y ago
  > for one the security model is incompatible with node APIs No it isn't. > deno was able to ignore all of that So maintaining a Node.js stdlib (or subset thereof) is more work for the Deno team. I agree, but that seems a weak argument for harming a Deno user.
  - endisneigh 3y ago
    > No it isn't. sure it is. how could deno maintain its security model and implement all of the node apis? part of why it works is because there's a standard lib and there's no way to obscure usage and thus circumvent the permissions. unless your answer is that --allow-run is the solution. even with the OP post, they don't even support child_process with deno deploy, which is why, but clearly they can't support everything and still maintain security, which is the point. consider just the c++ embedder apis. how exactly would deno deal with that with respect to permissions?
    - bartlomieju 3y ago
      Bartek from the Deno team here, let me clarify a few things. > for one the security model is incompatible with node APIs. All Node.js APIs are polyfilled using Deno APIs and as such these Node.js API are subject to the same permission model as regular Deno programs. > however if deno were to support all npm packages, it would necessarily basically have to implement the entire node api, including support for pre async/await (aka callbacks) We're not aiming for 100% compatibility, though we managed to polyfill a hefty amount of built-in Node modules, including ones that are callback based. > consider just the c++ embedder apis. how exactly would deno deal with that with respect to permissions? This is the same situation as with Deno's FFI API. You need to pass `--allow-ffi` flag to enable usage of `Deno.dlopen` (or `require("./foo.node")` for N-API extensions). That said when you load dynamic libraries all bets are off - we can't control what the dynamic library can do and you effectively open up your whole system. Still, you can't load such libraries unless `--allow-ffi` flag is passed. Hope this clears up some things.
      - endisneigh 3y ago
        > We're not aiming for 100% compatibility, though we managed to polyfill a hefty amount of built-in Node modules, including ones that are callback based. yeah, I'm aware of this. my point was that you couldn't 100% compatibility without compromising. fwiw it's a good thing. node can be a security nightmare if your team is not disciplined about dependencies. w.r.t to node apis, technically you are like you say polyfilling them. and with that implementation differences hopefully allow you to continue to polyfill.
- tracker1 3y ago
  I think, in general the requests are largely to support specific, and generally popular npm modules. People wrigin software running under Deno aren't generally asking for "all" of node's API, but enough to where at least the most popular modules out of npm actually work. I think we're largely at that point now. Haven't tested it, but one of the modules I had a lot of trouble importing when MS-SQL was a major database I interacted with was `mssql` backed by `tedious`. I'm at least able to `import mssql from 'npm:mssql';" now. I don't have many other good/complex imports that weren't working before or were lacking suitable deno alternatives. Back when trying to use the likes of esm.sh and similar, it used to blow up spectacularly.