Hacker News Reader

Comment by lucasyvas | Hacker News Reader

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.

View on HN

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.

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)).

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.

> 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"?

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

> 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.

> 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?

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.

> 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.

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.

Reply on news.ycombinator.com