alt.hn

7/24/2026 at 5:59:08 PM

Gsxui – Shadcn-style components for Go

 https://ui.gsxhq.dev/

by jackielii

7/24/2026 at 8:45:14 PM

GSX seems interesting but I don’t understand why it depends on the node ecosystem. I just want to use Go for everything.

by sosodev

7/24/2026 at 10:17:32 PM

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

by jackielii

7/25/2026 at 4:48:47 AM

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.

by SamInTheShell

7/25/2026 at 11:59:11 AM

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

by pjmlp

7/25/2026 at 11:42:28 AM

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

by throw1234567891

7/25/2026 at 4:51:11 AM

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

by indemnity

7/25/2026 at 10:10:07 AM

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

by jackielii

7/25/2026 at 2:45:20 PM

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.

by evilduck

7/25/2026 at 7:07:20 AM

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

by saurabhmudradi

7/26/2026 at 2:09:46 AM

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

by nzoschke

7/24/2026 at 9:00:17 PM

How does this compare to templ and templui? I see from the docs that gsx is templ compatible.

And why does this depend on node / npx? Something to do with the JSX syntax and parsing?

I wish go std templates were more ergonomic for components.

Past that I wish projects like templ or GSX have a simple go generate pipeline, and support html and text/markdown output including whitespace.

Until then I have a Frankenstein of a bunch of templating.

by nzoschke

7/24/2026 at 10:18:24 PM

It doesn't depend on node for runtime. Only for dev: the vite dev server, and js bundling, nothing else.

Also I've been a long time templ & html/template user, also used templui. gsx is born out of my ergonomics desire from templ. gsxui is similar to templui, but makes bundling possible. Also borrowed pipeline filters from html/template. But you're right, this does involve a _build_ step. But I think it's worth it.

Later I'll add the bundler free version. But really, vite has been so useful. Just treat it as another tool.

by jackielii

7/25/2026 at 6:36:30 PM

A GSX + Wails combo sounds interesting for developing desktop apps fully in Go

by hoppp

7/24/2026 at 8:37:24 PM

Looks good. I normally package a webui up with vite and serve that but I'll keep this in mind

by gen3

7/24/2026 at 10:22:46 PM

Yep, exactly, you can also do code splitting by adding multiple entry points. https://github.com/gsxhq/vite does the heavy lifting

by jackielii

7/24/2026 at 9:43:08 PM

does it work with htmx?

by skontraandrija