Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faster DOM

annevankesteren.nl

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Faster DOM

#41

Post by abritinthebay »

coldtea wrote: post #40
m1el wrote: post #29

I 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.44…

> I 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. Isn't that the same as (among several other things) React's JSX?

It's pretty much identical.

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.

Re: Faster DOM

#42

Post by TabAtkins »

c-smile wrote: post #24
dionidium wrote: post #20

Earlier quoted context omitted.

"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: el…

> drops all resolved CSS rules on element, its siblings, its parent and all children.

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!)

Re: Faster DOM

#43

Post by TabAtkins »

amelius wrote: post #38

Is there anything in a browser that ensures that simple updates with local effect have O(1) layout cost? Or do developers have to live with the uncertainty that simple updates may have a higher computational complexity?

The CSS 'contain' property helps ensure that local changes don't cause dirtiness to spread higher up the tree. " rel="nofollow">https://drafts.csswg.org/css-containment/>

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.

Re: Faster DOM

#44

Post by TabAtkins »

sivvy wrote: post #33
dceddia wrote: post #30

Earlier quoted context omitted.

I think he meant "C++ (now Rust)", referring to the Servo browser using Rust - https://servo.org/

I think he is actually a she.

"Anne" is a male name in the Netherlands. (I don't know if it can also be a female name there, but this Anne is definitely male.)

Re: Faster DOM

#45

Post by EGreg »

Yeah, that's why in our framework, we go the FastDOM /greensock route and encourage writing mutation code explicitly for when the state changes.

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.

Re: Faster DOM

#46

Post by c-smile »

TabAtkins wrote: post #42
c-smile wrote: post #24

Earlier quoted context omitted.

"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: el…

> drops all resolved CSS rules on element, its siblings, its parent and all children. 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…

"So if there's no rules mentioning an [a] attribute in the page, el.setAttribute("a", ...) will generally not do anything."

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.

Re: Faster DOM

#47

Post by lj3 »

At what point does fiddling with the DOM get complicated and unpredictable enough that WebGL and/or Canvas starts to look like the saner alternative?

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?

Re: Faster DOM

#49

Post by [deleted] »

c-smile wrote: post #24
dionidium wrote: post #20

Earlier quoted context omitted.

"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: el…

[deleted]

Re: Faster DOM

#50

Post by bzbarsky »

lj3 wrote: post #47

At what point does fiddling with the DOM get complicated and unpredictable enough that WebGL and/or Canvas starts to look like the saner alternative? 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?

At the point when you decide you don't care about accessibility or actually rendering any interesting text.
Post reply on HN