[strogonoff]

Well, I have outlined why declarativity is good, so as far as I’m concerned the choice to go imperative and abandon the benefits of declarativity in order to make access to nodes trivial should probably be accompanied by understanding of why that access would be needed in the first place.

[mbivert]

To perform any action on the DOM, you need access to the nodes: registering handlers, manually triggering events, setting/getting values, rebuilding them, etc.

I'd encourage you to toy with a concrete example, in case you (or I) are missing a subtle point; the previous piece of code is the "view" for a modal "component" which hosts an external HTMLElement (r). See how you'd implement it with both approaches.

With both, the "view" and the logic are still separated. The view is merely encoded differently.

[strogonoff]

> To perform any action on the DOM, you need access to the nodes

Not really. With declarative approach you can just give HTML to the browser (or some templater) and get your page completely laid out without having any access to any nodes.

In fact, declarative approach does also allow to connect handlers with ease (onclick and similar attributes are very much a thing).

Using onclick handlers doesn’t scale well if we are talking about Web apps with complex GUIs, but then the naive imperative approach of createElement scales potentially even worse. The approaches that do scale tend to favour declarative approach with isolated imperative logic (such as in event handlers).

[mbivert]

> In fact, declarative approach does also allow to connect handlers with ease (onclick and similar attributes are very much a thing).

Yup, but it's more limited: consider the modal: you can't — without relying on attributes, or worse, the page's structure — hide the modal when clicking on the little cross, in an onclick attribute.

> The approaches that do scale tend to favour declarative approach with isolated imperative logic

I think it's key regardless of the approach: you want to break down your pages in pieces (e.g. "components"), have them eventually communicate with each others, while keeping those communications as local as possible.

Very much in the same way we design programs over small units (procedure, function, object, etc.).

[strogonoff]

Modals are generally involved in a full-blown Web app. For an average post or article, you don’t need node handles, pure declarative HTML is enough. At the same time, implementing a full-blown app imperatively directly with createElement would result in an unmaintainable mess. In other words, there seem to be very few use cases where such approach is justified.

[mbivert]

> For an average post or article, you don’t need node handles

It goes without saying...

> At the same time, implementing a full-blown app imperatively directly with createElement would result in an unmaintainable mess

I disagree, and I've built non-trivial UIs with createElement; a key is to have the discipline to keep the "components" well-isolated.