Faster DOM
annevankesteren.nl
Faster DOM
1–10 of 54 posts
Re: Faster DOM
#2I think this is a natural evolution of where DOM has been headed. Batching requests is entirely within the spirit of the original DOM.
Re: Faster DOM
#3I'll leave this module here for those of you how haven't heard of it. https://github.com/patrick-steele-idem/morphdom
It diff's the DOM instead of a VDOM
Re: Faster DOM
#4> That way, you only do the IDL-dance once and the browser then manipulates the tree in C++ with the many operations you fed it.
As a beginning web developer, I remember being surprised that there was no way for me to group DOM manipulations into SQL-like transactions, or even an equivalent to HyperCard's lockScreen.
I'm finding it a little tough to tell whether the author is talking about putting the browser or the web developer in control of grouping DOM updates.
Re: Faster DOM
#5[deleted]
Re: Faster DOM
#6> That way, you only do the IDL-dance once and the browser then manipulates the tree in C++ with the many operations you fed it. As a beginning web developer, I remember being surprised that there was no way for me to group DOM manipulations into SQL-like transactions, or even an equivalent to HyperCard's lockScreen. I'm finding it a little tough to tell whether the author is talking about putting the browser or the…
The more I learn about HyperCard, the more amazed I am about how nifty piece of technology it was. Too bad I haven't been fortunate enough to ever use it.
http://www.jaedworks.com/hypercard/HT-Masters/visual-effects...
Re: Faster DOM
#7> That way, you only do the IDL-dance once and the browser then manipulates the tree in C++ with the many operations you fed it. As a beginning web developer, I remember being surprised that there was no way for me to group DOM manipulations into SQL-like transactions, or even an equivalent to HyperCard's lockScreen. I'm finding it a little tough to tell whether the author is talking about putting the browser or the…
You actually can, via (ab)using requestAnimationFrame. It's been a while since I did front-end development, but back in the day (...okay, 2014 ish) we'd batch DOM reads and writes, run through them the next time the frame was painted, and avoid multiple redraws. It was rather cumbersome, especially since reads had to be asynchronous, but it was fast.
Re: Faster DOM
#8> That way, you only do the IDL-dance once and the browser then manipulates the tree in C++ with the many operations you fed it. As a beginning web developer, I remember being surprised that there was no way for me to group DOM manipulations into SQL-like transactions, or even an equivalent to HyperCard's lockScreen. I'm finding it a little tough to tell whether the author is talking about putting the browser or the…
> I'm finding it a little tough to tell whether the author is talking about putting the browser or the web developer in control of grouping DOM updates.
The Web developer (or library author). He is talking about an API.
Re: Faster DOM
#9> That way, you only do the IDL-dance once and the browser then manipulates the tree in C++ with the many operations you fed it. As a beginning web developer, I remember being surprised that there was no way for me to group DOM manipulations into SQL-like transactions, or even an equivalent to HyperCard's lockScreen. I'm finding it a little tough to tell whether the author is talking about putting the browser or the…
> [...] I remember being surprised that there was no way for me to group DOM manipulations into SQL-like transactions [...]
There is a way to group DOM manipulations: a DocumentFragment[0]. If you have a wrapper, you can easily use
parent.replaceChild(fragment, wrapper); // [1]
I've used similar techniques to make applications that render efficiently.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra... [1]: https://developer.mozilla.org/en-US/docs/Web/API/Node/replac...
Re: Faster DOM
#10> That way, you only do the IDL-dance once and the browser then manipulates the tree in C++ with the many operations you fed it. As a beginning web developer, I remember being surprised that there was no way for me to group DOM manipulations into SQL-like transactions, or even an equivalent to HyperCard's lockScreen. I'm finding it a little tough to tell whether the author is talking about putting the browser or the…
> [...] I remember being surprised that there was no way for me to group DOM manipulations into SQL-like transactions [...] There is a way to group DOM manipulations: a DocumentFragment[0]. If you have a wrapper, you can easily use parent.replaceChild(fragment, wrapper); // [1] So long as you start with your fragment having a new copy of that wrapper—the entire node and its children will be replaced in 1 operation. T…
That assumes that all the changes are grouped under the same part of the tree...