4 ms·

Gsxui – Shadcn-style components for Go

73 points by jackielii 2mo ago

gen3 2mo ago
Looks good. I normally package a webui up with vite and serve that but I'll keep this in mind
- jackielii 2mo ago
  Yep, exactly, you can also do code splitting by adding multiple entry points. https://github.com/gsxhq/vite https://github.com/gsxhq/vite does the heavy lifting
sosodev 2mo ago
GSX seems interesting but I don’t understand why it depends on the node ecosystem. I just want to use Go for everything.
- jackielii 2mo ago
  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 2mo ago
    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.
    - indemnity 2mo ago
      Same, hard pass on remote shell as a service that is Node and its ecosystem.
      - jackielii 2mo ago
        I'm not sure I follow. Node is not on the production path
        evilduck 2mo ago
        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.
        indemnity 2mo ago
        As someone who has had to clean up systems that only did a _npm install_ to get compromised, despite being good Renovate citizens, it doesn't matter if it is not "on the production path". I don't care to hear arguments about how npm was _configured wrong_. A tool with insecure defaults, with a long and storied history of being the vector by which data has been exfiltrated and companies hacked, needs to do an awful lot to justify still being used for any infrastructure our team is responsible for.
        SamInTheShell 2mo ago
        The proxy caches and package solution for Go has had its own drama. My big contention with this project is that if I wanted to use node (or npm; or vite) in any capacity, I would have chosen node for that. I don’t want to use those tools in this context because it serves me worse than a well thought out solution. The thought out solution is to isolate your frontend into its own directory. You can embed and serve that as part of your Go server. That frontend could have been done with react, vite, jsx, whatever typescript nonsense you want; without the Go parts necessarily needing npm or node in the build process. I literally have toy projects illustrating the idea (this one is a toy I had AI make with some of my own patterns months ago): https://github.com/SamInTheShell/social/tree/main/frontend https://github.com/SamInTheShell/social/tree/main/frontend Projects like grafana do stuff like this already. It’s a known good pattern.
  - saurabhmudradi 2mo ago
    Cool! was looking for go based frontend options for local data heavy dashboard usecase, this seems perfect.
  - nzoschke 2mo ago
    Thanks for the explanation. I do find air lacking for sufficiently complicated applications servers
nzoschke 2mo ago
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.
- jackielii 2mo ago
  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.
skontraandrija 2mo ago
does it work with htmx?
- jackielii 2mo ago
  Absolutely. I already ported my production app - enterprise customer to it. I use it with https://github.com/jackielii/structpages/ https://github.com/jackielii/structpages/
hoppp 2mo ago
A GSX + Wails combo sounds interesting for developing desktop apps fully in Go

73 points by jackielii 2mo ago

gen3 2mo ago

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

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

sosodev 2mo ago

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

jackielii 2mo ago
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 2mo ago
  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.
  - indemnity 2mo ago
    Same, hard pass on remote shell as a service that is Node and its ecosystem.
    - jackielii 2mo ago
      I'm not sure I follow. Node is not on the production path
      - evilduck 2mo ago
        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.
        indemnity 2mo ago
        As someone who has had to clean up systems that only did a _npm install_ to get compromised, despite being good Renovate citizens, it doesn't matter if it is not "on the production path". I don't care to hear arguments about how npm was _configured wrong_. A tool with insecure defaults, with a long and storied history of being the vector by which data has been exfiltrated and companies hacked, needs to do an awful lot to justify still being used for any infrastructure our team is responsible for.
        SamInTheShell 2mo ago
        The proxy caches and package solution for Go has had its own drama. My big contention with this project is that if I wanted to use node (or npm; or vite) in any capacity, I would have chosen node for that. I don’t want to use those tools in this context because it serves me worse than a well thought out solution. The thought out solution is to isolate your frontend into its own directory. You can embed and serve that as part of your Go server. That frontend could have been done with react, vite, jsx, whatever typescript nonsense you want; without the Go parts necessarily needing npm or node in the build process. I literally have toy projects illustrating the idea (this one is a toy I had AI make with some of my own patterns months ago): https://github.com/SamInTheShell/social/tree/main/frontend https://github.com/SamInTheShell/social/tree/main/frontend Projects like grafana do stuff like this already. It’s a known good pattern.
- saurabhmudradi 2mo ago
  Cool! was looking for go based frontend options for local data heavy dashboard usecase, this seems perfect.
- nzoschke 2mo ago
  Thanks for the explanation. I do find air lacking for sufficiently complicated applications servers

nzoschke 2mo ago

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.

jackielii 2mo ago
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.

skontraandrija 2mo ago

does it work with htmx?

jackielii 2mo ago
Absolutely. I already ported my production app - enterprise customer to it. I use it with https://github.com/jackielii/structpages/ https://github.com/jackielii/structpages/

hoppp 2mo ago

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