> there are a bunch of JS libraries that simplify working with the DOM without resorting to writing fake HTML in JavaScript.

The problem with arbitrary lines is that they are arbitrary: there are no criteria for them except your gut feeling.

You can't rant against "fake HTML" and then turn around and talk about a framework that uses fake JS inside its non-fake HTML.

> Oh, right, observables are the way to go. No, wait, hooks are the right approach. No, wait, signals are definitely the future.

1. It's called evolution. We don't know all the best solutions from the get go.

2. Guess what datastar is using underneath.

Honestly, I don't know if I should continue at this point as you clearly have literally no idea about what you're talking about. You "checked out" from keeping track, you haven't used Datastar or dug into its internals, you call literal verifiable facts a biased outlook from a framework developer etc.

> Look, the current web standards, and Web Components in particular, aren't perfect. I'm certainly not a fan of some of the design decisions. But they're tools that in conjunction cover a large amount of functionality that modern web frameworks simply ignore or reinvent. This is what I'm saying is a mistake.

Just a few issues with this "tool" that is not perfect, but must be used. Note, this tool has been in development for 14 years this year, and literally none of the "huge bloated frameworks" have this issue. Note that all of these are from the Web Component Working Group report. They themselves wrote about these issues. And these all are issues that "biased" framework developers had been talking for literal years before this report even saw the light of day:

- ARIA is broken. Needs a separate huge JS-only specification that is only now being slowly developed: https://w3c.github.io/webcomponents-cg/2022.html#cross-root-... See a larger description of the issue here: https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibil...

- CSS cascade and theming is broken. Needs several new specs to function, many of them JS-only, some already shipped, some still just being developed: https://w3c.github.io/webcomponents-cg/2022.html#constructab... and https://w3c.github.io/webcomponents-cg/2022.html#css-module-... and https://w3c.github.io/webcomponents-cg/2022.html#css-propert... and https://w3c.github.io/webcomponents-cg/2022.html#custom-css-... and ...

- Document selection is broken https://w3c.github.io/webcomponents-cg/2022.html#composed-se...

- Form participation is broken as it requires additional Javascript per each component to just participate in forms. Buttons inside shadow roots still cannot function as submit buttons: https://w3c.github.io/webcomponents-cg/2022.html#form-associ... and https://github.com/WICG/webcomponents/issues/814

And that's before we get into how they break many other things. Like the fact (that you labeled as biased) that using custom elements-aware APIs leads to a 30% drop in performance.

> `template` is just one building block. You can use it alongside others to do things frameworks can do, except... without a framework! What a concept, I know.

And end up making your own lib/framework in the process. Unless, of course, you want to pretend that all the issues above are nothing to talk about.

> That code is standard HTML with JS in data attributes that does get interpreted at runtime, but it's not an HTML-like DSL that gets parsed and compiled into JavaScript—it is HTML.

That's not JS, and it's not interpreted at runtime. It's painstakingly parsed with regexes, and then certain code is executed based on the result of that parsing.

Somehow "fake HTML" is a no-no, but fake JS? Yeah, go ahead.