Incrementalism for hydration/scheduling/batching

[tigt]

package-name

fluurt, I guess?

Description

I’d love to see is libraries and frameworks adopting a Progressive Booting model, especially as we ship more code to our users. Not every component is special, and the developer should be given controls to decide how booting happens!

To show the impact of taking this approach, I made a straw man PR for Preact that uses requestIdleCallback. It cut the TTI down by 6x.

—🌟 When everything's important, nothing is! 🌟

This is especially true if you use a web framework or virtual DOM library that manages component re-rendering in response to state changes. Many of these libraries define component lifecycle methods that all get run synchronously whenever there’s a change. For an app with a lot of components, this can easily be thousands of function calls.

An important point to understand is it’s not necessarily how much code you run that matters, it’s how you run it.
—Why Web Developers Need to Care about Interactivity

Possible Implementation & Open Questions

Hook into requestIdleCallback, or requestAnimationFrame with some delta for the browsers that don’t have it.

But that’s the boring, easy thing. The interesting thing could be something like Mr. Walton describes in Idle Until Urgent:

Code version	FID (p99)	FID (p95)	FID (p50)
Before idle-until-urgent	254ms	20ms	3ms
After Idle-until-urgent	85ms	16ms	3ms

While the requirements are pretty steep for a runtime that has a component model as its atomic unit, the signals and computed properties you guys showed me seemed like they could very cleanly implement this strategy in Marko. In particular, this quote of his:

The reality is that initializing each component in its own task is usually not sufficient and oftentimes not even possible. What’s usually needed is breaking up tasks within each component being initialized.

Is this something you're interested in working on?

Yes