If you have a lot of duplicated functionality in a web frontend and backend, it may be a lot more maintainable to do the development once and not have to keep two implementations in sync.
As far as performance, if you’re using one of the JS application frameworks with server-side pre-rendering time to interactivity may very well be faster than anything you can build in Go or Rust.
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.
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.
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)
While many people have the impression the Rust type system slows them down while prototyping, I think it is a huge time saver when working on existing code, so I'm not sure why you think Rust isn't as maintainable.
Because there's a large productivity gain from being able to use one language for both the frontend and the backend, and server-side JS tooling is far more mature and usable than client-side Go or Rust.
Because they simply can't convert all of their js code into either go or rust for a forseeable future? Even providing they actually find those languages desirable, comparing to typescript.
Yeah it’s a silly question. It’s like going into a python thread and being like “why didn’t you implement all of this in Go or Rust?” Well, there’s a thousand reasons, and it’s really not even worth the time to unwrap this very reductive question that is really only going to turn into a language flame war for no reason.
If you have a lot of duplicated functionality in a web frontend and backend, it may be a lot more maintainable to do the development once and not have to keep two implementations in sync.
As far as performance, if you’re using one of the JS application frameworks with server-side pre-rendering time to interactivity may very well be faster than anything you can build in Go or Rust.