Avoid the Shadow UI
Ok so you've got a new web project that will at some point want interactivity that requires enough JavaScript to make someone tear their hair out. If you ever decide to have an API that your UI consumes, you already fall into this category.
How do the thing these days?
You should avoid, at all costs, the situation in which you have two UIs for the same application.
I don't mean an electron app and a web app and an admin app, etc. What I mean is two applications that do similar things that are overlaid on each other.
This often happens when you use a non-javascript language to render your UI on the server, and JS to render your UI in the browser. What this results in is the server rendering a Shadow UI that is taken over by the JavaScript UI. Hence: two UIs that often need to accomplish the same tasks.
Having a Shadow UI means that you are duplicating work all the time in two different ways. This means your UI people need to constantly decide where functionality goes and have to cover two language implementations for many behaviors. It means they can't use best-in-class tooling because best-in-class tooling (rightfully) doesn't consider golang (or X language) to be an implementation target. It targets JavaScript, whether at runtime (emotion) or build time (postcss).
It also means you don't have much of a choice between client-side, server-side, or prebuilding your UI. Everything has to fit into a two-language pipeline.
Imagine you had two APIs serving from the same database. One serves responses to bootstrap a user request, and then the client transfers over to the other to continue interacting with