5 ms·

IMO not the performance of DOM but the DOM itself is the biggest blocker to a good experience (user and dev)

by neoeldex 14y ago

coldtea 14y ago
In what sense? And what do you propose replaces it?
- lenkite 14y ago
  The DOM should have been a cursor based or perhaps a pull-based API. Everything being an in-memory tree was OK a decade ago but not today the node count in the millions across browser tabs. Dom funcions could have been generic ala C++ STL style for iteration restrictions
  - tantalor 14y ago
    Your comment surprises me. Maybe I don't undertand the DOM as well as you? I don't think a DOM tree is necessarily all in memory. For performance reasons you might cache the tree in memory, but that's not a requirement. You have to query it, right? Of course you can query for the same element multiple times, so it's not cursor-based. But the engine can generate the tree in response to user queries instead of storing the entire tree in memory. What do you mean by pull-based API?
    - vinayan3 14y ago
      [quote]I don't think a DOM tree is necessarily all in memory. For performance reasons you might cache the tree in memory, but that's not a requirement.[/quote] Yes it is not a requirement. What browser have you heard of storing in the tree in something else than memory? Imagine if the browser used a the disk to store parts of the tree.
    - lenkite 14y ago
      All the DOM implementations I know store the DOM tree in memory. Because DOM allows unrestricted, write access to any portion of the tree at any time, a disk cache would work well for some access patterns and fail for others. Yes, you can point out that browser implementations don't hold heavy weight DOM node _content_ in memory. (Usually just a pointer), but that doesn't remove the fundamental problem that the API has mostly restricted the choice of data-structures and limited the set of performance optimizations. I probably should have not used the term "pull based api", since that is just a fancy word for a cursor based api. Example could be SQL - we get a result set after a query exection and can iterate over the elements of the result set. SQL databases can be implemented in a wide variety of ways. (Though best practice has condensed this to a few). A browser api that had a query language to get different types of node cursors: read-only, appendable, live, etc and some well-defined, optimizable operations on such cursors would have allowed implementors to choose a wide variety of data-structures/algorithms for optimization.
  - comex 14y ago
    While it might be beneficial in some cases to save the DOM to disk (mostly because of reboots but also, yes, because of people opening hundreds of tabs), I doubt the API would make much difference - sane browsers would still keep any single page either on disk or in memory; they aren't that big.

IMO not the performance of DOM but the DOM itself is the biggest blocker to a good experience (user and dev)

coldtea 14y ago

In what sense? And what do you propose replaces it?

lenkite 14y ago
The DOM should have been a cursor based or perhaps a pull-based API. Everything being an in-memory tree was OK a decade ago but not today the node count in the millions across browser tabs. Dom funcions could have been generic ala C++ STL style for iteration restrictions
- tantalor 14y ago
  Your comment surprises me. Maybe I don't undertand the DOM as well as you? I don't think a DOM tree is necessarily all in memory. For performance reasons you might cache the tree in memory, but that's not a requirement. You have to query it, right? Of course you can query for the same element multiple times, so it's not cursor-based. But the engine can generate the tree in response to user queries instead of storing the entire tree in memory. What do you mean by pull-based API?
  - vinayan3 14y ago
    [quote]I don't think a DOM tree is necessarily all in memory. For performance reasons you might cache the tree in memory, but that's not a requirement.[/quote] Yes it is not a requirement. What browser have you heard of storing in the tree in something else than memory? Imagine if the browser used a the disk to store parts of the tree.
  - lenkite 14y ago
    All the DOM implementations I know store the DOM tree in memory. Because DOM allows unrestricted, write access to any portion of the tree at any time, a disk cache would work well for some access patterns and fail for others. Yes, you can point out that browser implementations don't hold heavy weight DOM node _content_ in memory. (Usually just a pointer), but that doesn't remove the fundamental problem that the API has mostly restricted the choice of data-structures and limited the set of performance optimizations. I probably should have not used the term "pull based api", since that is just a fancy word for a cursor based api. Example could be SQL - we get a result set after a query exection and can iterate over the elements of the result set. SQL databases can be implemented in a wide variety of ways. (Though best practice has condensed this to a few). A browser api that had a query language to get different types of node cursors: read-only, appendable, live, etc and some well-defined, optimizable operations on such cursors would have allowed implementors to choose a wide variety of data-structures/algorithms for optimization.
- comex 14y ago
  While it might be beneficial in some cases to save the DOM to disk (mostly because of reboots but also, yes, because of people opening hundreds of tabs), I doubt the API would make much difference - sane browsers would still keep any single page either on disk or in memory; they aren't that big.