It was actually great when you got it, but the learning curve was so steep many developers couldn't use it effectively to begin with. For complex pages only certain developers could make changes or fix the bugs. Precisely because it was functional and most developers at the time really only understood imperative.

In fact, I remember the DailyWTF had a WTF about using XSLT as client-side transforms a few years later:

https://thedailywtf.com/articles/Sketchy-Skecherscom

But doing something like that was in fact so much faster than doing it in js, and when you groked it (deliberate throwback), it was so much simpler. I actually wrote a pivot table control in XSLT which completely blew away the performance of the pre-v8 javascript one. Pre-V8 javascript was so slow most developers wouldn't believe you now. A 10,000 iteration loop of even basic operations was often enough to cause IE6 to show a pop-up saying the page wasn't responding.

The pivot table in javascript would crash with just a few hundred lines of data, in XSLT it was instant with even 10,000s.

A really interesting use of XSLT on the web at the time was the WoW character viewer. You could view (and share) your character on Blizzard's website, with all their gear, skills, etc. It was blazingly fast for the time and it was all written in XSLT.

CSS and HTML have a dual relationship. You could certainly write CSS with an XML-like syntax but people would always get confused at whether they are looking at style or markup. Because HTML and CSS look completely different you never have that problem.

XSLT shares the same problem with the RDF specs coming out at the same time that it hid the production rules/logical nature of the system, had it looked more like

  <someElement someAttributeattribute=$x/> -> <anotherElement>$x</anotherElement>

