Why fastdom?

[oskarrough]

Fastdom sounds so efficient that I need to ask what the possible downsides are. Why is this not the default behaviour implemented in modern browsers?

you should wrap any DOM reads with fastdom.read and writes with fastdom.write. They will get batched & executed in next frame...

[paullewis]

The simple reason is that browsers are wired for sync ops. You can set offsetWidth (write) and then ask for its value (read) and that is allowed. FastDOM lets you opt out of that and makes everything async. That is you would get the old value of offsetWidth before the new one was set. That's one example, and there are many properties that would trigger layout that you can Google for.

Async is great, and it would be lovely if this were the normal behaviour. But things would break if this were the default. FWIW Dart actually does DOM updates async, not that it solves this issue, but just so you know there are places where async DOM updates are normal and don't require libraries like FastDOM.

[wilsonpage]

Would it be helpful to have an answer like this on the main readme?

[paullewis]

I think so. Setting out why this even a thing is going to help devs less familiar with the area.

[renatoi]

Sorry to resuscitate the issue but I have a question:

What's the difference between using requestAnimationFrame directly and using fastdom?

[wilsonpage]

Using rAF might be OK for very small issues, but it doesn't ensure you won't be interleaving DOM read and writes, which is the thing we want to avoid.

How can you be sure that another part of your app hasn't scheduled conflicting work for the same frame?

FastDOM 'globally' coordinates when your read/write tasks are run, meaning that they are always run in the most performant way. All you have to know is that when your callback fires, the job is done :)

[serapath]

how does the performance of fastdom compare to virtualdom?

[wilsonpage]

A virtual DOM library could consume a library like Fastdom to help it
schedule operations at the correct time.

A virtual DOM library may also do a lot more. Think of fastdom as a lower
level tool and a virtual DOM library as higher level abstraction.

All performance comparisons are relative. You'd need to try for yourself.

W.
On 7 Feb 2015 03:57, "serapath" notifications@github.com wrote:

how does the performance of fastdom compare to virtualdom?

—
Reply to this email directly or view it on GitHub
#35 (comment).

[leandromoreira]

It might sound silly (just naming and curiosity) but why measure and mutate functions instead of read and write?

Forget about it, I think I know why.

[wilsonpage]

I think they are a little clearer in their intent. For example, you can 'read' an via .getAttribute() without making DOM 'measurements'. With 'mutate' I also feel it's more explicit. Sounds more damaging and should be treated with care.

[allyraza]

what I don't understand why do we need a library when browser actually queue dom operations before doing a repaint.

[paullewis]

@allyraza because the browser won't stop you breaking that behaviour. If you mutate some styles and then request -- say -- offsetLeft, the browser will run layout at that point. So while it's true that browsers do enqueue DOM operations, and that by default they will get applied in a batch, it's also true that you can break that behaviour with JavaScript, and that's what FastDOM is attempting to help with.

[crazy4groovy]

I see a lot of performance solutions suggest a double/inner raf, but fastdom isn't using that technique. Is there a reason? I presume it was tried and measured.

[wilsonpage]

Interesting, can you give more detail/links?

[crazy4groovy]

https://stackoverflow.com/questions/44145740/how-does-double-requestanimationframe-work