3 ms·

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

I'm not sure what you mean. Eg, here: https://gist.github.com/thraxil/5ee7cdb4edb3b4846580e33f17ecd359 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 3y ago
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 3y ago
  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 3y ago
    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