vecty VS gomponents

Vecty

It depends on how specifically you don't want to write HTML/CSS/JS and how broad your definition of "frontend" is. There are a handful of all-go frontend frameworks such as Vecty and Vugu of varying maturity and completeness. Then there's other libraries that more or less have you write HTML tags in go, such as go-app.

It draws on Go's syscall/js library as inspiration, which is pretty powerful (I wrote a pretty popular React-like framework using it a while back.)

A note on wasm: I'm building a hobby project with it right now and have tried different frameworks, I tried vecty which is nice to compile but full of bugs and unexpected behavior. I'm now on vugu which works better but is still harder to work with than a JS framework.

https://github.com/hexops/vecty/ is a framework for developing dynamic web frontends in Go. It's not production-ready, and will likely get some rewrites once generics drop, but it's pretty neat (I'm a contributor).

There's Vecty, though it's likely to get a bit of a redesign once generics drops.

How does it compare to https://github.com/hexops/vecty or https://github.com/bep/gr ?

Reminds me of Vecty from the GopherJS project: https://github.com/hexops/vecty .

Gomponents is also a great way to deal with HTML in Go.

https://www.gomponents.com/

If you mean “action=/foo” for a “form” tag, there is an “Action” attribute: https://github.com/maragudk/gomponents/blob/main/html/attrib...

I'm really happy you like it. :) And thank you for your comment, I really appreciate newcomer viewpoints especially.

Have a look at the `Classes` helper component already available: https://github.com/maragudk/gomponents/blob/main/components/...

Yeah, I'm not a total fan of the runtime panics, but it was a tradeoff where I chose in favour of API simplicity and readability. In practice, it works out well, because you catch any typos at development time.

I've had elements and attributes in separate packages before, but then you can't dot-import both packages and not have name clashes, and have to either prefix elements or attributes with the package name, which makes the code much less readable. Again, a tradeoff. :)

Gomponents:

I now always use https://github.com/maragudk/gomponents for frontend components (I'm the author of that library) together with HTMX (https://github.com/maragudk/gomponents-htmx), and it's just so much more fun and fast to work with.

However, there is an alternative to achieve React-ish components in Go using this package: https://github.com/maragudk/gomponents

reminds me of https://github.com/maragudk/gomponents

I’ve also started just rendering views from the Go backend. It’s so nice and simple when you don’t need an SPA (like in your case). I didn’t like the syntax of html/template though, so I started a small view component library. Maybe it would be useful to you too, wrote about it here: https://www.maragu.dk/blog/gomponents-declarative-view-components-in-go/

Are you speaking of something like: gomponents? I can see what it has to offer. I tried it for half an hour but did not feel that well about it.