Even in React we do a lot of programmatic “UI generation” for data structures, and mostly use react for the more “unique” things, which is arguably a big part of our Enterprise application. We do use shared components, but it’s also very nice not to share them too widely in terms of testability and maintenance.

So I think it’s perfectly reasonable not to use tempting if it works for you. Especially if the templating isn’t very good, which is frankly most of them. I do think some templating can be good for prototyping, but as soon as you’re doing the same thing a lot of times and that thing doesn’t really change beyond what happens to the underlaying data structure, I think it’s very worth it to build it programmatically. Which is basically a lot of data CRUD UI in many organisations.

You can try gomponents https://www.gomponents.com/

It also has an HTMX plug in.

Thank you for the mention! :)

Relevant libraries, for those who want to dive directly into it:

- https://github.com/maragudk/gomponents

- https://github.com/maragudk/gomponents-htmx

Oh, thank you for open sourcing it! I'm having a lot of fun, and it's nearly as agile as react, only hit by the lack of expressiveness in the go language in some cases.

You're welcome! :)

I'm always open for feedback, so if you think there's room for improvement, feel free to open an issue for discussion on the repo. (That said, I'm fairly conservative about the API, trying to keep it simple for everyone to use.)

i just wish gomponents/html would define an alias for gomponents.Text so i don't have the impedance mismatch of switching the package qualifier

but otherwise, I'm quite liking it so far

Hmm. I see what you mean, but <text> isn't a valid HTML element, so that wouldn't work for that alone.

But try dot imports for the html package and you don't have to have a package qualifier for most of your view code at all! :D

I tried it yesterday until far past midnight.

gomponents is amazing! I find the abstractions just right. it now looks possible that I can port my minimalistic bun/deno setup with htmx to go.

I found "gow" watcher that allows auto-restart of the development webserver when go code was changed. And I'm using "hx-refresh" header paramter and "hx-trigger='every 250ms'" to have a simple polling browser refresh.

it also integrates well with tailwind css. you can use tailwind vscode extension and define a custom "classRegex" for gomponents "Class(...)" function.

I needed to write a custom `Classes()` function that allows me to have conditional classes like `clsx()`. it's a bit hacky, but I like the simplicity.

  func Classes(nodes ...g.Node) g.Node {
    var classes []string
    for _, node := range nodes {
     if node != nil {
      var builder strings.Builder
      _ = node.Render(&builder)
      c := builder.String()
      c = strings.TrimLeft(c, " class=\"")
      c = strings.TrimRight(c, "\"")
      classes = append(classes, c)
     }
   }
   return Class(strings.Join(classes, " "))
  }

the runtime panics for functions that use vararg for optional arguments and have an invalid number of arguments is probably an okayish trade-off. mixing attributes and children elements in the builder functions, I don't know if it's good or bad, but I like the simplicity; JSX and hyperscript-like functions separate tag, attributes, and children into three different parameters.

edit: reformat and typos.

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. :)

I would like to mention maud in this context:

https://github.com/lambda-fairy/maud

It is refreshingly different from other Rust templating libraries. It uses a proc-macro that compiles your HTML into Rust code. I also happen to use it in conjunction with HTMX and it works very well for me (at least in small projects). You will still have to learn a little bit of "special" syntax though, which you are looking to avoid if I understand you correctly.

while it looks nice, I’d prefer html and not to learn yet another DSL, the reason is that migrating is easier between template engines.

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

I don't really understand what you're looking for and I don't write web apps in Go, so sorry if this is a wrong answer.

The templ language linked here is compiling something that looks similar to React's JSX into Go code. And then you can do HTMX: https://templ.guide/server-side-rendering/htmx/

If you want to really go back to oldskool way you could use XML for this.

I believe I recently built something to do exactly what you're describing for HTML, though it's C++ (but maybe a useful basis for a rust version - I don't know).

https://github.com/rthrfrd/webxx