Ideally you would put as much of the "business logic" in the go code as possible, and have it "render" to something like JSON which the front end just reads in

Ideally you would put as much of the "business logic" in the go code as possible, and have it "render" to something like JSON which the front end just reads in and displays. Interactions with the front-end just send a new request to the go code to handle and respond with what is needed. It is a lot more work for small applications compared to something like wxWidgets, but for larger applications the decoupling of the front end from the "back end" can help in a bunch of ways. It lets you develop them somewhat separately, it gives you a uniform look-and-feel across platforms (could be a pro or a con depending on how you feel about it), and allows you to do something like replace the web-front-end with a native system later if you want (and you could write the front-end in the platform's native GUI widget library for best performance and integration while keeping the backend code identical). So your go code is basically an HTTP server at that point, but it frees you up to let go do what it does best without worrying about how you will display it, and it lets javascript/html/css do what it does best (display stuff). I've had great success doing this once before, and if you have some experience with React, it works out really "beautifully" as the front-end can be completely stateless. So what was pushed to it from go is what is displayed. Easy to test, easy to develop, and easy to replace if needed.