I know this is probably blasphemy at this point, but I actually wasn't enjoying package management in Deno (or lack thereof). I've been an avid user of the NPM ecosystem for a long time (10+ years), it's entrenched deep in me and I don't mind it haha! In particular with Deno, it was trying to remember all the dependency URLs, and not wanting to duplicate them - every time I wanted to read a file and I had to lookup the std library URL for the umpteenth time. The package discovery isn't as good, and documentation was too different (why is everything in a file called mod.ts? why do I need to see all of the files in a dependency?).
This led to the recommended advice of having a dedicated TS file where you pull all your external dependecies in and then re-export them locally. This felt worse than package.json (read: clunky not having a first-class system to list external dependencies). And this is in a project with minimal dependencies too - yet it still frustrated me. Plus my editor had no type info for any external imports. I then discovered import maps, but that was still hit and miss in my editor (Neovim mind you) with code completion, made worse by not having a clear way to import ohm-js. Not to mention having to explicitly list `--import-map` for every command and forgetting too often and then wondering why my code wasn't working. Just feels like it's on a roundabout path to reinventing package.json anyway, just with distributed packaging by default?
I'm not particularly concerned with security either, so having to list `--allow-x` and `--allow-y` got tiring very quick. At this point, I just felt like Deno was constantly trying to stop me from getting stuff done. I ended basically ditch most of the new stuff in Deno and was basically treating it a ts-node (thanks to the new NPM/Node compat feature) - but it had me off side now.
I knew Bun.sh has some rough edges in terms of compatibility, etc (which is fine as it's pre-v1)... but for writing a compiler: I'm mostly writing everything from scratch and just need to read/write from the filesystem which is definitely stable and well documented. Switching to Bun was painless and all of a sudden everything Just Worked™, ran faster and I can get back to actually working on my compiler. The only problem I've had with Bun is not being able to tweak the output the results of `bun test` (e.g. if one of the first tests fail, I have to keep scrolling back up through my big list of passing tests to see why it failed) - if Bun had a better error summary at the end of the test output I'd be set!
TLDR; As someone using NPM/node for over a decade, nothing in Deno "just worked" for me and instead blocked me at every turn and the lack of package management turned me off. I know there are sound and objective reasons for design decisions in Deno, but none of those things matter much _to me_. Bun, on the other hand, is intended as a drop-in replacement for Node, but faster and with native support for TypeScript which ticks all the boxes I need for this particular project. (FWIW I tried switching a Remix project to Bun and it didn't work and stuck with Node).
Interesting, I'll really have to dig deeper into Bun. I know I've been having a hard time switching to anything else because I rely heavily on a typescript compiler transformer and that hasn't wanted to transfer to well to other things (like from Webpack to esbuild for example).
This led to the recommended advice of having a dedicated TS file where you pull all your external dependecies in and then re-export them locally. This felt worse than package.json (read: clunky not having a first-class system to list external dependencies). And this is in a project with minimal dependencies too - yet it still frustrated me. Plus my editor had no type info for any external imports. I then discovered import maps, but that was still hit and miss in my editor (Neovim mind you) with code completion, made worse by not having a clear way to import ohm-js. Not to mention having to explicitly list `--import-map` for every command and forgetting too often and then wondering why my code wasn't working. Just feels like it's on a roundabout path to reinventing package.json anyway, just with distributed packaging by default?
I'm not particularly concerned with security either, so having to list `--allow-x` and `--allow-y` got tiring very quick. At this point, I just felt like Deno was constantly trying to stop me from getting stuff done. I ended basically ditch most of the new stuff in Deno and was basically treating it a ts-node (thanks to the new NPM/Node compat feature) - but it had me off side now.
I knew Bun.sh has some rough edges in terms of compatibility, etc (which is fine as it's pre-v1)... but for writing a compiler: I'm mostly writing everything from scratch and just need to read/write from the filesystem which is definitely stable and well documented. Switching to Bun was painless and all of a sudden everything Just Worked™, ran faster and I can get back to actually working on my compiler. The only problem I've had with Bun is not being able to tweak the output the results of `bun test` (e.g. if one of the first tests fail, I have to keep scrolling back up through my big list of passing tests to see why it failed) - if Bun had a better error summary at the end of the test output I'd be set!
TLDR; As someone using NPM/node for over a decade, nothing in Deno "just worked" for me and instead blocked me at every turn and the lack of package management turned me off. I know there are sound and objective reasons for design decisions in Deno, but none of those things matter much _to me_. Bun, on the other hand, is intended as a drop-in replacement for Node, but faster and with native support for TypeScript which ticks all the boxes I need for this particular project. (FWIW I tried switching a Remix project to Bun and it didn't work and stuck with Node).