Strictly speaking I agree with your first sentence, but clearly some languages/environments lend themselves more to the declarative style than others, and may or may not let you reap more of the benefits. (I also disagree that HTML has "failed" in almost any sense, but I don't think that's as interesting a discussion.)

Even so, web developers always had the option of sticking with an imperative approach to UI, like using element.innerHTML = '...', but overwhelmingly they preferred more declarative solutions like React. You could just as easily make the argument that the shortcomings of HTML had nothing to do with its "declarativeness", since that part was retained. I think a more likely explanation is that HTML couldn't be used to express the more complicated SPAs that people wanted to build, and regardless of what you think about those, JS-based solutions had to fill that need.

Yeah, HTML is declarative but the issue is that it’s such in an extremely simple way.

Loops, conditions, and variables/transclusions are table stakes, and without them pure HTML is just tedious data entry with extra tags.

> at some point web development skills shifted from it to mostly js.

[citation needed]

I mean, it looks like this if you look at HN (the comments, not the code) and similar places, but imo less in the wild.

You and I can both claim opposite things without citation, but we both know which is closer to reality based on what skill is on demand in the job market and what's LOGICALLY required to make web apps with such and such capabilities.

Declarative markup always evolves into a badly conceived programming language.

I think in one direction, i.e. templating, it works fine. Have data, have declarative syntax on how to iterate over data and generate fresh code from that.

The bidirectional case is already difficult where your changes in the generated source should backtranslate into changes in the supplied data.

But now also declaring interactions in the general case? This endeavour must surely fail, as there are so many possible interactions and so little design space without running into either the inner platform effect, where you're just replicating the host programming language (but with bugs), or Greenspun's tenth rule of programming, where you're accidentally building "an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp".

As an aside: I think a sweet spot is providing some UI elements and a framework for composing them, and then having a kind of DSL to low-code-connect them up in the DOM. You can abstract a lot of stuff away from the end user using, you know, code. And then the DSL can be nice for the interactions.

But we all know that interactivity is hard and complex and no way of writing it down, be that imperative, declarative, or whatnot, will take that away.

Edit: Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.

That's also been my experience, yet I've also gotten a spaghetti of a mess assembling the UI in regular code with loops and whatnots. Are there any other interesting options I could explore?

Declarative Code for initial state, with modifications done in regular code. Ideally data bindings for lists etc. (so the declarative part can state "this is a scrollable list view, each item looks like this, the content of these items is stored in variable Y", and any update to Y updates the list)

an imperative language that is DSL-friendly, such as kotlin and jetpack compose, or just functional languages, like ClojureScript's Reagent.

JSX is fine too. It's gotten a lot a bad rap because of React, but looping and conditions have never bothered me, despite people's complains about them.

I wouldn't go so far as to be bitter about it like you appear to be (based on past negative experience?) but yeah: the real question is why should one stick to markup when you're developing an app anyway?

Markup is for documents, and the "declarative" aspect of it is that it guarantees certain safety conditions (termination, injection safety, maintainability) without sending the author into a full Turing-complete programming environment and everything that goes with it, requiring experience, testing, choice over implementation alternatives, maintenance, debugging, and more laborious/expensive hosting with monitoring, etc. Markup is for ambitious tech-savvy end users/non-developers, and the high end of a non-Turing markup language operating purely at the level of syntactic manipulation, unlike htmx and TwinSpark, IMHO would be SGML, containing a finite state mechanism for context dependent styling or other processing and natural injection-free templating/macro expansion.

Now the web has pushed the limits of what can conceivably be called "documents" eg blogs with threaded comments, table of contents and other navigational idioms, etc. For these kind of "content apps" (supported by SGML still), there has always been a struggle between full Turing complete environments and increasingly idiosyncratic markup techniques.

That struggle is even more noticeable when looking at CSS. IMO, CSS has aggregated such an enormous complexity while most advanced use cases fall straight into "app" territory. That is, there is no justification for most recent CSS features when those features can only realistically be applied in the presence of JavaScript anyway, and thus should actually be implemented using JavaScript rather than bloating CSS. Case in point: the has() selector which doesn't materially enhance what you can do with HTML/CSS but clearly is introduced in support of components and modularity; ie requiring JS anyway, and with JS allowing much better modularity already anyway, is hence just redundant. Clearly, also calc() and custom properties are doubling what's already available.

I think my experiences are just very different from yours, but I found that declarative markup was the only sane way to represent visual UI elements. The classic example is using an imperative JS API like element.innerHTML = '...' vs React/Vue/etc, but the same could be said for newer UI APIs, like SwiftUI. I wouldn't call a mobile app's UI layout a document, but I still think the declarative nature of that API is a better fit than its imperative predecessor, UIKit.

Both of those examples have an "escape hatch", where you can drop into an imperative API if you need to, so I can see the argument for them not being a perfect abstraction of the underlying primitives, but that doesn't mean they're not useful and a good fit for the problems they're solving.

The has() selector definitely enhances what you can do with CSS. You can style elements differently based on what they contain.

which is the wrong way to do it. The source of truth for a state, that determines the style, should be... well a state, most likely in memory. It should not be a visual representation of that state (what element is rendered in side). When you change the latter, your conditional css will become broken unknowingly.

Even more to that point we only need HTML (in any flavor) because the browser says we do. The compile target is the DOM. The DOM is the goal, not HTML. If the environment were treated more like WASM where any language could compile to the target then it wouldn't matter what the source language is.

I imagine rendering a website to be much faster if the initial render is just streaming bytes from the network into the browser runtime, instead of parsing some string.

Having a standardized data representation is a good thing.

Does it really matter? The data representation could be markdown, yaml, JSON, SVG, or just about anything else and be equally effective. The browser already supports XML and HTML5 as wildly differing grammars that still compile to the same target.

html is not a DATA representation, it's not designed that way and it would actually be way more noisy if attemps to represent all the hidden states of the DOM.