I think part of why tRPC shines is because it's tightly coupled to TypeScript (and especially Zod, its schema validation library of choice - many of its features map 1:1 onto TypeScript concepts that don't exist in many other languages), which means it can avoid many of the issues that OpenAPI generators have. I'd also like to see a good TS-first OpenAPI client - Fern [0] is probably the closest I've seen.
In general in my experience, when you take away the constraint of inter-language interop, you get much smoother DX because you can take advantage of language features. A good example would be the lack of native date/time types in JSON - valuable for interop because different languages handle dates differently, but painful when you're going to/from the same language. Web applications are a special case, because the client-side is effectively constrained to either JavaScript or WebAssembly (except you'd still need at least some JS in the latter case), so it follows that you'll get the best DX if you have JS or TS on both sides of the stack, especially if you can set up your project in a way that lets you share code between both. Not always an option, but I've always felt more productive (as a full-stack dev) when I've been using TS on both the client and server, compared to TS on the client and another language on the backend.
:wave: Hey Mark -- I'm one of the primary contributors to Fern.
+1 to your comment about how needing to support multiple languages results in not being able to leverage certain language specific features. We've tried the best to manage the trade-offs here, but there's a limit to what you can do.
If you have feedback on how we can improve the TypeScript client, feel free to comment here or create an issue on our repo (https://github.com/fern-api/fern)!
In general in my experience, when you take away the constraint of inter-language interop, you get much smoother DX because you can take advantage of language features. A good example would be the lack of native date/time types in JSON - valuable for interop because different languages handle dates differently, but painful when you're going to/from the same language. Web applications are a special case, because the client-side is effectively constrained to either JavaScript or WebAssembly (except you'd still need at least some JS in the latter case), so it follows that you'll get the best DX if you have JS or TS on both sides of the stack, especially if you can set up your project in a way that lets you share code between both. Not always an option, but I've always felt more productive (as a full-stack dev) when I've been using TS on both the client and server, compared to TS on the client and another language on the backend.
[0]: http://buildwithfern.com/