Gsxui – Shadcn-style components for Go
ui.gsxhq.dev
Gsxui – Shadcn-style components for Go
1–10 of 20 posts
Re: Gsxui – Shadcn-style components for Go
#2Looks good. I normally package a webui up with vite and serve that but I'll keep this in mind
Re: Gsxui – Shadcn-style components for Go
#3GSX seems interesting but I don’t understand why it depends on the node ecosystem. I just want to use Go for everything.
Re: Gsxui – Shadcn-style components for Go
#4How 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.
Re: Gsxui – Shadcn-style components for Go
#5does it work with htmx?
Re: Gsxui – Shadcn-style components for Go
#6GSX seems interesting but I don’t understand why it depends on the node ecosystem. I just want to use Go for everything.
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
Re: Gsxui – Shadcn-style components for Go
#7How 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…
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.
Re: Gsxui – Shadcn-style components for Go
#8Looks good. I normally package a webui up with vite and serve that but I'll keep this in mind
Yep, exactly, you can also do code splitting by adding multiple entry points. https://github.com/gsxhq/vite does the heavy lifting
Re: Gsxui – Shadcn-style components for Go
#9does it work with htmx?
Absolutely. I already ported my production app - enterprise customer to it. I use it with https://github.com/jackielii/structpages/
Re: Gsxui – Shadcn-style components for Go
#10GSX seems interesting but I don’t understand why it depends on the node ecosystem. I just want to use Go for everything.
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…
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.