[efecan0]

Hi.

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

    std::string msg = payload["message"];  // type inferred

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!

[const_cast]

On the topic of modules: a single-header template implementation is still the most practical and quick way to distribute a library. Module support is currently iffy - I wouldn't use them.

[sph87]

I love modules. Honestly. I advocate usage simply as a forcing function for upstream. Tooling support is iffy because usage is low. Usage is low because tooling is iffy. All of the major players in the build space have reasonably mature levels of support though. So it's one of those things were compilers have outpaced IDE.

[efecan0]

Thanks for the great follow-up discussion, everyone. This really highlights the classic "pragmatism vs. vision" debate in the C++ ecosystem.

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.

[jpc0]

> Tooling support is iffy because usage is low. Usage is low because tooling is iffy.

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.