The standard templating in Go has been good enough for my small projects, and I usually avoid adding libraries if I can help it. But seeing this makes me want to try it just to see how it compares.
I'm in a similar position. I dismissed Templ by default when it started getting mentioned; I've always disliked JSX and the approach reminds me of that. I realized that it basically enables compiler and type checking of the template code though and now I'm interested. Ie, with html/template, you could easily reference a variable/attribute/etc that doesn't exist and have no way of knowing until you hit it at runtime so you had to be careful to write tests that covered all the conditional paths in the templates.
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).
Yes, it's exactly like having a bug in your code. Using Templ means that it gets caught at compile time (if not earlier since your IDE can show you that there's a problem as soon as you write the code). That's (IMHO) almost always preferable to catching it at test time.
Standard Go templating seems really lacking if you come from something like Jinja. Even with libraries like https://masterminds.github.io/sprig/ (used e.g. for Helm templating) it feels hard to use.
Standard Go templating can do almost anything you want it to do, but figuring out how to do it from the documentation alone can be a real challenge.
If this sounds to the reader like a defense of Go templates... it isn't.
Plus, I would agree that while it can do almost anything you want, that doesn't mean it always does it in a good way, or in a way that makes sense if you aren't a programmer. It's a pity. There's some power there, and I like the attempt at making templating safe, but it could really use a v2.
