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.