This looks quite interesting - I got the impression that React would need quite a rewrite internally to accomplish incremental rendering.
One thing I noticed with the priority mechanism proposed - Angular 1 has something like this, but it turns out to be a complex api to understand and use. In fact, just about everyone stays away from mucking around there, and all usages of it I have seen in the wild is a straight up hack/misusage. I suspect that something like this would increase complexity dramatically.
Animation is a problem I feel might be worth studying different systems on, maybe not even just the browser. For example, Angular's implementations have ended up mirroring how Chrome handles animations after collaboration with the Chrome team. It probably shouldn't be singularly focused on how one browser has implemented it, but studying these systems is probably best for maximizing extensibility and performance.
Wow I'm at the bottom of the page and this is the first post about the actual article. One thing I was wondering was whether the approach they are taking might actually increase the complexity rather than decrease it. For example, when writing games, it's pretty common to have your physics engine and your rendering engine run at different frame rates. You get the incremental rendering by separating the two. This approach seems to tie the rendering of the internal model to the final rendering.
To be fair, I haven't really spend much time considering the JS animation API. I suspect this is really what's at fault here -- there may be no easy way to update the animation after the fact. Still, I can't help thinking that it would be better to try to separate the screen rendering from the internal model rendering...
Yes, this was my thoughts also. I've got a hunch that concerns have been incorrectly mixed here, leading to unnecessary complexity. But it's too soon to tell for sure
I believe the idea is to expose as little of the prioritization details as possible. E.g. updates triggered by a text input's change event will automatically receive higher priority. Or a DOM element with display: none will automatically receive lower priority. Etc.
The proposal doesn't sound like that was what was intended - it seems like it is left to the user to implement the fibers, with the work priority to be set by the user somehow. Indeed, a quick glimpse of the commits of the implementation reveals a priority system of values exposed directly to the user when creating components (see unit tests).
acdlite is correct here -- most users won't need to worry about priorities and it's unclear to what extent we'll even expose them. The unit tests do not describe a public API (and we're not close to settling on one).
Thanks for the clarification! I've been flying 16 hours today (Milan to SF), so I'm sure I didn't grasp the full significance of the concepts in the doc.
One thing I noticed with the priority mechanism proposed - Angular 1 has something like this, but it turns out to be a complex api to understand and use. In fact, just about everyone stays away from mucking around there, and all usages of it I have seen in the wild is a straight up hack/misusage. I suspect that something like this would increase complexity dramatically.
Animation is a problem I feel might be worth studying different systems on, maybe not even just the browser. For example, Angular's implementations have ended up mirroring how Chrome handles animations after collaboration with the Chrome team. It probably shouldn't be singularly focused on how one browser has implemented it, but studying these systems is probably best for maximizing extensibility and performance.