[thraxil]

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.

[verdverm]

If you pass a struct as input, you can check data & constraints. That's more or less what this is doing as well

[thraxil]

I'm not sure what you mean. Eg, here: https://gist.github.com/thraxil/5ee7cdb4edb3b4846580e33f17ec...

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

[verdverm]

That's something that should be caught at test time. It's like having a bug in your code.

There is another class of template bugs that comes from input data, that's what I'm referring to. The validation catches it before rendering

[thraxil]

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.

[verdverm]

You have to introduce a new tool to your box and run more commands, so it is not free

people have a resistance to increasing tooling, and especially learning a new syntax or language, for a small task in a larger project

Since we test already, adding a test is often a much easier ask and lift

on top of that, you still need to validate inputs and test rendering with Templ anyway