Templ: A language for writing HTML user interfaces in Go

but otherwise, I'm quite liking it so far

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, " "))
  }

edit: reformat and typos.

there's an obvious typo of a variable name in the template "Titl" instead of "Title". Program compiles. Parse() succeeds. It just fails at runtime (outputting "<title>" and stopping. My understanding is that a Templ equivalent would probably end up with a compile error much earlier on (and probably more obvious in your IDE as well).

There is a very simple and productive subset of PHP that I feel got neglected over the last 1-2 decades.

The simple, but relatively fast “array”, which has value semantics.

The batteries included networking (HTTP, SMTP etc.) and SQL stuff.

The stateless execution model and straightforward way to combine and execute scripts.

And finally the in-built, seamless HTML templating.

It’s unfortunate that especially the last one got neglected so developers feel the need to build a safe abstraction over it.

Idk if it has to with "modern" or not. Proper escaping contexts (whether, and which delimiters to quote in attributes, in content, in markup declarations, ...) are already defined by SGML, with HTML-aware templating or other vocabulary-specific expansion such as suppressing <script> elements injection as would be required by basic user commenting also being covered by SGML. My impression was that go/templating (and maybe pug?), while considered advanced relative to other templating packages shitting strings into markup, still requires explicit sanitation depending on the insertion context.

> My JavaScript modifies the DOM rather than creating it.

So (as usual) the key is to find the balance that works for you instead of pursuing one way (only server-side rendering or only SPA Javascript framework).

For the time being this approach works very well for me.

With every project that grew the need for UI state I either wished I went with client side rendering or did so from the start for the parts that needed it.

The issue is: manipulating the DOM can become hard to reason about. You either somehow manage to use the DOM as your source of truth, or you manually sync your state into and out of the DOM, and other things like the URL etc.

The “immediate mode” style GUI model is much easier to reason about, because you can think of each render as a fresh start.

You don’t need React for this, in fact other libraries do this faster and without additional complexity such as Lit. Plus if you use something with web components, it is easier to mix and match client side and server side templating.