Fastdom – a weapon in the war against jank

by lacoolj • 11 years ago

77 16 11 years ago

pornel• 11 years ago

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.

skaplun• 11 years ago

I get error on your splash from note 2, unrelated? :)

deanclatworthy• 11 years ago

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

jleahy• 11 years ago

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.

spyder• 11 years ago

In Firefox: "Page load failed! The application could not be fully loaded. Please try again later."

But it loads in Chrome.

superice• 11 years ago

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• 11 years ago

Did you miss the example links from the readme?

- 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.

s_kilk• 11 years ago

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

Joeri• 11 years ago

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

dorianm• 11 years ago

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• 11 years ago

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

Symen• 11 years ago

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.

daemonk• 11 years ago

Does this work with svg?

fit2rule• 11 years ago

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• 11 years ago

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.

onli• 11 years ago

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?).

Fastdom – a weapon in the war against jank

Related Stories