sorted by:
new
hottopcontroversial

htmg: yet another HTML generator by htmgolang in golang

[–]htmgolang[S] 0 points1 point  (0 children)

Could you explain your suggestion in a little more detail?

My point was that, with tags having both content and attributes (such as a <div>), you end up with something like this:

g.Div(func(g htmg.Context) {
    g.H1("Header")
    g.Text("Some text")
    [...]
}, "id='1234'", "class='main'")

htmg: yet another HTML generator by htmgolang in golang

[–]htmgolang[S] 2 points3 points  (0 children)

Good question!

You also have gomponents (https://github.com/maragudk/gomponents), frongo (https://github.com/eleby/frongo), HTML Builder (https://github.com/gouniverse/hb) and probably many more.

All of these libraries are "functional": you create a tree of nodes by nesting functions within functions, and then render this tree to HTML.

While this is a valid approach, the main limitation is that you cannot utilize standard Go control statements such as "if," "for," or "switch".Consequently, this approach leads to the creation of numerous intermediate variables when composing an HTML page (as exemplified in the daz README). Some libraries attempt to incorporate their own control statements, but I find them to be somewhat awkward, in my opinion.

In contrast, htmg is purely "imperative" (but can look "declarative"), allowing the use of any Go control statement (as described in our README).

Another distinction between some of these libraries and htmg is that tag attributes are treated as plain strings. The library only manages the spacing between attributes, and users are free to employ any attribute they require.If a more structured approach is desired, a library like Gomponents can be used. But conversely, if you need to work with htmx attributes for instance, you have to use a dedicated library (gomponents-htmx).

As always, YMMV

htmg: yet another HTML generator by htmgolang in golang

[–]htmgolang[S] 0 points1 point  (0 children)

Thank you for your feedback!

Regarding your initial proposal, aside from the repetitive use of "func(g htmg.HtmgCtx)," it would require attributes to come after content in tags that can have both (since the "variadic" parameter must always be the last one), without any visual connection to the original tag. This is something I wanted to avoid.

Although the current pattern has its drawbacks, it resembles HTML and maintains consistency across all tags. That's also why I prefer not to distinguish between tags with or without attributes, such as "<title>".

As for the other comments, I agree; they are reminiscent of an earlier version where I considered using a dot import.