Sure, they'll now walk back on this after the public outcry (& THANKFULLY the loss of data was agonizing but reversible), but I'll be looking up @use_bruno /
@httpie / some other non-dev-hostile option

Anytime an OSS project gets acquired/raise $$$ I worry

github.com/Kong/insomni...

All in all, bun is EXTREMELY interesting, and my first experience with it was very positive. And not even gotten into CJS/ESM interop usecases. Honestly, more bullish on Bun, than on deno which takes a different approach.

Definitely play with it this weekend! ✌️🤗

Things I'm unsure of:
- bun is EVERYTHING. Node replacement? npm replacement? Toolchain? Testrunner? sdk? Yes. Hope it doesn't spread too thin
- Another lockfile! bun.lockb is interesting format, but _feels_ redundant 🫥

Things that didn't work:
- Metrics scripts didn't work with `PerformanceObserver is not yet implemented in Bun.`
- Had to disable Pyroscope script with error: "Cannot find module "[]/pprof/build/node-v108-darwin-arm64-unknown/pprof.node" from "[]/pprof/out/src/heap-profiler-bindings.js"

Things that worked OOTB:
- bun install vs npm install is not even a race - bun install is 🔥🔥🔥
- Truly drop-in replacement* (see below) - Literally had 8 lines of code changed to run Bun
- Everything feels more "zippy" than regular nodejs/npm - Not sure of tradeoffs

For folks who think vi(m) is hard, I strongly suggest reading this: https://stackoverflow.com/questions/72498282/your-problem-with-vim-is-that-you-dont-grok-vi

Even though IDEs like IntelliJ/VSC are excellent, I still find myself on vim for most of my slicing/dicing/searching of data!