This video is a few years old, but the core concepts remain the same.
They are not concatenation by themselves. But for them to be useful, you will end up doing a lot of it because there's nothing else to do with strings than parse (often with regexps [1]) and concatenate [2] the strings. And then you dump the concatenated string into the DOM using `.innerHtml` [3]
There's no magic.
[1] https://github.com/lit/lit/blob/main/packages/lit-html/src/l...
[2] https://github.com/lit/lit/blob/main/packages/lit-html/src/l... and https://github.com/lit/lit/blob/main/packages/lit-html/src/l... and so on.
[3] https://github.com/lit/lit/blob/main/packages/lit-html/src/l...
Any property can be a full JS object. When the property is changed, it is re-rendered in your component. I have never touched innerHtml and my Lit apps pass and render all kinds of stuff into html`` tagged templates.
It's really pure magic because you can freely mix regular old HTML and regular attributes with dynamic data and data binding. There's more than one way to write anything which gives you great flexibility. I adore tagged templates, and they work for CSS and SVG, too.
I'm talking about how lit is implemented internally and that's why I provided links to relevant parts of lit's code.
People having no idea how things work is the bane of our industry. And that's why we have objectively false statements like "regular old HTML and regular attributes with dynamic data and data binding".
Lit is almost as far from "regular old HTML" as React's JSX is: lit is a HTML-like DSL that even has constraints on how you use tagged literals themselves.
E.g. `<${tagName}></${tagName}>` is a valid tagged literal and it's invalid in lit.[1]
> they work for CSS and SVG, too.
If lit lets you mix SVG with custom elements, they don't really use custom elements. See discussion https://twitter.com/Rich_Harris/status/1198339672361119745?s...
[1] https://lit.dev/docs/templates/expressions/#invalid-location...
Are you suggesting that Lit is updating .innerHtml when it doesn't need to? And are you sure about that? Because that should be entirely under my control by setting properties or state of the component, not by Lit redrawing them willy-nilly.
Literally nowhere did I say that. I was responding to a specific thing.
How is it "objectively false" that Lit mixes regular HTML with data binding? That is exactly how it works. I have several Lit apps and they use regular HTML as well as custom components and both have access to Lit properties and state that are dynamic.
Are we talking at cross-purposes or are we trying to say the same thing two different ways? I use this tech every day and I feel like you're saying something about it that's not true -- or maybe I'm not understanding your view.
I never said needless
> that "string concatenation" is the only thing they can do
It's not what "they" need to do. It's what you, or the library using them needs to do.
> Now we are agreeing that that's not true
If you invent something that I never said, then yes, we can both agree it's not true.
> How is it "objectively false" that Lit mixes regular HTML with data binding?
Once again that is not what I said. The objectively false statement is that it's "regular HTML". Lit is a HTML-like DSL because none of this is "regular HTML" because those attributes are invalid in regular HTML:
html`<div ?hidden=${!show}></div>`
html`<input .value=${value}>`
html`<button @click=${this._clickHandler}>Go</button>`
// Valid JS, and valid tagged literals. Invalid Lit
<${tagName}></${tagName}>
No. You're inventing things that I never said or implied and arguing against those inventions.
You can definitely mix data binding with regular HTML. It might be "invalid" according to a spec that makes no difference. The point of all of this is to write apps that work and can be debugged.
What is the rallying cry against Lit, exactly?
Please re-read what I wrote in my very first comment
> What makes you say the .value and @click attributes are invalid?
Just checked the spec, you're right they are valid. Hm, I was sure they weren't. Won't dig through the history to see if this changed :)
However, "Authors must not use elements, attributes, or attribute values that are not permitted by this specification or other applicable specifications, as doing so makes it significantly harder for the language to be extended in the future.", https://html.spec.whatwg.org/multipage/dom.html#elements
So I'd say they are still not okay on existing HTML elements
> It might be "invalid" according to a spec that makes no difference.
That is a very bad stance to take. "Invalid to the spec, but who cares".
> What is the rallying cry against Lit, exactly?
There's no rallying cry against lit. Stop. Inventing. Words. And. Meanings. I. Never. Said. Or. Implied.
There's a single very literal comment I made with links to support that statement.
I'm out of this discussion. I have other things to do with my life than keep saying "I never said what you think I said" over, and over, and over again.