3 ms·

There are many people that feel having Node support harms Deno's goals, but I don't agree. To me, this is like complaining that you can mix JS into TypeScript

There are many people that feel having Node support harms Deno's goals, but I don't agree. To me, this is like complaining that you can mix JS into TypeScript projects. The only reason the latter is successful is because you can migrate from the former in a first-class way. I don't think Deno has the community support to make it on its own steam - that said, I think it's a huge value add in terms of DX. I support them on this 100%. Node is trying to add in some capabilities of Deno. We'll see which one comes out ahead.

endisneigh 3y ago
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.
        3y ago
ravenstine 3y ago
I wouldn't say it necessarily harms Demo's goals, but I think it sort of "harms" the JS community by keeping Node cruft around as a crutch. It's one thing to support Node features when there's no other choice for a package, but then keeping around these Node APIs just encourages developers to keep using them no matter what runtime you are using. By the time that nearly packages support Demo in one way or another, I expect most new packages to still predominantly be written in Node style. Just my opinion, but I'd rather that not be the case.

endisneigh 3y ago

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.
        3y ago

ravenstine 3y ago

I wouldn't say it necessarily harms Demo's goals, but I think it sort of "harms" the JS community by keeping Node cruft around as a crutch. It's one thing to support Node features when there's no other choice for a package, but then keeping around these Node APIs just encourages developers to keep using them no matter what runtime you are using. By the time that nearly packages support Demo in one way or another, I expect most new packages to still predominantly be written in Node style. Just my opinion, but I'd rather that not be the case.