[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.)

[mbivert]

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

I haven't made a case for it to be a requirement, but rather for direct access to be 1) trivial to achieve 2) more convenient than all of the (Vanilla JS) alternatives that I know of (attributes-based solutions).

> JSX and React’s refs

From a quick glance, I'm not sure this brings anything more than keeping a handful of node pointers around. But it should, at least in some ways, be better that attribute-based solutions.

[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).