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

81–90 of 112 posts

Re: Node.js built-ins on Deno Deploy

#81

Post by forty »

paulddraper wrote: post #79
forty wrote: post #72

Earlier quoted context omitted.

Something along the lines of > docker run -it --rm -v "$PWD":/app -w /app node:18 node main.js It's a tad longer but it's more flexible too ;)

Of course, now you have to boot and run an entire VM on your MacBook, just to run that one Node.js program.

Ah yes, I always forgot some people don't use Linux as their OS to develop. That always seems weird to me because then they have to launch VMs each time they want to simulate their target OS :D

But I do see your point :)

Re: Node.js built-ins on Deno Deploy

#82

Post by tracker1 »

paulddraper wrote: post #79
forty wrote: post #72

Earlier quoted context omitted.

Something along the lines of > docker run -it --rm -v "$PWD":/app -w /app node:18 node main.js It's a tad longer but it's more flexible too ;)

Of course, now you have to boot and run an entire VM on your MacBook, just to run that one Node.js program.

If you're using Docker Desktop, and have it run at startup, that VM is already running when you launch your docker command. It's not like you have to start a new/fresh VM every time you do docker run.

Re: Node.js built-ins on Deno Deploy

#83

Post by tracker1 »

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…

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.

Re: Node.js built-ins on Deno Deploy

#84

Post by tracker1 »

sisve wrote: post #80

Am I the only one reading this right or am I the only one reading it wrong. Deno is not supporting node.js built-ins. It's deno deploy. Meaning that this will not work on other hosting platforms, right... or?

Deno has already been seeing increasing support for Node's API and built-ins... this means, they are now also available for running in Deno Deploy (cloud environment)... if you were using something where you deployed your own Deno (docker, etc) then you could already to this.

Note: Cloudflare Workers is also starting to support a lot of Node APIs as well (opt-in), so bundles will likely be able to run in both of them and others. Can't speak specifically to it, but Bun will probably also largely work.

Re: Node.js built-ins on Deno Deploy

#85

Post by eropple »

strangescript wrote: post #69
spixy wrote: post #67

Earlier quoted context omitted.

I have inherited Deno web app in my job and I cannot wait to migrate it to Node

Genuinely curious the motivation here

I'm not the OP, but I've built a little bit of software [0][1] in Deno. I don't know if I'd do it again. Thoughts, in no particular order:

- Big plus: the built-in stdlib is strong (coming from Node; it's not as strong as Python or even Ruby, but I'll take what I can get). The stdlib is also pretty "good Unix citizen" focused--it's very easy to build an ergonomic command-line application.

- Theoretical plus: the capabilities-based security model is smart and cool.

- In-reality minus: you end up passing most `--allow` flags anyway for anything that isn't trivial. It could scope down to specific modules if you are a tryhard, but I am not sufficiently a tryhard, and this really should just be within the capability of Deno to figure out and recommend for you.

- Moderate plus: `deno compile` being built in is nice, and it is easier than the Node `pkg` library from Vercel.

- Small minus: The set of targets for `deno compile` is limited, though, and (for reasons that are both reasonable and unfortunate) it spits out truckasaurus-sized executables, which is a bummer.

- Enormous, world-stopping minus: dependency management. It's bad, and it's not easy to get around. "Just put all your deps in a TypeScript file and export it" is not the amazing solution that its adherents want you to think it is. The developer experience of upgrades is annoying and unpleasant and `deno-upgrade` helps but makes your project feel out-of-control. (Import maps don't really help, it's just another road into the same unpleasantness and since they don't work if you're writing a library I don't think you should ever use them at all; just stay consistent between applications or libraries.)

- Whiny minus: VScode support is pretty bad. It exists, but it's not great, and there's a weird lag to dependency management that I never figured out.

- Real minus: the Deno VScode stuff freaks out when you use a Node project, even if you set `deno.enabled: false` in your .vscode/settings.json file.

There are definite, real benefits to some of what Deno does. But I just don't see why I'd continue to use it over Just Continuing To Use Node.

[0] - https://github.com/eropple/tmuxed

[1] - https://github.com/render-oss/render-cli

Re: Node.js built-ins on Deno Deploy

#86

Post by eropple »

jrsj wrote: post #29
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…

Deno Deploy is the killer feature for me, and it’s ultimately the main product of Deno, Inc. too. Node support just makes it easier to get existing software running there. I don’t think it will suffer the same fate as Kotlin because a lot of the value add is in Deploy, Deno KV, etc.

Have you used Cloudflare Workers? How does Deno Deploy stack up, if so?

Re: Node.js built-ins on Deno Deploy

#87

Post by tracker1 »

mark_and_sweep wrote: post #77
vorticalbox wrote: post #75

Earlier quoted context omitted.

I don't think the speed matters persa, what annoys me is when starting a node project I have to install typescript, jest, eslint (any plugins) then whatever dependences I am using and then set up a tsconfig and what every else also needs a config file. In deno you can just open your ide, add some imports to the import map and you're ready to code.

Note that import maps are optional. I mostly just open my editor for a Deno project and I'm good to go. :)

This is it for me too... with Deno, I can write a fully contained one-off script with a shebang and use it for general shell scripting.. with node, it was never that simple. Though having to use the `#!/usr/bin/env -S -- deno run ...` is still a little more awkward.

Direct imports that the runtime caches for you, vs node_modules is way easier to deal with most of the time.

Re: Node.js built-ins on Deno Deploy

#88

Post by tracker1 »

bartlomieju wrote: post #41
robust-cactus wrote: post #28

Earlier quoted context omitted.

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

Until you try to build a TS project that imports an .mjs from node_modules that doesn't work right. Oh, set the project to type=module, nope, then other crap breaks. I mean, you can get it all working, but simple and easy are two words I would not use for modern node, especially when working with typescript.

Re: Node.js built-ins on Deno Deploy

#89

Post by sisve »

tracker1 wrote: post #84
sisve wrote: post #80

Am I the only one reading this right or am I the only one reading it wrong. Deno is not supporting node.js built-ins. It's deno deploy. Meaning that this will not work on other hosting platforms, right... or?

Deno has already been seeing increasing support for Node's API and built-ins... this means, they are now also available for running in Deno Deploy (cloud environment)... if you were using something where you deployed your own Deno (docker, etc) then you could already to this. Note: Cloudflare Workers is also starting to support a lot of Node APIs as well (opt-in), so bundles will likely be able to run in both of them…

Thanks. That explains it. See that it was added to deno in jan. I guess the last version on deno made it ready to be used on deno deploy.

Re: Node.js built-ins on Deno Deploy

#90

Post by pjmlp »

forty wrote: post #81
paulddraper wrote: post #79

Earlier quoted context omitted.

Of course, now you have to boot and run an entire VM on your MacBook, just to run that one Node.js program.

Ah yes, I always forgot some people don't use Linux as their OS to develop. That always seems weird to me because then they have to launch VMs each time they want to simulate their target OS :D But I do see your point :)

Being a developer!== Linux.
Post reply on HN