> You wouldn't be able to modify something that has not be rendered yet for instance.
What does rendered mean? In the browser window? Why not, you can certainly modify that. If you mean not rendered in the HTML then we are now talking about two different things, because my answer was meant for when there is an existing HTMl tree already.
Rendering meaning turning the html elements into dom nodes first before painting.
But that's a red herring.
The point in that the sequence, render-modify cannot be turned into modify-render.
This is not commutative.
Now, render(a, b, c) where a, b, c are html nodes is a slightly different story because we consider only one function.
Here, your claim is that since it is basically equivalent to render(a) + render(b) + render(c) then it's commutable.
Well, it depends at which granularity one looks at it (subtrees...). And as the original comment mentions, in the general case, it's only true if there is no side-effects.
Well, now we are really down to semantics. I don't think there is any guarantees about rendering whatsoever, are there?
In other words, if you, currently, put some html elements (whatever that means, maybe using innerHTML or so) is there any guarantee how exactly they are rendered, meaning, how they are turned into dom nodes?
Because of not, then render(a, b, c) is in fact equivalent to render(a) + render(b) + render(c).
If this process can be controlled, then obviously "inserting" an html element (structure) must be able to describe that process to make it declarative.
You wouldn't be able to modify something that has not be rendered yet for instance.
Render itself is declarative perhaps, but that's the meta level.
Render is imperative in terms of rendering a declarative tree.