> …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. I felt this way too before usi

> …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. 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 https://deno.land/manual/runtime/web_platform_apis ) and the work to standardise those across platforms (https://wintercg.org/ 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/ 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 https://tinyclouds.org/jsconf2018.pdf and https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA )