3 ms·

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

• 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.
        • galaxyLogic 4y ago
          But my end-goal could be finding the recipe, maybe I am a recipe collector.