glsubri
commented
1 month ago I've also been thinking about something like this in the last weeks.
While I think the approach of shadcn/ui works really well in the javascript world, I wonder how much it would stick in the go world. People in javascript-land are very used to importing tons of libraries, having a lot of config files and needing tools like transpilers, bundlers, etc... Contrasting that with Go where there isn't much that can't be done through the go command.
For example, one of the reasons for which I enjoy using gomponents instead of templ, is the fact that it's just Go. No new types of file. No extra building step. No weird syntax. Just Go. It's simple.
I love the idea of having shared gomponents, but I think that if it gets too complicated, most people will just not use it.
Additionally, I feel like, while fragmented in thousands of libraries, the javascript world does revolve around React, tailwindcss and some other core projects. Which means that most people use the same tech stack. Having this amount of people makes these component libraries much more worth it in terms of time invested.
As a "food for thought", I've really enjoyed the way some component libraries like https://www.hyperui.dev/ or https://www.penguinui.com/ approach the problem. They simply show you the code of the component in HTML (and with some AplineJS if you want). The big downside to this for me right now, is that I need to translate HTML to Gomponents.
If this could be automated (at least partly) for React (like https://htg.piotrkowalski.me/ for HTML), maybe we would be able to benefit from reusing shadcn/ui or other existing component libraries instead of making a new one.
In any case, I'd much rather have something than nothing. I'm happy to help if this moves forward
camstuart
markuswustenberg
Context
The goal of components is to share, between your own projects and with other community members. However, a big challenge is doing so in a generic enough way that components satisfy enough needs to be useful, without being too opinionated. This can be discouraging to would be component authors, as they they need to address their own requirements first, and may not have enough time to think about and implement the needs of others.
Proposal
Follow the approach of shadcn/ui by actually generating source code into ones project, rather than importing a library.
Once the Gomponent is generated, the project author can use it as is, or modify it as required. Almost like vendoring Go packages like we did back in the day.
Approach
list(display metadata) andpull <gomponent-name>The CLI simply grabs the Gomponent sources and related tests, and places them into your project. Perhaps there are some overrides on path and package. But in the first instance, follow @markuswustenberg convention of path
htmlpackagehtmlFrom here, the project owner uses the Gomponent as is, or makes whatever modification they feel are needed (usually style adjustments)
This allows Gomponent authors to focus on functionality and ignore style concerns. Hopefully motivating them to share.
IE: I would rather tweak an existing Gomponent that almost fits my needs, than build from scratch. And a streamlined copy paste mechanism would be useful.