figaro has quit [Read error: Connection reset by peer]
<isd>
Ug, I hate html templates. I want to be able to just pass back two different fragments to the caller, to be rendered in different places, but no...
<isd>
To be clear, what I want is not a templating language that has that one feature. I just want to use my regular programming language, and be able to compose the rendering logic the same way I do all of my other code...
<TimMc>
It's interesting to contrast the state of the art of HTML generation with JSON generation.
<TimMc>
With JSON you build a tree and then serialize it. With HTML you... well, it's some nasty combination of string interpolation, concatenation, custom templating languages, and a smattering of tree manipulation.
<TimMc>
I think I've seen one, maybe two tools that treat HTML like data for the purposes of HTML generation.
<kentonv>
isd, does React / jsx do what you want?
<simpson>
TimMc: I explored this from the E perspective recently: https://lobste.rs/s/ozllaj/parse_don_t_type_check#c_vqyawc Part of the punchline is that yeah, basic string building was better for HTML generation than the fancy templating and reparsing techniques.
<TimMc>
Better in terms of performance, usability, or correctness?
<TimMc>
nevermind I'll read it :-P
<simpson>
I didn't do serious performance testing; off the cuff, html`<p>Hi!</p>` can't possibly be less work than m`tag.p("Hi!")` because the former has to do the equivalent of the latter.
<simpson>
Otherwise, it's the same in terms of usability and correctness. The original article's slogan about parsing and type-checking is based on the idea that one is like the other.
<isd>
kentonv: I have limited experience with react per-se, but I think yes. Certainly comes closer than blaze templates...
<TimMc>
There's a Clojure library called Enlive where you load an HTML skeleton from a file into a tree, then transform it by using CSS selector/function pairs, then flatten it back into HTML.
<TimMc>
I don't know if I love it, but it was refreshingly different.
<isd>
I feel like I've stirred up this conversation in this channel before.
<TimMc>
yes :-)
<isd>
Well, our UI code is still frustrating to hack on, for all the same reasons
<kentonv>
I think we don't use blaze the way it was intended. The intention was to have lots of small templates, but we tend to have huge templates with lots of embedded control flow
<kentonv>
with that said, Meteor gave up on Blaze and conceded to React like 6 years ago
<kentonv>
so we should probably try to switch some stuff?
<kentonv>
it's sad though, I prefer blaze's approach of generating reactive code from templates over react's approach of generating whole DOM trees at runtime and then diffing them to find what changed
<isd>
They apparently support Svelte now too
<isd>
And Vue
<isd>
But I don't know if either of those solves my concerns
<kentonv>
from a brief look at the Svelte web page, it looks like my cup of tea
<isd>
I figured you'd feel that way
<isd>
It's intriguing. I'd want to see if it was expressive enough though; perf is not actually the problem I'm having, and it would be a shame to switch to something else and then find that it's not better in the aspect that actually needed improvement.
<kentonv>
I mean if I understand correctly, it sounds like it should result in less runtime code, too
<kentonv>
and I feel like pretty much every modern web app has way too much browser-side code
<isd>
Maybe I'll play with it. It would be nice to cut some fat, but ultimately I'm more worried about maintainability.
<JacobWeisz[m]>
Main perk of React is presumably just that everyone is using it.
<isd>
My main misgiving about React is the dependency footprint -- I'd like to move in the direction of less dependency bloat, not more.
* isd
is half tempted to write his own thing
<JacobWeisz[m]>
Ian, if there were enough of you, I'm pretty sure you'd write your own everything.
<JacobWeisz[m]>
:D
<isd>
:P
<isd>
Really what I want is something like Jane Street's Incr_dom -- separate the ractive computation from the UI layer entirely, and then just do the vdom thing, but because you're computing the vdom itself reactively, the diff on any part of the tree that didn't get re-computed is O(1)
<isd>
reactive
<abliss>
fyi, it looks like Bonsai is supposed to be the new hotness that improves on Incr_dom.