
Fastdom – a weapon in the war against jank - lacoolj
https://github.com/wilsonpage/fastdom
======
pornel
We're using this for [http://app.ft.com](http://app.ft.com), and it has
completely eliminated problem of layout trashing for us.

We can have many independent components, each one independently reading and
modifying DOM however it wants, but all of that goes asynchronously through
fastdom that acts as a scheduler.

~~~
deanclatworthy
I get a very janky scroll on an iPhone 6s on this page. Presumably it's not
thrashing though.

~~~
jleahy
It used to be much much worse, to the point of being absolutely unusable on
the latest iPhone. I actually cancelled my FT subscription for several years
solely because of the poor performance of that site.

It still has a nice bug where it reserves space for ads, then when it fails to
download them (because you're offline) after 60s the whole page reflows
(losing your position). Plus the classic loss of scroll position on screen
rotation.

------
Joeri
If this works, why don't browsers do this natively?

~~~
dorianm
Because it would not be backward compatible, eg:

    
    
        el.style.color = "red" // write
        console.log(el.style.color) // read
        el.style.color = "green" // write
        console.log(el.style.color) // read
    

Outputs: "red" then "green".

Batched: it outputs "green" then "green".

~~~
coderdude
There could be a flag included in the HTTP response header (X-Batch-DOM) or a
meta tag like <meta http-equiv="X-Batch-DOM" content="1">. The response header
would be a better place for that flag since you can stick a meta tag at any
point in your markup (even where it's incorrect to do so). The browser could
choose to ignore the meta tag if any JS has executed or it could reload the
page with the setting turned on. Not ideal. Anyway, if you feel completely
sure that your code would not do anything like you've demonstrated then
batching might work fine. Though this basically excludes the safe use of
externally linked scripts that you can't control (analytics is one example).

------
onli
Very hard to integrate that even in a very simple app of mine (js-wise at
least).

First, I can't use fastdom-strict.js to help with the integration, because of
course I'm using other scripts (pace.js, jquery, Magnific Popup, a detail-
polyfill and Flot). Am I missing something here to apply that selectively?

But also my own code would need transformation. It's quite common to have Dom
reads and writes on the same line, all of them would have to be separated and
variables be created… That is not impossible much work, but together with the
other libraries not nice.

It would be way better if this would patch the existing functions (maybe on
jQuery side?) to automatically batch DOM reads and writes, without having to
take care of that at the side of the developer. But the asynchronity
introduced by that concept would break a lot, this would then need callbacks
or promises (I think at least?).

------
superice
Interesting, but I'm missing a benchmark or video comparison between a page
built with fastdom and one without. How much of a difference does this
actually make? Is batching DOM operations really faster than just executing
them whenever you want?

Do not understand me wrong, if this works as hoped, I think this might a
really useful library, but I'm curious if it's worth the trouble of
implementing.

~~~
ygra
Did you miss the example links from the readme?

\-
[http://wilsonpage.github.io/fastdom/examples/animation.html](http://wilsonpage.github.io/fastdom/examples/animation.html)

\- [http://wilsonpage.github.io/fastdom/examples/aspect-
ratio.ht...](http://wilsonpage.github.io/fastdom/examples/aspect-ratio.html)

Especially the animation example shows a very noticeable improvement.

~~~
s_kilk
The aspect-ratio demo shows a huge improvement too, especially if you crank up
the number of nodes to 1000.

------
fit2rule
Doesn't this just spell broken to anyone else? I mean, I get it .. the DOM is
not the best way to produce a GUI .. but .. the existence of these kinds of
tools just makes me want to burn the entire stack and start again. Really,
things like this just tweak my "The web sucks, just do everything native"
buttons ..

~~~
grumblestumble
The web is far more ambitious than some proprietary walled garden. Personally,
I'm willing to put up with a bit of suckage in the DOM API to support that.

------
daemonk
Does this work with svg?

