gomponents VS quicktemplate

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.

Here are a couple:

https://github.com/julvo/htmlgo

https://github.com/rohanthewiz/element

I'm sure there are many more.

The thing about these is that performance is often not as good as when using templates, especially when the templates are compiled to native code. Quicktemplate [1] is still the leader here IMO, and I don't think the OP project brings much that couldn't be done pretty easily with QT.

[1] https://github.com/valyala/quicktemplate

From my experience you don't really need a distinct frontend framework for web development in Go. I've been able to use quicktemplate for some of my projects for rendering HTML pretty effectively. I've written about using it here.

If the question is about templating libraries, then I've seen people use other libraries than the html/template, like https://github.com/hoisie/mustache or https://github.com/valyala/quicktemplate

I originally started out trying to add features to quicktemplate, but didn't get any engagement, so went my own way: https://github.com/valyala/quicktemplate/issues/80

I've been using quick template with htmx and I'm really enjoying the combo. As a mostly backend developer it's a pretty intuitive approach. Now if someone could just build something to simplify working with CSS...

Like with the previous post, we're going to use djinn-ci/imgsrv as an example of using multiple sources in a build manifest. If we look at the top of the manifest file, we will see that it requires three repositories to build. These are, the source code for djinn-ci/imgsrv itself, golang/tools, and valyala/quicktemplate, defined like so,

I like Hugo quite a lot, but I don't like Go's standard library templates. I wonder if it is possible to use https://github.com/valyala/quicktemplate with Hugo?

For encoding, the receivers usually want very specific encoding (namespaces, nil as xsi:nil, not omitted value...) - templating with text/template or github.com/valyala/quicktemplate is easier on the long run, than fight with xml.Marshal and the other end's unspoken assumptions.

The "Hello World" example is up at https://github.com/a-h/qt-lsp - it's called qt-lsp because I started down this track looking to build IDE support for quicktemplate - https://github.com/valyala/quicktemplate/issues/80 - but didn't think it was practical when I dug into the design of quicktemplate more.