[jackielii]

because Vite is great. It only uses it in dev. In prod, no node involved. Try the gsx init. You'll know why. The dev experience you'll want.

EDIT: highlights are:

- live reload: it only reloads after new binary is built. also has /healthz check integration. I believe this is better than air, wgo etc

- dev panel & error overlay: see generate, build status: on syntax error, you get an error overlay explaining where the error is;

- status for slow builds: if you're working in a big project, you can see the building progress & log in the dev overlay

[SamInTheShell]

I'm kinda in the camp of wanting nothing to do with node if I'm building in Go. We have our own stdlibs for serving.

[pjmlp]

I am on the Java/.NET camp for the most part, however I do share the sentiment.

[throw1234567891]

I’m in the other camp. I switched to node backends from go because of vite.

[indemnity]

Same, hard pass on remote shell as a service that is Node and its ecosystem.

[jackielii]

I'm not sure I follow. Node is not on the production path

[evilduck]

It's easy to follow, it's a knee jerk tribalism reaction and not a logical or informed one. Go attracts backend or anti-frontend people so anything intermingling the two will draw out the commenters who bemoan anything that realistically builds a modern website. Just ignore it, your choice for dev tooling is practical and makes sense to me.

[saurabhmudradi]

Cool! was looking for go based frontend options for local data heavy dashboard usecase, this seems perfect.

[nzoschke]

Thanks for the explanation. I do find air lacking for sufficiently complicated applications servers