[LorenzoGood]

There is no way that a js ssr framework is faster than a go ssr template renderer.

[lolinder]

If you're building in plain Go with pure SSR, sure, but OP is talking about building a React frontend that is pre-rendered server-side. TTI very well could be faster with that than with a React front end that talks to a Go backend.

[konart]

I'm kind of lost here. It's been ages since I wrote anything frontend related so here the question: how does it matter?

I mean unless you have pure front end app - you are still going to talk to some backend. Regardless of how you got your frontend part - generated by the server or a static file served by nginx.

[spion]

Modern JS frameworks pre-render the components on the server then they attach to them to "rehydrate" and add JS handlers on the client. They also allow mixing of purely-server-side components (essentially templates, no JS or hydration) and mostly-client-side components (that still pre-render on the server)

For Rust, Leptos (https://leptos.dev/) would be one choice that can do SSR+hydration (but not intermixed with server-side components, at least AFAIK not yet)

[tuetuopay]

There very well could be, the same way that java can be faster than c.

Why? Because js and java are JIT compiled for the very specific cpu they run on, and HotSpot is basically PGO but running all the time.

Granted, this is if and only if the js or java is carefully and properly written, which never happens...