3 ms·

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 t

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.

mkesper 3y ago
Standard Go templating seems really lacking if you come from something like Jinja. Even with libraries like https://masterminds.github.io/sprig/ https://masterminds.github.io/sprig/ (used e.g. for Helm templating) it feels hard to use.
- arp242 3y ago
  It's different from Jinja, but feature-wise it's about on-par.
- jerf 3y ago
  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.
thraxil 3y ago
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

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.

mkesper 3y ago

Standard Go templating seems really lacking if you come from something like Jinja. Even with libraries like https://masterminds.github.io/sprig/ https://masterminds.github.io/sprig/ (used e.g. for Helm templating) it feels hard to use.

arp242 3y ago
It's different from Jinja, but feature-wise it's about on-par.
jerf 3y ago
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.

thraxil 3y ago

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