3 ms·

I think there might be a difference in what we see what the HTML tree exactly is in this example. For me, the HTML is a declaration of structure. This can be pa

by Timon3 4y ago

I think there might be a difference in what we see what the HTML tree exactly is in this example. For me, the HTML is a declaration of structure. This can be passed to imperative code to build the DOM, but the tree itself (the HTML code, if you will) is a declarative representation of what I want to have in the end. It doesn't matter to me how this HTML is turned into a DOM. You could go through the HTML line by line and create the nodes. Or, if you'd think it could be faster, you might insert the children in reverse order at the correct position (e.g. start inserting the last element, then before that insert the second-to-last, and so on). All that matters is that the DOM in end behaves exactly like the one I specified. In the end, it's the same as with SQL. It doesn't matter what exact approach you take to get me what I want, as long as the end result is what I specified.

aatd86 4y ago
Yes, it's an abstraction over the implementation details. For html, the renderer still depends on the structure of the tree. Whether it starts from the bottom of the top doesn't matter. Because the renderer is an imperative function. But the declarative part is the tree itself and these declarative statements are not commutative is what I mean. You cannot insert to a node that doesn't exist.
- Timon3 4y ago
  I don't think what you write actually touches what I wrote. > For html, the renderer still depends on the structure of the tree. Of course! But it's not important whether you first insert node A at place X and node B at place Y, or the other way around. > Whether it starts from the bottom of the top doesn't matter. Because the renderer is an imperative function. See, that's the thing. What renderer are you talking about? I'm talking about the process of turning the declarative HTML tree into a DOM tree. > But the declarative part is the tree itself and these declarative statements are not commutative is what I mean. Well, no. You can't change a declarative structure and expect it to be the same. But why does that have any bearing on whether HTML trees are declarative? The tree is a declaration, and it doesn't matter how you turn this declaration into a DOM tree. It seems like you're expecting to be able to re-order the child nodes. That is not what declarativity is about. It means that it doesn't matter in which order you do the operations. The operation itself is defined by the node placed into the tree AND the resulting position of the node. You are right that you can't re-order the node declarations, but you can execute them in whatever order you want.
  - aatd86 4y ago
    Just to be sure, what do you mean by executing node declarations? Seems then to me that it is exactly the example of declaring variables. The order doesn't matter indeed. But for operations on these variables, i.e. function calls, there needs to be an ordering between variable declarations and functions calls (source order) except in a few cases maybe where a language uses hoisting. That's in the simple case where there are no side effects (but the parent comment takes this into account already). Of course, when someone transforms an html element into its corresponding DOM node, because this does not depend on shared state, these operations can be commuted but that's not what declarativity is about. Declarative is: cook me a chicken. As opposed to imperative i.e.: turn the oven on, wash and season the chicken, put it on the oven, wait 1hour, get if off the oven and serve it. You can buy the chicken or the oven whichever first. Still need to follow the steps in order. I'm still not quite sure I understand what you meant exactly :/
    - galaxyLogic 4y ago
      I'm still a bit confused about the distinction. A HTML-page would be a declarative definition of a DOM-structure, right? It just declares what I want to see in the browser, it does not describe how the browser-engine shall render the HTML given to show it to my readers. Good so far, declarative. But what if the web-page shows a cookbook recipe whose steps are elements in the DOM-structure of the page? Such a page then procedurally describes how to cook a cake, right? Is that recipe then declarative or procedural?
      - aatd86 4y ago
        The html code is a declarative definition of a webpage. The internal representation as a DOM tree is just the imperative implementation on the backend. A recipe is a description of the steps to the end result. So it's imperative. Here instead of DOM nodes, you probably have utensils and ingredients on which you apply operations (grab, heat, pour oil etc...) The end goal is not the description of the recipe itself. It's the meal that you get once you have followed the steps to completion.

by Timon3 4y ago

aatd86 4y ago

Yes, it's an abstraction over the implementation details. For html, the renderer still depends on the structure of the tree. Whether it starts from the bottom of the top doesn't matter. Because the renderer is an imperative function. But the declarative part is the tree itself and these declarative statements are not commutative is what I mean. You cannot insert to a node that doesn't exist.

Timon3 4y ago
I don't think what you write actually touches what I wrote. > For html, the renderer still depends on the structure of the tree. Of course! But it's not important whether you first insert node A at place X and node B at place Y, or the other way around. > Whether it starts from the bottom of the top doesn't matter. Because the renderer is an imperative function. See, that's the thing. What renderer are you talking about? I'm talking about the process of turning the declarative HTML tree into a DOM tree. > But the declarative part is the tree itself and these declarative statements are not commutative is what I mean. Well, no. You can't change a declarative structure and expect it to be the same. But why does that have any bearing on whether HTML trees are declarative? The tree is a declaration, and it doesn't matter how you turn this declaration into a DOM tree. It seems like you're expecting to be able to re-order the child nodes. That is not what declarativity is about. It means that it doesn't matter in which order you do the operations. The operation itself is defined by the node placed into the tree AND the resulting position of the node. You are right that you can't re-order the node declarations, but you can execute them in whatever order you want.
- aatd86 4y ago
  Just to be sure, what do you mean by executing node declarations? Seems then to me that it is exactly the example of declaring variables. The order doesn't matter indeed. But for operations on these variables, i.e. function calls, there needs to be an ordering between variable declarations and functions calls (source order) except in a few cases maybe where a language uses hoisting. That's in the simple case where there are no side effects (but the parent comment takes this into account already). Of course, when someone transforms an html element into its corresponding DOM node, because this does not depend on shared state, these operations can be commuted but that's not what declarativity is about. Declarative is: cook me a chicken. As opposed to imperative i.e.: turn the oven on, wash and season the chicken, put it on the oven, wait 1hour, get if off the oven and serve it. You can buy the chicken or the oven whichever first. Still need to follow the steps in order. I'm still not quite sure I understand what you meant exactly :/
  - galaxyLogic 4y ago
    I'm still a bit confused about the distinction. A HTML-page would be a declarative definition of a DOM-structure, right? It just declares what I want to see in the browser, it does not describe how the browser-engine shall render the HTML given to show it to my readers. Good so far, declarative. But what if the web-page shows a cookbook recipe whose steps are elements in the DOM-structure of the page? Such a page then procedurally describes how to cook a cake, right? Is that recipe then declarative or procedural?
    - aatd86 4y ago
      The html code is a declarative definition of a webpage. The internal representation as a DOM tree is just the imperative implementation on the backend. A recipe is a description of the steps to the end result. So it's imperative. Here instead of DOM nodes, you probably have utensils and ingredients on which you apply operations (grab, heat, pour oil etc...) The end goal is not the description of the recipe itself. It's the meal that you get once you have followed the steps to completion.