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

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

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

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.

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?

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.

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