Earlier quoted context omitted.
> But yes, Bun's current strategy is "churn out code" whereas Deno has a different pace and approach. They're trying to build different things, and have a lot less catch-up to play than Bun. Are they trying to build different things? I feel like they're direct competitors. Are you a Deno user? Curious what your experience has been
Well e.g. JSR is different to anything I've seen from the Bun team, so yes. I didn't mean Deno and Bun's core offerings are different, but that there are differences in what they're each applying time and effort to. I'm a Node user. I haven't yet seen a compelling reason to switch that justifies potential compatibility/ecosystem issues.
(Deno has not stayed entirely still, other new features were added outside of that compatibility effort, but Bun doesn't have Node compatibility as much as a goal today and so gets the fast mover award.)
I started using Deno in hobby projects because I like the out-of-the-box defaults a lot better than Node (deno.json is a lot simpler than a lot of the cruft that package.json has acquired, but also includes more things in one place like out of the box eslint support [deno lint] and prettier-equivalent [deno fmt]). Also, Deno Deploy has a generous free tier and that's a healthy incentive for hobby projects that want a modest database (Deno KV) and basic task processing queues.