We're using this for 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.
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.
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.
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).
By reading the README I guess that exceptions would be an issue. With fastdom they are thrown asynchronously, so a different API is required to catch them.
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 ..
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.
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?).
18 comments
[ 1.4 ms ] story [ 57.4 ms ] threadWe 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.
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.
But it loads in Chrome.
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.
- http://wilsonpage.github.io/fastdom/examples/animation.html
- http://wilsonpage.github.io/fastdom/examples/aspect-ratio.ht...
Especially the animation example shows a very noticeable improvement.
Batched: it outputs "green" then "green".
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?).