You've all made it very clear that from a user's perspective, a single-header library is still the gold standard for ease of use and integration. The ideal scenario is for a developer to just #include "binaryrpc.hpp" and have everything work without touching their build system, and I now see that as a crucial goal for the project. My framework isn't there yet, and the feedback has been a wake-up call that the current multi-header approach creates too much friction for new users.
So, my path forward is clear: 1. First, focus on simplifying the core API based on the initial feedback (e.g., creating wrapper objects for payloads). 2. Then, work towards providing a single-header distribution for maximum compatibility and ease of use.
I agree that modules are the future. But for now, delivering the most practical and frictionless developer experience seems to be the most important priority.
Thanks again for guiding me on this.
There’s effectively one developer working on module support in clangd. I have submitted more than one issue with minimal reproducible examples of hard clangd crashes and every one is still open or Ive given up on following them.
I’m all for modules myself and when you aren’t hitting the edge cases hey are absolutely amazing.
Thank you for the detailed feedback—this is exactly the kind of input that helps the project grow.
You’re right: developer experience needs to be better. Right now there is too much boiler-plate and not enough abstraction. Your example
is the direction I want to take. I’ll add a thin wrapper so users can write `payload["key"].as_string()` or even rely on assignment type-inference. Refactoring the basic chat demo to be much shorter is now my next task.About C++20 modules: I agree they are the future. The single-header client was a quick MVP, but module support is on the roadmap as compiler tooling matures.
If you have more DX ideas or want to discuss API design, please open an issue on GitHub I’d be happy to collaborate.
Thanks again for the valuable feedback!