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

41–50 of 112 posts

Re: Node.js built-ins on Deno Deploy

#41

Post by bartlomieju »

robust-cactus wrote: post #28
qbasic_forever wrote: post #24

Earlier quoted context omitted.

Uhh do you not realize deno has an entirely different import system where you import by direct resource URL, or one level of indirection through an import map (just like the web)? There's no complex node_modules resolution, no .mjs extension nonsense, no package.json bits to flip. Imports are radically simpler in deno.

That's my point. They fixed and defined the ecosystem which is great. I feel like everyone is forgetting what a mess Node is right now.

Just to clarify - we do have support for node_modules/ resolution (with all of its quirks and gotchas), otherwise we wouldn't be able to load npm packages. However we made a hard stance that CommonJS is only supported in npm dependencies and cannot be used in user code (ie. you must use ESM in your application code).

Re: Node.js built-ins on Deno Deploy

#43

Post by dkarl »

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…

Having a feature is not the same thing as having API compatibility with Node's implementation of the feature. I think people are worried that an exciting project that aimed to have a different approach and a different set of trade-offs from Node will end up having to support everything that Node does, possibly inheriting its trade-offs and losing the freedom to innovate that they started with.

Even if there's no technical trade-off, it does seem that most of their engineering efforts will be focused on backwards compatibility with Node, instead of the new vision that they were promising.

Re: Node.js built-ins on Deno Deploy

#44

Post by mati365 »

paulddraper wrote: post #35
forty wrote: post #26

Earlier quoted context omitted.

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

Reinvent of unevil / pledge

Re: Node.js built-ins on Deno Deploy

#45

Post by troupo »

paulddraper wrote: post #34
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…

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

> Easy package management.

If anything, deno's package management is definitely not easy.

And no, "just throw your deps into deps.ts and re-export each manually" isn't easy either.

Re: Node.js built-ins on Deno Deploy

#47

Post by golergka »

lolinder wrote: post #21

Deno is moving into a similar space as Kotlin started at by adding all this interop—they're trying to be the "better Node". Meanwhile Kotlin is frantically trying to differentiate itself because Java is closing the gap, but it's hard for them to do because they've spent so long piggybacking on the Java ecosystem. Deno is very vulnerable to the same fate. Yes, it's easier to get adoption if you can plug into an ecosys…

This may be bad for Deno if Node will close the gap and okay if it doesn't, but both cases are good for users.

Re: Node.js built-ins on Deno Deploy

#48

Post by CuriouslyC »

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 this works for the same reason Typescript works. You can adopt with no changes, then slowly take advantage of advanced features.

Re: Node.js built-ins on Deno Deploy

#49

Post by TechBro8615 »

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?

Nah, Deno is just another runtime. Now we have the browser runtimes and multiple server runtimes. Not to mention we also have server runtimes like Cloudflare Workers that are "almost" Node in the sense that they run on V8, but without access to filesystem APIs.

People will make sure to distribute their library so that it works on all of them. They might even use `deno compile` to bundle the library into a single file that can be consumed from any of the runtimes.

Post reply on HN