[strogonoff]

By being imperative, you describe how to get to the state you desire. By being declarative, you split the concerns of “how it should be” and “how to get there”, which doesn’t come without downsides (abstractions are leaky) but does have its benefits: the latter logic you’d maintain in one place, and the former is usually easier to reason about.

[TeMPOraL]

I'm not talking about imperative vs. declarative, but about working at the level of language you're dealing with. Using string concatenation for building HTML or SQL is like doing arithmetic like "123" + "456" = "123456" -- you're using the wrong addition operator.

[strogonoff]

Describing the state by design implies not working at the same level as getting to that state, though—I’m not sure if there is some subtlety I’m missing—and to me there seem to be obvious benefits (and downsides, as mentioned above) to not explicitly manipulating DOM where I want to just describe how a page should be structured.

[mbivert]

Perhaps this can help to fix the ideas: here's how you could create the HTML by manipulating the DOM (the code indentation mimics the HTML indentation):

   let p = document.createElement("span");
  
    let b = document.createElement("button");
    b.innerText = btnText;
    if (btnClass) b.classList.add(btnClass);
  
    let m = document.createElement("span");
    m.style.display = "none";
    m.classList.add(modalClass);
  
     let q = document.createElement("span");
     q.classList.add(modalContentClass);
  
      let c = document.createElement("button");
      c.innerText = "×";
      c.classList.add(modalBtnCloseClass);
  
      // r is an "external" HTMLElement
      r.classList.add(modalContentClass);
  
     q.append(c, r);
  
    m.appendChild(q);
  
   p.append(b, m);

It's not that different from writing the HTML (with or without a template). But IMO the great thing here is that, at the end of that chunk of code, you've got pointers to every node of interest. You can then register handlers, target arbitrary nodes in such handlers, without having to navigate through the HTML (e.g. by setting ``id`` or other attributes to help identify them, or by relying on a static HTML structure).

And as the parent points, this should prevent some amount of unexpected HTML injection.

There's still a separation between the view and the page structure.

[strogonoff]

I know how to manipulate DOM. You are not invalidating my point. This way involves a lot more mental overhead any time you need to define a structure for a page, compared to a declarative way of writing HTML as a string and delegating DOM manipulation to separate imperative logic (or indeed browser’s native parser).

[mbivert]

> This way involves a lot more mental overhead any time you need to define a structure for a page,

How so?

The "imperative logic" of the previous example is parametrized by a few node pointers. Assuming I understand your approach correctly, your separate imperative logic would still need to be parametrized by some node pointers as well.

Except because you wouldn't have direct access to them, you'd need to use class names or IDs to retrieve them. Hence you would need an extra layer to join the two parts that you've separated, which in my opinion is more mental overhead: the management of those attribute comes at a cost (e.g. naming conflict, more class names to remember, confusion between class names).

Perhaps a more concrete example (bits of code) of your approach might help make your point clearer.

[strogonoff]

Why do you assume there is a requirement to access nodes directly, and why would that be a typical requirement?

(There are ways to achieve that more declaratively than by building the entire DOM imperatively, JSX and React’s refs is one approach, but I wonder why you assume direct access is always needed in the first place.)