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