Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js built-ins on Deno Deploy

deno.com

Post reply on HN
Print view View original

31–40 of 112 posts

Re: Node.js built-ins on Deno Deploy

#31

Post by lucacasonato »

lolinder wrote: post #14
endisneigh wrote: post #11

Earlier quoted context omitted.

I am not saying deno does not have benefits. I am saying you can get many of those things with node already. I see deno more and more as an opinionated set of things + node. This is not a bad thing. but if you already have a huge legacy node project why would you switch to deno? or are we all going to pretend to forget why Deno was even created?

Yep. I saw Deno as intended to be a platform for new projects that want to start fresh without all the legacy cruft from Node. Somewhere along the way they decided it was a priority to be able to transition legacy Node projects to Deno, and I'm afraid that what's going to happen is it will freeze the ecosystem's development of independent solutions in favor of just using Node libraries for everything.

I don't think this will happen. People _love_ cutting edge innovation. Cutting edge innovation happens on cutting edge platforms, not in the legacy.

Re: Node.js built-ins on Deno Deploy

#32

Post by endisneigh »

paulddraper wrote: post #30
endisneigh wrote: post #23

Earlier quoted context omitted.

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 adva…

> 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

Re: Node.js built-ins on Deno Deploy

#33

Post by endisneigh »

lucacasonato wrote: post #31
lolinder wrote: post #14

Earlier quoted context omitted.

Yep. I saw Deno as intended to be a platform for new projects that want to start fresh without all the legacy cruft from Node. Somewhere along the way they decided it was a priority to be able to transition legacy Node projects to Deno, and I'm afraid that what's going to happen is it will freeze the ecosystem's development of independent solutions in favor of just using Node libraries for everything.

I don't think this will happen. People _love_ cutting edge innovation. Cutting edge innovation happens on cutting edge platforms, not in the legacy.

I disagree. people love a robust ecosystem, not innovation for innovation's sake.

Re: Node.js built-ins on Deno Deploy

#34

Post by paulddraper »

endisneigh wrote: post #12
shrubble wrote: post #5

I do wonder about the long-term effects of Deno being Node-compatible; will it result in only Node programming being done since "Deno will handle it fine" and thus Deno specific stuff will not be developed?

Sad such a reasonable question is downvoted, lol. I agree with the sentiment. It's expected any development would want to have the highest reach, which means Node. If Deno supports node features, and node does not support deno clearly the logical conclusion is that features will be node-first, with deno expected to support it anyway. Thus leading to the question of why even bother with Deno? Deno does have some benef…

> Thus leading to the question of why even bother with Deno?

1. Native support for TypeScript.

2. Better built-in APIs.

3. Security model.

4. Easy package management.

Node.js is closing the gap. E.g. top-level await, fetch() API, Permissions.

I believe Node.js will follow Deno and implement more and more features. Sort of a npm/yarn situation.

It's cool to see what Deno does, but I don't think you will be left out by sticking with Node.js.

Re: Node.js built-ins on Deno Deploy

#35

Post by paulddraper »

forty wrote: post #26
endisneigh wrote: post #12

Earlier quoted context omitted.

Sad such a reasonable question is downvoted, lol. I agree with the sentiment. It's expected any development would want to have the highest reach, which means Node. If Deno supports node features, and node does not support deno clearly the logical conclusion is that features will be node-first, with deno expected to support it anyway. Thus leading to the question of why even bother with Deno? Deno does have some benef…

Nodejs is the de facto platform and ecosystem to write JS backend, and it seemed to me a bit weird that one would want to compete with it without being compatible with it which meant throwing away the very large ecosystem and existing code bases with no good reasons if you wanted to migrate. So congrats to them to have made it now, Deno can still compete on speed or tooling for example. Good Deno ideas will indeed pr…

> can someone explain why it's a good idea to have isolation at the interpreter level rather than relying on OS features? (or VMs).

Those technologies are platform-specific and difficult to use.

For example, provide the command line for running a Node.js program in Linux without file system access.

In deno, it's

    deno run main.ts
Or, to enable fs access:

    deno run --allow-read --allow-write main.ts
---

That said, I agree that I'd rather rely on containers, VMs, etc.

Re: Node.js built-ins on Deno Deploy

#36

Post by paulddraper »

endisneigh wrote: post #32
paulddraper wrote: post #30

Earlier quoted context omitted.

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

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

Re: Node.js built-ins on Deno Deploy

#37

Post by endisneigh »

paulddraper wrote: post #36
endisneigh wrote: post #32

Earlier quoted context omitted.

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…

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

Re: Node.js built-ins on Deno Deploy

#38

Post by o1y32 »

derefr wrote: post #25
shrubble wrote: post #5

I do wonder about the long-term effects of Deno being Node-compatible; will it result in only Node programming being done since "Deno will handle it fine" and thus Deno specific stuff will not be developed?

I think you can analogize these server JS runtimes (Node, Deno) to browser runtimes (V8, JavaScriptCore, SpiderMonkey) and to the APIs that ship with those. When one browser JS engine invents and exposes a novel feature + API surface for it that the other engines don't, what happens? If there's any demand at all for doing what the feature does, then devs will tend to write polyfills to make the feature "work" (for so…

Just want to point out one issue in your comment -- webkit, blink would be more suitable as examples for "browser runtimes". V8 and JavaScriptCore are JavaScript engines. In other words, the page here is more about platform APIs (or maybe "standard library") rather than JavaScript language features. V8 vs JavaScriptCore vs SpiderMonkey doesn't matter to most developers because they are mostly up-to-date with ECMAScript specs and the behavior is mostly consistently, while different browser engines have varying support for features.

Re: Node.js built-ins on Deno Deploy

#39

Post by bartlomieju »

endisneigh wrote: post #37
paulddraper wrote: post #36

Earlier quoted context omitted.

> 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 everyt…

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.

Re: Node.js built-ins on Deno Deploy

#40

Post by endisneigh »

bartlomieju wrote: post #39
endisneigh wrote: post #37

Earlier quoted context omitted.

> 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 everyt…

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…

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

Post reply on HN