Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gsxui – Shadcn-style components for Go

ui.gsxhq.dev

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Gsxui – Shadcn-style components for Go

#11

Post by indemnity »

SamInTheShell wrote: post #10
jackielii wrote: post #6

Earlier quoted context omitted.

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.

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

Re: Gsxui – Shadcn-style components for Go

#12

Post by saurabhmudradi »

jackielii wrote: post #6
sosodev wrote: post #3

GSX 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…

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

Re: Gsxui – Shadcn-style components for Go

#13

Post by jackielii »

indemnity wrote: post #11
SamInTheShell wrote: post #10

Earlier quoted context omitted.

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.

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

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

Re: Gsxui – Shadcn-style components for Go

#14

Post by throw1234567891 »

SamInTheShell wrote: post #10
jackielii wrote: post #6

Earlier quoted context omitted.

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.

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

Re: Gsxui – Shadcn-style components for Go

#15

Post by pjmlp »

SamInTheShell wrote: post #10
jackielii wrote: post #6

Earlier quoted context omitted.

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.

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

Re: Gsxui – Shadcn-style components for Go

#16

Post by evilduck »

jackielii wrote: post #13
indemnity wrote: post #11

Earlier quoted context omitted.

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

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

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.

Re: Gsxui – Shadcn-style components for Go

#18

Post by nzoschke »

jackielii wrote: post #6
sosodev wrote: post #3

GSX 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…

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

Re: Gsxui – Shadcn-style components for Go

#19

Post by indemnity »

evilduck wrote: post #16
jackielii wrote: post #13

Earlier quoted context omitted.

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

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.

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.

Re: Gsxui – Shadcn-style components for Go

#20

Post by SamInTheShell »

indemnity wrote: post #19
evilduck wrote: post #16

Earlier quoted context omitted.

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.

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 lo…

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

Projects like grafana do stuff like this already. It’s a known good pattern.

Post reply on HN