←back to thread

Deno 2.4

(deno.com)
133 points hackandthink | 1 comments | 07 Jul 25 08:44 UTC | HN request time: 0.212s | source
Show context
outlore ◴[07 Jul 25 15:17 UTC] No.44491279[source]▶
Really love the ideas behind Deno, and tried to do things the Deno way (Deno.json, JSR, modern imports, Deno Deploy) for a monorepo project with Next.js, Hono and private packages. Some things like Hono worked super well, but Next.js did not. Other things like types would sometimes break in subtle ways. The choice of deployment destination e.g. Vercel for Next also gave me issues.

Here is an example of a small microcut I faced (which might be fixed now) https://github.com/honojs/hono/issues/1216

In contrast, Bun had less cognitive overhead and just "worked" even though it didn't feel as clean as Deno. Some things aren't perfect with Bun either like the lack of a Bun runtime on Vercel

replies(3): >>44491381 #>>44491695 #>>44492669 #
1. Ciantic ◴[07 Jul 25 15:28 UTC] No.44491381[source]▶
It works surprisingly well when used in npm compatiblity mode, a lot like Bun is used.

Running `deno install` in a directory with package.json will create a leaner version of node_modules, running `deno task something` will run scripts defined in `package.json`.

Deno way of doing things is a bit problematic, as I too find it is often a timesink where things don't work, then if you have to escape back to node/npm it becomes a bigger hassle. Using Deno with package.json is easier.