> The entire idea of writing fake HTML that gets parsed, compiled, and interpreted in JavaScript to manipulate the DOM at runtime is wrong.

Because there's nothing in the web standards to do it otherwise.

> The concept of a virtual DOM, diffing, reconciliation, and a bunch of related nonsense, is wrong.

Of the frameworks I mentioned none use virtual DOM or diffing. They have all moved to a much more efficient way that is, guess what, on a way to become a native browser standard: https://github.com/tc39/proposal-signals

> The insanity of an entire ecosystem of tools built around solving client-side state management.

Any time you have a dynamic UI, you have state management. I wish the web remained static, but that ship has sailed long ago. And there's nothing in web standards that helps with state management.

> It just means that the field has become dominated by influencer developers, to the point that junior developers entering the field are not aware of other ways of building web applications.

It's strange how you completely dismissed Solid, Vue, and Svelte which all offer a different way to build web apps when compared to React, for example.

> JavaScript in web browsers is a stable, modern language.

You need more than just a language. You also need libraries and actual useful functionality exposed by the browsers.

Literally the whole reason so many libraries and frameworks have popped over the years, is because no one wants to spend time writing hundreds of lines of code just to properly set up and change some DOM element. And the reason very few libs/frameworks (even newcomers) use "the amazing new features in the browsers" is because these features have a list of features issues and caveats a mile long. Here's just one single example: https://x.com/Rich_Harris/status/1841467510194843982

> HTML has received numerous transformative updates over the years, such as the `template` element we're discussing here.

And what, pray tell, does template give you? On its own it's useless. You need some JS to manipulate it, at least.

> but because it takes a first principles approach and rejects building on top of the existing pile of abstractions.

Didn't you just say this: "The entire idea of writing fake HTML that gets parsed, compiled, and interpreted in JavaScript to manipulate the DOM at runtime is wrong. "?

What do you think Datastar is doing if not literally the same thing. How do you think this works:

    <div data-signals="{counter: 0, message: 'Hello World', allChanges: [], counterChanges: []}">
    <div class="actions">
        <button data-on-click="$message = `Updated: ${performance.now().toFixed(2)}`">
            Update Message
        </button>
        <button data-on-click="$counter++">
            Increment Counter
        </button>
        <button
            class="error"
            data-on-click="$allChanges.length = 0; $counterChanges.length = 0"
        >
            Clear All Changes
        </button>
    </div>
    <div>
        <h3>Current Values</h3>
        <p>Counter: <span data-text="$counter"></span></p>
        <p>Message: <span data-text="$message"></span></p>
    </div>
    <div
        data-on-signal-patch="$counterChanges.push(patch)"
        data-on-signal-patch-filter="{include: /^counter$/}"
    >
        <h3>Counter Changes Only</h3>
        <pre data-json-signals__terse="{include: /^counterChanges/}"></pre>
    </div>
    <div
        data-on-signal-patch="$allChanges.push(patch)"
        data-on-signal-patch-filter="{exclude: /allChanges|counterChanges/}"
    >
        <h3>All Signal Changes</h3>
        <pre data-json-signals__terse="{include: /^allChanges/}"></pre>
    </div>
  </div>

> Because there's nothing in the web standards to do it otherwise.

Sure there is. We've been manipulating the DOM with JavaScript since the dawn of the web, which later projects like jQuery made more ergonomic. There are a bunch of JS libraries that simplify working with the DOM without resorting to writing fake HTML in JavaScript.

> Of the frameworks I mentioned none use virtual DOM or diffing. They have all moved to a much more efficient way

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

We expect these trend-chasers to define the future of the web? Give me a break.

> Any time you have a dynamic UI, you have state management.

That's true, but state management became such a big problem because of the trend of SPAs and fat clients. A lot of this complexity can be mitigated by relying on the server more. At some point, developers became obsessed about not making a traditional HTTP request that would do a full page refresh, and libraries and frameworks sprung to resolve issues that were largely self-imposed.

Add to that the ever-evolving nature of the JS ecosystem, and developers constantly one-upping each other and chasing trends, which boils down to the insanity I'm talking about.

> It's strange how you completely dismissed Solid, Vue, and Svelte which all offer a different way to build web apps when compared to React, for example.

I checked out from keeping track of frontend frameworks years ago. FWIW, I did try early versions of Svelte, and enjoyed the DX, but at the end of the day, the apparent simplicity was a facade that hid insane amounts of black magic in the background to make all of it work. These days with SvelteKit and the changes in Svelte 5, it feels like just another React clone.

I have recent experience with Vue, and it is the epitome of everything wrong with modern web development. I just didn't have the time and energy to address it specifically.

Again, my issue is not with specific frameworks, but with the whole concept that developers need such behemoth frameworks to build web sites.

> Literally the whole reason so many libraries and frameworks have popped over the years, is because no one wants to spend time writing hundreds of lines of code just to properly set up and change some DOM element.

That's a strawman. As you can see in this very thread, there are examples of people building advanced interactive web sites without much boilerplate or abstractions. For the remaining rough edges that you may not want to deal with yourself, there are libraries and lightweight frameworks you can choose from. You're not forced to use a monolithic framework. Frameworks are a popular choice because they're trendy, but there are plenty of much simpler alternatives.

> Here's just one single example

Ah, I'm sure authors of popular frontend frameworks are fair and unbiased...

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.

> And what, pray tell, does template give you? On its own it's useless. You need some JS to manipulate it, at least.

`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.

> What do you think Datastar is doing if not literally the same thing.

It's not the same thing. 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.

To be clear: I haven't used Datastar, nor dug into its internals. I'm personally not a fan of abusing HTML attributes with JS logic like that, and I prefer how old school frameworks like Backbone and Knockout handle this. My frustrating experience with Vue was partly what motivated me to think about and come up with my own approach, which I linked to above, if you're curious.