Hi Christian, Fair questions, so taking them one at a time: Compile time and bloat: those should be measured, not assumed. Compile time I'm already working on (see my other mail). Binary size I checked: the hello example in release, stripped, is 1.8 MB with GCC. A hand-written Beast server with the same two routes is 1.1 MB. So taar adds about 0.7 MB on top of Beast, and that includes shutdown and error handling the hand-written one doesn't have. That 0.7 MB is a one-off cost. Each route after that adds about 25 KB (measured up to 52 routes. Memory safety: true for any C++ server, including everything already built on Beast today. Taar doesn't make anyone pick C++. It helps people who already have. HTTP/1.1: that comes from Beast, not from a decision to give something up. Taar builds on what Boost has and doesn't take anything away. In most deployments HTTP/2 and HTTP/3 end at the load balancer or proxy anyway (AWS ALB, GCP's load balancer, Azure Front Door, Envoy, nginx), and the hop to the app is often plain HTTP/1.1. If Boost gets HTTP/2 support, taar can sit on top of it. JWT, OAuth, etc.: those usually live in a different layer. A gateway or auth proxy (API gateway authorizers, Envoy ext_authz, nginx auth_request, oauth2-proxy) validates the token and forwards the request with the identity in a header. The service reads that header, and taar already matches and extracts headers and cookies. I don't think a routing library should implement OAuth. Why not Node, Go, C#...: if you're starting from scratch, maybe. But plenty of teams already have a large C++ codebase and just need an HTTP or REST endpoint in front of it, or even choose to use C++ with new projects. Adding a second language means another runtime, build, deployment and on-call story. That cost is real, and that's the user taar is for. Cheers, Reza