Granted, it did seem that XML got more heavily abused than some other options for a while. I am curious if that is just a by product of when it was introduced. That or just the general proliferation of how many front end developers we have. (I hate that I am pushing that to almost be a complaint. I certainly don't mean it that way.)

And don't get me wrong, I don't necessarily want everything absolute positioned. I just find it amusing when people try to get a badge or some such on something and then herculean efforts they will go through to get that badge exactly where they want it.

So, with bluesky, the amount of markup that goes into the footer menu of each post would be what I'm looking at. Tools were clearly used to get styles such as "css-g5y9jx" and this isn't the worst examples I've seen. But I am curious on why so many nested divs seem to be needed all of the time.

I am not clear what you mean by canvas-like approach? I think folks should still use elements. Just fewer of them, all told.

Direct to my claim, though; my argument is just that templates/designs are visual things. I don't think people are thinking in terms of nested div elements. They largely don't even think of sections of their template as parent/child relationships. They have a visual thing and want it filled in with whatever data.

If you’re working on generating markup, it makes more sense to do that at the markup level than constantly switch between markup and imperative JavaScript.

It might use JavaScript for control flow, but does it really count when it uses it in a way that is not idiomatic at all? It’s not idiomatic JavaScript to use map instead of for everywhere, and it’s not idiomatic JavaScript to use ternaries instead of if everywhere. Writing JSX looks very different to writing normal JavaScript.

I largely get the intent of what you are saying. But the entire point of why developers use templates is so that they can create pages that meet a design. And the entire reason I think they constantly get redone, is that design is inherently a visual process.

This is like trying to use formatting strings to try and handle localization. It just doesn't work. Folks will try and piecemeal all of the different strings in their application, only to find that some languages don't decompose the sentences in the same way. It can work wonders in small demos. It falls on its face when doing large things.

Don't get me wrong, I'm largely sympathetic to the gripes about the `createElement` and related methods. I've hacked on top of them many times with stuff similar to https://taeric.github.io/cube-permutations-1.html. They aren't pretty. But I'm not entirely clear on why template strings would be largely better?

Further, I could be surprised and this new API will usher in a better way of doing things. I'm not opposed to the effort. I just have a low prior on it succeeding. And I heavily disagree that we know what a good templating syntax is. Quite the contrary, until we learn to embrace visual artifacts, I do not think we will solve the templating needs.

Do you have examples that are good?

DOM sucks though, it's slow, it's heavyweight, it lacks transactions. We're stuck with it, and frameworks like React have to do the DOM diffing + patching thing, explicitly, in JS.

(I'm still of the sort that thinks Signals are just worse Observables, so it's not a proposal I'm particularly thrilled about, but were it to be adopted Signals are easy to use in Observable contexts as well, they are just uglier half-implemented BehaviorSubjects, though maybe with a few extra lint rules to prefer Observable behaviors over Signal ones.)

1. https://developer.android.com/develop/ui/compose/kotlin

and then you immediately go on to say this:

> tagged templates could reach at least the same level of DX as JSX if the community invested the resources to make that better.

So, tagged templates are also non-starters without IDEs helping autocomplete, linting/format, syntax coloring.

> i'm not saying it's the right solution for a standard, but it would be way better than jsx, since tagged templates are already a standard.

They are strings. There's no magic in tagged templates that somehow make them immediately better for some custom non-standard syntax compared to JSX.

You can't just plop a string containing lit's custom non-standard syntax into an IDE (or a browser) and expect it to just work because "it's tagged templates are standard".

For the purpose of templating in the browser there's literally no difference between standardizing a custom syntax based with JSX or tagged templates.

It really is a shame Apple don’t invest more in WebKit and the web standards process. Although they’ve been doing a lot better over the past few years.

Or that their mere existence infects nearly every spec in existence delaying and needlessly complicating actual useful specs like Scoped CSS?

    <!DOCTYPE html>
    <title>Example</title>
    <cool-dog>
        <template shadowrootmode="open">
            <style>
                :host {
                    display: block;
                    font-family: system-ui;
                    margin: auto;
                    width: fit-content;
                }
                ::slotted(img) {
                    border-radius: 1em;
                }
            </style>
            <slot></slot>
        </template>
        <img
            src="https://placedog.net/512/342?random"
            width="512"
            height="342"
            alt="A dog"
        >
        <p>Check out this cool dog!</p>
    </cool-dog>
    <script>
        customElements.define(
            "cool-dog",
            class extends HTMLElement {},
        );
    </script>

Now, I’ve noticed that since the text is a caption for the image, I should actually use <figure> and <figcaption>. So let’s do that:

    <!DOCTYPE html>
    <title>Example</title>
    <cool-dog>
        <template shadowrootmode="open">
            <style>
                :host {
                    display: block;
                    font-family: system-ui;
                    margin: auto;
                    width: fit-content;
                }
                ::slotted(img) {
                    border-radius: 1em;
                }
            </style>
            <slot></slot>
        </template>
        <figure>
            <img
                src="https://placedog.net/512/342?random"
                width="512"
                height="342"
                alt="A dog"
            >
            <figcaption>Check out this cool dog!</figcaption>
        </figure>
    </cool-dog>
    <script>
        customElements.define(
            "cool-dog",
            class extends HTMLElement {},
        );
    </script>

It’s because web components can’t style anything other than their direct children. You can style the <img> when it’s a direct child of the web component, but as soon as you need anything more complex than an entirely flat hierarchy, you run into problems. Even if it’s something as simple as wrapping an <img> in a <figure> to associate it with a <figcaption>.

What’s the “official” way of getting things like this done when you bring it up with the people working on the specs? Make a custom property to fake the real one and then set a global style that listens to the fake property to set it on the real one:

    <!DOCTYPE html>
    <title>Example</title>
    <style>
        img {
            border-radius: var(--border-radius);
        }
    </style>
    <cool-dog>
        <template shadowrootmode="open">
            <style>
                :host {
                    display: block;
                    font-family: system-ui;
                    margin: auto;
                    width: fit-content;
                    --border-radius: 1em;
                }
            </style>
            <slot></slot>
        </template>
        <figure>
            <img
                src="https://placedog.net/512/342?random"
                width="512"
                height="342"
                alt="A dog"
            >
            <figcaption>Check out this cool dog!</figcaption>
        </figure>
    </cool-dog>
    <script>
        customElements.define(
            "cool-dog",
            class extends HTMLElement {},
        );
    </script>

Nope. Every instance of the web component needs its own <template>. The best you can do is write some JavaScript to copy the template into each one.

The developer ergonomics of this stuff is terrible. It’s full of weird limitations and footguns.