> Bun’s APIs try really hard to make the obvious & default way > also the fast way. Nice! That makes a lot of sense, and look forward to trying them. Fwiw I s

> Bun’s APIs try really hard to make the obvious & default way > also the fast way. Nice! That makes a lot of sense, and look forward to trying them. Fwiw I sometimes worry about the slippery slope to infra that exists on the JS side, i.e. I work a lot in a GraphQL backend, and even if Bun gave us (or really our framework, so fastify/mercurius) a super-optimized way of getting the raw bytes off the wire, Mercurius is still doing GraphQL parsing, validation, routing, response building in JS land. Granted, I want to keep my application's business logic in TS, but naively it seems tempting to push as much of the "web framework" / "graphql framework" as possible into the native side of things, where as I think historically Node/etc API have stopped at the "here's the raw HTTP request off the wire". > I’ve thought a little about this. Sweet! That's awesome just to hear that it's crossed your mind. Agreed it would be a moonshot. And, yeah, I'm perfectly happy leaning into JITs and good APIs. Thanks for the reply!