I often feel like Docker shouldn't even be needed for Go apps. It's just so easy to have your dependencies in order if everything is statically linked.
I agree. Skepticism usually serves people well as a lot of new tech turns out to be just hype. Except when it is not and I think this is one of those few cases.
I don't understand their worries. What are they trying to achieve with this? I can understand e.g. not wanting to have affiliate links on fraudulent/deceptive websites, but how is a search interface hurting anybody?
It was a great experience, at least to the extent I needed it. What sold me on it is its support for template composition[1], something I've struggled with using the standard `html/template`. And I really like the idea of generating statically typed templates which are just Go functions in the end of the day. In theory, I can share them between many of my apps, especially as I'm using a monorepo for all my projects. This is yet to be tested though.
There are some rough edges around using `script` templates[2], for example it doesn't allow you to pass `this` and `arguments` from HTML event handlers[3]. This is not a show-stopper though, because you can always fall back to just defining your event handler in an HTML <script></script> block, albeit without type checking of the arguments and deduping the scripts. Also it hurts Locality of Behaviour which I'm a fan of.
That being said, I think it has some great potential. I can completely imagine people building fully-fledged UI libraries in this once component reusability is improved.
But the best part of using templ for me was that I could completely get rid of Node and NPM from my stack.
I’ve been using pongo2 for a year or two as I always found the standard html/template to be annoying to work with for inheritance as you mentioned. I’ve got years of Django experience and always liked their templates, and pongo2 is basically just Django templates in Go so it’s nice.
But being able to break things into reusable components with templ is compelling (and works fairly well from my experimenting). I’m just not in love with how you pass data into it and I ran into a few awkward points with the string interpolation of data when doing inline scripts.
I’m sure if I spent more time with it, I’d overcome these issues quick.
I remember checking out pongo2 briefly before deciding on templ, but my lack of familiarity with its syntax kept me away. I guess the calculus is much different if you have prior experience, but for me it was attractive that templ uses Go syntax in its templates (with some exceptions).
Yeah, passing data if for some reason you can't use templ's `script` block can be annoying, if that's what you meant! I think they should make sure that the `script` block works in every situation and then it's going to be way less awkward.
Yes, apologies for that, I had to disable that call as it was making too many calls to the eBay API endpoint which resulted in the rate limit getting hit.
The Amazon PAAPI is "interesting" because to even access it, you need to have 3 qualified sales. But... I wanted to use the API to create a website where I'd post the affiliate links on. It's a chicken-and-egg problem. That's why I went with eBay.
Yep, I don't have much experience with affiliate programs (I like to build more SaaS-like apps[1]) but from my research Amazon have gotten really stingy circa 2019. Happy to see an alternative.
[1] I didn't know about the 3-sales precondition either. I guess some people bought albums on Amazon on my other music-related app.
