I felt this way too before using Deno for a while. So far I enjoy:
- Breaking from npm/node modules support on purpose turns out to be a real plus for me. It's refreshing to have dependencies referenced by URL, and it's good to have them cached centrally by default (in $HOME/Library/Caches/deno on macOS and $XDG_CACHE_HOME/deno or $HOME/.cache/deno on Linux, for example).
- Use of web platform APIs (https://deno.land/manual/runtime/web_platform_apis ) and the work to standardise those across platforms (https://wintercg.org/ ) is encouraging.
- `deno lint` and `deno fmt` make adopting and using JS/TS feel more like Rust/Go/other languages with good built-in ceremony-free tooling.
- Fresh is turning into a very nice Next.js/Astro alternative (https://fresh.deno.dev/ ) that I found very easy to learn and deploy, with great performance and developer experience out of the box.
Bun is interesting, but I wish it didn't embrace node modules: perpetuating its use instead of attempting to move the community on by recognising it for the mistake it was feels sad to me. (See Ryan Dahl's “Design Mistakes in Node” PDF or talk for more: https://tinyclouds.org/jsconf2018.pdf and https://www.youtube.com/watch?v=M3BM9TB-8yA )
But on the other hand, when I look at Bun I think it has heaps more going for it than Deno. The fundamental value prop of offering better performance (both runtime and developer experience) is huge, and something that would get me to want to use it. Contrarily, while I see a number of improvements in Deno, the vast majority of them seem to be "niceties" that solve some initial "setup" issues that can be painful in Node - but since I already have taken care of a lot of those Node issues in my own projects, there is not a ton that I see compelling in Deno.
Point being, if I were a betting man, I'd easily put all my chips on Bun vs. Deno. It's a "plan where the puck is headed" vs. a "plan where the puck is now" approach, and from that perspective I see a lot more value in Bun.