3 ms·

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 reali

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 3y ago
If you pass a struct as input, you can check data & constraints. That's more or less what this is doing as well
- thraxil 3y ago
  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

verdverm 3y ago

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

thraxil 3y ago
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