Faster DOM
annevankesteren.nl
annevankesteren.nl
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.
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...
// Example; untested pseudo-code
var fragment = document.createDocumentFragment(),
wrapper = document.getElementById('wrapper');
fragment.appendChild(wrapper.cloneNode(true));
// update your fragment
// update the page
document.body.replaceChild(fragment, wrapper);
http://www.jaedworks.com/hypercard/HT-Masters/visual-effects...
The Web developer (or library author). He is talking about an API.
But the need of "transactioned" DOM updates is not just about the speed. There are other cases when you need this. In particular:
1. Massive DOM updates (that's your case), can be done with something like: Element.update( function mutator(ctx) ). While executing the mutator callback Element.update() locks/delays any screen/layout updates.
2. That Element.update( function mutator(ctx) ) can be used with enhanced transitions. Consider something like transition: blend linear 400ms; in CSS. While executing the update browser makes snapshots of initial and final DOM states and does blending of these two states captured into bitmaps.
3. transactioned update of contenteditable. In this case Element.update() groups all changes made by the mutator into single undoable operation. This is a big deal actually in WYSIWYG online editors.
There are other cases of course, but these three functionalities are what I've implemented in my Sciter Engine ( http://sciter.com ) already - proven to be useful.
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.
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 (<select> cannot contain <div>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.
Browsers optimize this, too - they try hard to keep up metadata structures that tell them whether they need to invalidate styling or not. (This is why mutating the stylesheet is so expensive - browsers have to freshly rebuild the supporting data structures. They could optimize that too, but it's a lot of effort for a rare case.)
So if there's no rules mentioning an [a] attribute in the page, el.setAttribute("a", ...) will generally not do anything.
(One of the benefits of shadow DOM is that the shadow trees are scoped away from the main tree and each other, so you can have more expensive rules in them without making the rest of the page slow. Yay for componentization!)
That's true in general but there are exceptions as usual. Changing @href may trigger not only [href] rules but also :link ones. And :link rules are always present at least in default style sheet. @value triggers :empty. And so on.
But if someone in some library in galaxy far far away (small library used by your application) will add that [a] rule then magically you will get a spike on innocuous el.setAttribute("a", ...) calls in your code.
That's one of points of having transactional yet explicit DOM update mechanism. We have jQuery, Angulars, React, Ember, Vue, (you name it) that definitely need such thing. Sites/webapps that do not use one of those are quite rare these days.
It diff's the DOM instead of a VDOM
I'm going to try and bench this on a mobile webview and see what happens.
After looking into it further, morphdom appears to be a solid alternative to virtual DOMs. Seems worth having around for that reason alone, especially if it were to improve with time, or become used by other tools.
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
Isn't that the same as (among several other things) React's JSX?
I don't think people realize that all JSX is, is a way to elegantly write out something that transpiles down to a pure object representation of the DOM.
JSX and React have a few quirks where React means it's not quite a pure object, but the React devs are working on removing those.
1) I think the idea about such an API encouraging good practice is very much correct, in the sense that it makes it harder to interleave DOM modification and layout flushes. That might make it worth doing on its own.
2) DOM APIs are not necessarily _that_ cheap in and of themselves (though they are compared to layout flushes). Setting the various dirty flags can actually take a while, because in practice just marking everything dirty on DOM mutation is too expensive, so in practice UAs limit the dirty marking to varying degrees. This trades off time inside the DOM API call (figuring out what needs to be dirtied) for a faster relayout later. There is some unpredictability across browser engines in terms of which APIs mark what dirty and how long it takes them to figure that out.
3) The IDL cost is pretty small in modern browsers, if we mean the fixed overhead of going from JS to C++ and verifying things like the "this" value being of the right type. When I say "pretty small", I mean order of 10-40 machine instructions at the most. On a desktop machine, that means the overhead of a thousand DOM API calls is no more than 13 microseconds. On mobile, it's going to be somewhat slower (lower clocks, if nothing else, smaller caches, etc). Measurement would obviously be useful.
There is the non-fixed overhead of dealing with the arguments (e.g. going from whatever string representation your JS impl uses to whatever representation your layout engine uses, interning strings, copying strings, ensuring that provided objects, if any, are the right type, etc). This may not change much between the two approaches, obviously, since all the strings that cross the boundary still need to cross it in the end. There will be a bit less work in terms of object arguments, sort of. But....
4) The cost of dealing with a JS object and getting properties off it is _huge_. Last I checked in Gecko a JS_GetProperty equivalent will take 3x as long as a call from JS into C++. And it's much worse than that in Chrome. Most of the tricks JITs use to optimize stuff go out the window with this sort of access and you end up taking the slowest slow paths in the JS engine. What this means in practice is that foo.bar("x", "y", "z") will generally be much faster than foo.bar({arg1: "x", arg2: "y", arg3: "z"}). This means that the obvious encoding of the new DOM as some sort of JS object graph that then gets reified is actually likely to be much slower than a bunch of DOM calls right now. Now it's possible that we could have a translation layer, written in JS such that JITs can do their magic, that desugars such an object graph into DOM API calls. But then that can be done as a library just as well as it can be done in browsers. Of course if we come up with some other way of communicating the information then we can possibly make this more efficient at the expense of it being super-ugly and totally unnatural to JS developers. Or UAs could do some sort of heroics to make calling from C++ to JS faster or something....
5) If we do provide a single big blob of instructions to the engine, it would be ideal if processing of that blob were side-effect free. Or at least if it were guaranteed that processing it cannot mutate the blob. That would simplify both specification and implementation (in the sense of not having to spell out a specific processing algorithm, allowing parallelized implementation, etc). Instructions as object graph obviously fail hard here.
Summary: I think this API could help with the silly cases by preventing layout interleaving. I don't think this API would make the non-silly cases any faster and might well make them slower or uglier or both. I think that libraries can already experiment with offering this sort of API, desugaring it to existing DOM manipulation, and see what the performance looks like and whether there is uptake.
There's additional cost for dealing with the call arguments, too; this varies widely by type of argument (e.g. an options object is clearly more expensive to deal with than a boolean, or even than a list of arguments containing the same information as the options object) and somewhat less widely by browsers.
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.
However to be fair the point of React, vdom, mithril etc. is to allow the developers to write a mapping from state to view and let the mutations be calculated automatically. They claim it's easier to just write the logic of the mapping instead of all possible transitions. I don't buy it, but it has grown to a huge community.
On that note, I just stumbled on an old framework that's been out of development since 2012 called Blossom. It looks like it uses Canvas instead of the DOM. Does anybody have any history with it?
Or do developers have to live with the uncertainty that simple updates may have a higher computational complexity?
I know Chrome has an implementation that I think is still moving thru the shipping cycle, and the other browsers are working on theirs iirc.
There were times before there was a DOM (you might not have been born yet) and there can be times after DOM :)
"née" means "originally called" (usually someone's maiden name). I don't think C++ used to be called Rust.