Yeah, gql in particular is a problem looking for a solution in most cases. It makes sense for facebook because they have people building frontend apps for their marketplace, and those apps need all kinds of weird combinations of data. However, this isn't the situation for most apps where you have a fairly well defined set of calls you're doing.

Most pages tend be just documents and fairly simple forms. Making SPAs and then having to worry about SSR is just making a Rube Goldberg machine in most cases. I think something like HTMX is a much better approach in most cases. You keep all your business logic server side, send regular HTML to the client, and you just have a little bit of Js on the frontend that knows how to patch in chunks of HTML in the DOM as needed. Unless you have a highly interactive frontend, this is a much better approach than making a frontend with something like React and adding all the complexity that goes with it.

No one cares about graceful degradation anymore. But you can sell management on SEO. Page performance is a key aspect of search engine rankings and server-side rendered pages will almost always have a much faster initial load than client-side rendered.

No I meant having to do async as opposed to having threads like you would in Java for example. In vast majority of cases a thread pool will work just fine, and it makes your code far simpler. Typically, Java web servers will have a single thread that receives the request and then dispatches it to the pool of workers. The JVM is then responsible for doing the scheduling between the threads and ensuring each one gets to do work. You can do async too, but I've found threads scale to huge loads in practice.