> backed by C++ (née Rust) "née" means "originally called" (usually someone's maiden name). I don't think C++ used to be called Rust.
Yeah, that stuck out to me, too. I'm still a bit fuzzy on how to interpret the author's original intent.
Faster DOM
21–30 of 54 posts
Re: Faster DOM
#22I'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
Whoa, that's pretty cool. Hadn't heard of it, but sure want to play with it.
Re: Faster DOM
#23> 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…
fastdom might be of interest – it batches read and write operations into separate queues and runs them using requestAnimationFrame:
Re: Faster DOM
#24We all know that Element.innerHtml = "..." can be significantly faster than set of individual DOM mutating calls. Element.innerHtml = ... gets executed as single transaction - relayout happens only once, at the end of it. Yet there is no overhead on JS-native bridging and function calls in JS in general. But the need of "transactioned" DOM updates is not just about the speed. There are other cases when you need this.…
"We all know that Element.innerHtml = "..." can be significantly faster than set of individual DOM mutating calls" Not necessarily: http://stackoverflow.com/questions/8461851/what-is-better-ap... That's an old post, but even then the conventional wisdom didn't hold up.
"Not necessarily".
Of course there are situations when these two methods of DOM update are on par.
But in any case I agree with one of answers there:
"If you don't mind the fact that innerHTML is a bit limiting (only total replacement of DOM sub-tree rooted at target element) and you don't risk a vulnerability through injecting user-supplied content, use that. Otherwise, go with DOM."
When you do for example this: element.setAttribute("a","b"); browser
1. drops all resolved CSS rules on element, its siblings, its parent and all children. Just in case you have CSS rules like:
element[a="b"] > span { display:none }
And when you do element.appendNode(node):
it does the same as above + plus ensures consistency of HTML DOM ( cannot contain s for example).
If you have multiple calls like these then all steps above need to be done for each of them. Engines can optimize such cases but not that much in some cases.
While browser do element.innerHtml it does each step strictly once: build consistent DOM, resolve styles, build rendering tree and mark window [area] as needed painting - request painting.
Re: Faster DOM
#25We all know that Element.innerHtml = "..." can be significantly faster than set of individual DOM mutating calls. Element.innerHtml = ... gets executed as single transaction - relayout happens only once, at the end of it. Yet there is no overhead on JS-native bridging and function calls in JS in general. But the need of "transactioned" DOM updates is not just about the speed. There are other cases when you need this.…
"We all know that Element.innerHtml = "..." can be significantly faster than set of individual DOM mutating calls" Not necessarily: http://stackoverflow.com/questions/8461851/what-is-better-ap... That's an old post, but even then the conventional wisdom didn't hold up.
Seems to me that page supports the claim that .innerHTML can be faster than individual DOM mutating calls.
Re: Faster DOM
#26I'm curious about the source of the slowness of the IDL operations. Is it specific to the DOM, or is he referring to overhead that exists for any bindings between JS and C++?
IDL operations are not particularly slow. Last I measured, a call from JS into C++ is between 10 and 40 CPU instructions of fixed overhead depending on the exact thing being called (method vs getter vs setter; they have slightly different costs) and the browser involved. At least once you get into the top JIT tier; baseline jit and interpreter can involve more overhead, obviously. There's additional cost for dealing…
> IDL operations are not particularly slow. Last I measured, a call from JS into C++ is between 10 and 40 CPU instructions of fixed overhead
To put that in perspective, that's the same number of instructions as objc_msgSend, which every Objective-C method call in native iOS or Mac apps goes through [1]. "The DOM is slow compared to native" is a common meme, but it's not that simple.
Re: Faster DOM
#27I'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
Thus it can be estimated that you can get, on average, a 45% speed improvement?!
I'm going to try and bench this on a mobile webview and see what happens.
Re: Faster DOM
#28Earlier quoted context omitted.
That assumes that all the changes are grouped under the same part of the tree...
Sure. If you have a ton of potentially layout-thrashing changes, just clone your page's highest wrapper node. Then make your changes and replace the node. I haven't needed it, or tested it for performance, but it's clearly doable. // Example; untested pseudo-code var fragment = document.createDocumentFragment(), wrapper = document.getElementById('wrapper'); fragment.appendChild(wrapper.cloneNode(true)); // update you…
You also potentially lose things like focus, input text, and selection on elements that otherwise didn't need to be replaced. I'd wager that re-creating all of that would add a discernible performance cost.
Re: Faster DOM
#29I was playing with the idea of using JS objects as a template engine: http://m1el.github.io/jsonht.htm, and I'm pretty happy with it.
I think DOM is pretty damn fast in modern browsers. `innerHTML` can be slower than creating elements from a JS object!
Here's the script I'm using for timing: https://gist.github.com/m1el/b28625b3b9261f0fab819e866133e49...
My results in Chrome are: dom: 2663.580ms, innerHTML: 10999.449ms
Re: Faster DOM
#30> backed by C++ (née Rust) "née" means "originally called" (usually someone's maiden name). I don't think C++ used to be called Rust.
Yeah, that stuck out to me, too. I'm still a bit fuzzy on how to interpret the author's original intent.
I think he meant "C++ (now Rust)", referring to the Servo browser using Rust - https://servo.org/