00:02 <isd> What needs getting around?

00:03 <JacobWeisz[m]> I get the error message added by that commit, unknown hostname.

00:05 <isd> Unfortunately there's no single static value we can hand it... Open an issue? For our purposes being able to turn it off would be fine.

00:07 <isd> An alternative would be to put a reverse proxy in front of it, but that seems sad just to work around this.

00:40 <JacobWeisz[m]> I've opened an issue to ask.

20:29 <isd> I still don't have a great handle on how to hack on Sandstorm's templates -- it seems like they're some of the messiest code we have. I've been staring at how to trigger a notification like "grains are backing up" from the bulk save backup button, and it's really not clear to me what the right approach is...

20:55 <kentonv> yeah blaze template state management is bizarre and we never figured out how to use it without creating a dumpster fire

21:44 <isd> I'm vaguely skeptical of template languages as a general concept. You're giving up programmability for some minor (and very subjective) syntax nicities. That doesn't strike me as a great bargain.

21:48 <isd> Like, sandstormTopbarItem is the kind of thing that is excessively hacky and difficult with a template language, which seems like it would be way, way easier to deal with with a proper programming language.

21:52 <kentonv> I guess the problem that templates are trying to solve is that specifying HTML DOM in code is cumbersome... but if the template is in a separate file then you end up tempted to extend the syntax to support programming constructs there, which maybe you shouldn't have

21:52 <kentonv> probably the right way to use blaze templates is to have many small templates that do one thing, whereas we have a lot of big monster templates

21:53 <kentonv> of course, react has their approach of merging HTML into the language, which is nice

21:53 <kentonv> but I think, ironically, Blaze did a better job at actual reactivity than React

21:54 <TimMc> Any language with data literals has a leg up, here. (Clojure, Javascript, some others.)

21:54 <TimMc> The ideal templating library would need a way to manage and merge small chunks of template in a fluent way.

21:55 <isd> Yeah, I'm dubious of the idea that doig dom manipulation in code is materially worse than what a template language gives you. a({href: ..}, ...) instead of <a href="..">..</a> ... I don't see the downside.

21:55 <kentonv> I mean, try writing out a longer example where the HTML contains text and elements

21:56 <isd> Eh, I think once you start putting i18n in the mix even the text bit ends up not being that meaningful.

21:57 <isd> Though I'll grant if you're splicing English right into the templates it scans a bit better.

21:57 <TimMc> If you want to see something unusual in this space, Enlive does server-side rendering with CSS selectors and transformers: https://github.com/timmc/pellucida/blob/master/src/org/timmc/pellucida/res/main.clj#L29

21:57 <kentonv> {a: {href: "..."}, body: [{cdata: "my link text"}, {b: {}, body: [{cdata: "this is bold"}]}]}

21:58 <kentonv> vs <a href="...">my link text<b>this is bold</b></a>

21:59 <kentonv> agreed that i18n means you don't actually what the text inline, but a11y means you don't actually want the layout inline either

22:00 <kentonv> really in code you want to be specifying logical components with properties specific to that component's purpose

22:00 <isd> You can do better than that. Something like a({href: "..."}, "my linked text", b("this is bold"))

22:00 <TimMc> I believe in Clojure's Hiccup syntax that would be [:a {:href "..."} "my link text" [:b "this is bold"]]

22:00 <TimMc> Any strings are automatically text to be escaped, not HTML.

22:00 <isd> (And my experience with Elm is that doing this in code is pretty ergonomic actually -- and it means everything is type checked)

22:01 <kentonv> and then you want to be able to convert that component structure into HTML or gtk or mobile UI or screenreader-optimized UI in different ways

22:02 <isd> Sure. But that just means factoring the rendering out into a separate set of functions.

22:02 <TimMc> With Enlive you write actual HTML, then transform it (enliven it) by injecting content, cloning nodes, or rearranging it as necessary. Here's the template that goes with that earlier link: https://github.com/timmc/pellucida/blob/master/src/org/timmc/pellucida/html/main.html

22:04 <TimMc> (I mention Enlive not because it's necessarily a great idea, but because I think it shows how little we've collectively explored the solution space.)

22:04 <kentonv> isd, well, I'm saying that ideally the purpose of the template language is to map logical components to HTML. I do think it makes sense to use a DSL for that purpose.

22:05 <kentonv> that said, the way we actually used templates in Sandstorm mixes lots of business logic into the templates

22:05 <kentonv> unfortunately

22:07 <TimMc> I've fallen out of love with the idea of components that can be rendered to different platforms (desktop, HTML, etc.) and feel at this point like just having separate clients might be better.

22:18 <isd> I just don't really see the point; I don't buy the syntactic argument, and I don't see what else templates buy you vs. just using functions.

22:18 <isd> (jsx is a better solution to the syntax issue on its own)

22:20 <kentonv> I guess in my mind jsx falls into the bucket of template languages... :)

22:22 <isd> I guess what distinguishes it is it isn't separate from javascript -- it's just some extra syntax in your existing PL. So it doesn't take language constructs away from you

22:22 <isd> (there are a bunch of places in the sandstorm templates that are screaming for higher-order functions... which we could just use if it were jsx).