> 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.
Literally means "born" (Fr).
Faster DOM
31–40 of 54 posts
Re: Faster DOM
#32I'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.
Where are you getting that number? The benchmarks in the readme show morphdom being much slower for several operations.
Re: Faster DOM
#33Re: Faster DOM
#34I 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…
Me too, kind of, except I'm mostly using functions to construct the templates. Haven't tested the performance yet, but it should be good.. https://github.com/jbe/zodiac
Re: Faster DOM
#35Re: Faster DOM
#36Earlier quoted context omitted.
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.
Where are you getting that number? The benchmarks in the readme show morphdom being much slower for several operations.
5 out of 31? And I'd say only 3 are noticeably slower, and only 1 seems to be "much" slower (at 0.38ms). But given that just about everything benchmarked seems to be sub-0.05ms, I'm left thinking that gaining noticeable and much-increased performance is highly dependent on operations, and a high-precision timer. Humans aren't going to notice a difference between an operation lasting 0.04ms vs 0.02ms. Unless a ton of operations add up to something noticeable, of course.
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.
Re: Faster DOM
#37Re: Faster DOM
#38Is 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?
Re: Faster DOM
#39Build faster browsers.
Don't be afraid of dogma.
There were times before there was a DOM (you might not have been born yet) and there can be times after DOM :)
Re: Faster DOM
#40I 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?