WICG
How does read-write batching work exactly?
fastDOM relies on the app to indicate when it's read vs. write phase is. What would dom-read-write-batching do exactly? Enter the read phase on the start of a frame, switch to the write phase on first write, and throw if a read is attempted during the write phase? There probably needs to be an additional API to co-ordinate this (maybe an event saying the write phase has been entered), right?
What I was thinking is something simpler, but it's fairly possible that I'm missing something. What happens if write operations are only acted upon (In terms or re-layout) when we're approaching the end of a frame? (Not sure when as we need to make sure that layout will be done before end of frame).
That means that any read operations that are done after writes will get the wrong info (similar to batching all reads followed by all writes), but assuming the app has opted in, it should be able to deal with it.
Would that work? Or am I missing the mark?
Maybe that's possible, IIRC our layout experts (maybe @esprehn) feel that's not practical to implement efficiently but I may be forgetting.
Also in that model it would be pretty hard for authors to find all their bugs, right? Presumably you'd use it in conjunction with a library like fastDOM.