5 ms·

"Because DOM is slow" DOM is not slow, in principle. What makes updates slow is the fact that each mutating DOM function must left the DOM in consistent state

"Because DOM is slow" DOM is not slow, in principle. What makes updates slow is the fact that each mutating DOM function must left the DOM in consistent state - rendering trees invalidated, etc. This creates significant overhead on massive updates. But: element.innerHTML = "new content"; is significantly faster than sequence of appendNode & Co. because element.innerHTML mutation is transactional. Browsers do not need to notify observers on each element parsed - only whole subtree at the end. I have tests of different methods of DOM updates in Sciter (https://sciter.com https://sciter.com) see: https://github.com/c-smile/sciter-sdk/blob/master/samples/tests/test-scrollable-table.htm#L114 https://github.com/c-smile/sciter-sdk/blob/master/samples/te... The test shows that these two methods: element.html = "new content"; and element.content( vector-of-vDOM-nodes ); are significantly faster than anything else as both methods are transactional.

raphlinus 6y ago
What you're saying seems to be consistent with what I'm saying. Web-browser standard DOM is slow, for exactly the reasons you state. Adding an additional tree mutation API, not supported by any web browser, can obviously be a lot faster, and as you say, a good way to make that faster is to group the mutation into a transaction, rather than effectively have one transaction for each appendChild and setAttribute call. What you've done is a pretty small change to the DOM and generally compatible with it. What I've done in Crochet is a more radical rework, but certainly with some of the same general principles (my `Mutation` datatype is also a transaction). I should also point out that my tree mutation is a bit more limited, as it can't do general movement of subtrees, only sibling movement within the same parent (and, in the current prototype, no swapping, only order-preserving, which includes insert, delete, and update). If some compatibility with browser DOM is a goal, then your approach is appealing. I'm not pursuing it in my prototype because I'm also holding overall system simplicity as a whole. But in any case, I agree that people should be aware of what Sciter does; it's an impressive system.
- c-smile 6y ago
  We just need to add one method to Web API: document.mutate(function(mutator) { mutator.changeAttributes(el,{...}); mutator.appendNodes(el,...); ... }); The mutate will do transactional update as fast as possible.
  - deleted 6y ago
    [deleted]

raphlinus 6y ago

What you're saying seems to be consistent with what I'm saying. Web-browser standard DOM is slow, for exactly the reasons you state. Adding an additional tree mutation API, not supported by any web browser, can obviously be a lot faster, and as you say, a good way to make that faster is to group the mutation into a transaction, rather than effectively have one transaction for each appendChild and setAttribute call. What you've done is a pretty small change to the DOM and generally compatible with it. What I've done in Crochet is a more radical rework, but certainly with some of the same general principles (my `Mutation` datatype is also a transaction). I should also point out that my tree mutation is a bit more limited, as it can't do general movement of subtrees, only sibling movement within the same parent (and, in the current prototype, no swapping, only order-preserving, which includes insert, delete, and update). If some compatibility with browser DOM is a goal, then your approach is appealing. I'm not pursuing it in my prototype because I'm also holding overall system simplicity as a whole. But in any case, I agree that people should be aware of what Sciter does; it's an impressive system.

c-smile 6y ago
We just need to add one method to Web API: document.mutate(function(mutator) { mutator.changeAttributes(el,{...}); mutator.appendNodes(el,...); ... }); The mutate will do transactional update as fast as possible.
- deleted 6y ago
  [deleted]