Deno 2.4

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

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.

100%. I was all-in on Deno, but there were just too many sharp edges. In contrast, Bun just works.

You picked a stack that is still very npm-centric, especially private npm packages. The sweet spot for doing things the Deno way still seems to be choosing stacks that themselves are very Deno and/or ESM-native. I've had some great experiences with Lume, for instance, and targeting things like Deno Deploy over Vercel. (JSR scores are very helpful at finding interesting libraries with great ESM support.) Obviously "start with a fresh stack" is a huge ask and not a great way to sell Deno, given how much time/effort investment exists in stacks like Next.js. But I think in terms of "What does Deno do best?" there's a sweet spot where you 0-60 everything in Deno-native/ESM-native tools.

Also, yeah, a lot of Deno's npm compatibility keeps getting better, as mentioned in these 2.4 release notes there are a few new improvements. As another comment in these threads points out, for a full stack like the one you were trying, using Deno package.json first can give a better compatibility feeling than deno.json first, even if the deno.json first approach is the nicer/cleaner one long term or when you can go 0-60 in Deno-native/ESM-native greenfields.