# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 13
# self = https://watcher.sour.is/conv/v43fota
What kind of fucking bullshit is this horrible Go template garbage!? What the hell is wrong with my template? https://lyse.isobeef.org/tmp/wtf_test.go.txt I rip it all out and replace it with some other template engine that doesn't suck balls. Holy fuck. What a giant waste of time, every fucking time I deal with this shit. End of rage. :-)
These comparisons are no operators but functions, hence, the solution is: {{ if ne (len .Events) 1 }} However, it makes absolutely no sense to generate utter bullshit instead of producing a syntax error. Any useable template engines to recommend that do not pull in a metric shitton of dependencies?
@lyse I haven't found a better Go templating engine tbh, I've just gotten used to the one in the std lib 😅
@lyse I haven't found a better Go templating engine tbh, I've just gotten used to the one in the std lib 😅
@lyse I haven't found a better Go templating engine tbh, I've just gotten used to the one in the std lib 😅
@prologic I'm coming from the Tornado world, so Tornado templates would be really great. Or Jinja, they'e quite close, although I like Tornado more. It's been a while, though, that I heavily worked with them.
Looking around I found a few candiates that might be worth looking into. Haven't tried any of them so far, though. I just looked at their dependencies, syntax and features.
I came across https://git.sr.ht/~dvko/extemplate which I believe is a must if one sticks to the standard library. It adds the extends concept, which is heaps more natural to me instead of of keeping track of the relations and reparsing them manually myself. The template.ParseFS(…) seems to be rather useless I have found. It doesn't really work all that great. Or I was holding things wrong. I will give extemplate a shot today regardless whether I stick with the default templates. extemplates doesn't have any other dependencies which is always a big plus in my book.
https://github.com/CloudyKit/jet/blob/master/docs/syntax.md looks fairly useable. It only uses one additional small third-party library which has no dependencies itself.
Zero dependencies for https://github.com/flosch/pongo2, a Django-inspired template engine. This is also close to Jinja templates.
https://github.com/valyala/quicktemplate is interesting as it compiles it into native Go code and claims to be very fast. Adds a bunch of dependencies.
A Jina-inspired template engine, that adds heaps of dependencies: https://github.com/noirbizarre/gonja I guess I have to compare Jinja and Djano before I know which syntax I generally like more. Probably would go with pongo2 over gonja, just of the number of deps. But more investigation is needed.
Another Jinja2 with an even larger number of third party libraries is https://github.com/kluctl/go-jinja2. Seems to work on invoking Python under the hood eventually. So, yeah, most likely not this one.
@prologic Too bad, extemplate doesn't work with Go-embedded file systems, just the regular host file system. I could patch it and then proceed, but I guess I just move on and look at jet.
@lyse Sometimes I tend to think we "do too much"in templates and templating engines. I honestly think all "logic" should be done in Go, and templates should be nothing more than variable "fill-ins". 😅
@lyse Sometimes I tend to think we "do too much"in templates and templating engines. I honestly think all "logic" should be done in Go, and templates should be nothing more than variable "fill-ins". 😅
@lyse Sometimes I tend to think we "do too much"in templates and templating engines. I honestly think all "logic" should be done in Go, and templates should be nothing more than variable "fill-ins". 😅
@prologic Yeah, I kind of agree. But having separate template files helps in the developing process. Just think of the syntax highlighting alone instead of large monotone strings in your Go code. :-) Also, depending on the permissions of the viewer, one certainly needs a bunch of conditionals to show or hide certain things in the output. Also, auto-escaping is something I don't want to miss. Inheriting is also at least needed for the layout stuff. Maybe Go code alone is the way to go for smaller code bases. Especially if there is no dedicated designer who just wants to work on HTML & CSS and doesn't touch the programming side. I'm doing everything myself here, so, it might work. I would definitely need a set of some helpers to make quick use of my rendering inside Go in order to not go totally insane.
I don't like the additional parentheses in jet. Also a bunch of yields for invocation and the weird mix of content and actual parameters for custom "functions". Doesn't directly appeal to me. A custom loader for the go:embed file system could easily be added, though. Didn't actually try out anything, just looking at the examples in the docs and the code itself. Now investigating pongo2. Very promising looking so far.
Maybe I just pause and experiment with my own "engine" in pure Go. Again, missing syntax highlighting is gonna be my worst enemy I reckon.
@prologic Hmmm. Not so sure about that: https://lyse.isobeef.org/tmp/htmlresponsewriter.png Do I like it or not? I mean it's cool to be able to write quick helpers directly in Go. Another benefit is that the HTML form field names are directly visible and thus can be quickly connected to the incoming request. But it's still a bit awkward. An escape helper with a very short name would be a bit nicer to be used "inline". But I actually would go the other way around and mark everything explicitly safe and apply auto-escaping to all unmarked strings. This way it cannot be forgotten. But this then gets a bit lengthy in the Go code I reckon.