When is a runtime that ranks urgent updates above deferred work, and can abandon a half-done pass, worth adopting?

Most component runtimes schedule one way: whatever is dirty gets flushed together, in order, in a single pass, and that pass runs to completion. A ranking runtime adds two capabilities on top - **priority classes** and **pre-emption** - and both have a price. Deciding whether you want them is a judgment call, not a best practice. ## What ranking actually adds - **Urgency classes.** An update traceable to direct input - a keystroke, a press, a drag - is urgent. An update that only refreshes results the user is not waiting on is deferred. The runtime flushes urgent work first. - **Pre-emption and discard.** A deferred pass that is half-done can be abandoned when an urgent update arrives; the abandoned work is thrown away and redone later from the newer state. This is what stops a long deferred pass from sitting in front of a keystroke. - **Deferred reads of a value.** A deferred update can render from the previous value of some state while an urgent pass renders from the new one, so the typed character appears immediately and the expensive view catches up. Notice what ranking does **not** add: it does not make the expensive pass cheaper, it does not move work off the thread, and it does not shorten a single indivisible unit of work. It reorders and it retries. ## What it buys One thing, clearly: responsiveness under contention. When a keystroke and a 200-node re-render want the same thread in the same moment, ranking ensures the keystroke's output is described and applied first, and that the heavy view is rebuilt from the latest input rather than from a state two characters stale. For search-as-you-type over a large result set, a filter over a big table, or a view that swaps while data streams in, that is the difference between an interface that feels immediate and one that feels stuck. ## What it costs 1. **Output code may run several times per action.** One keystroke can produce an urgent pass, an abandoned deferred pass and a redone deferred pass. Purity stops being a coding preference and becomes a correctness requirement, because every impurity now multiplies. 2. **Discarded work is wasted work.** Abandoned passes consume CPU and battery for output nobody sees. Under fast input, total work goes up even as perceived responsiveness improves. 3. **Reasoning gets harder.** "What ran, in what order, and did it survive?" becomes a real question during debugging. Logs show renders that were discarded; counters double; ordering intuitions that held with one queue no longer hold. 4. **Consistency traps appear.** Data read during a pass that is not part of the tracked state can change between the start and the end of that pass, so one screen can end up describing two different values. Ranking makes that window wider than a single synchronous pass ever did. 5. **A team skill cost.** The split between urgent and deferred is a design decision in every feature, and a wrong split is worse than no split at all. ## The decision framework I would use | step | what I am looking for | what it rules in or out | |---|---|---| | measure the interaction | is input visibly waiting behind a render? | no contention, no reason to rank | | find where the time goes | one indivisible heavy unit, or many cheap ones? | one huge unit will not be helped by reordering | | try the cheap levers | fewer nodes, narrower invalidation, less work per pass | often ends the problem outright | | move the work | compute off the interaction, page or virtualise the data | changes the amount of work, not its order | | then consider ranking | contention remains after the above | adopt narrowly, on the specific interaction | | re-measure | did perceived latency improve for real users? | credit or revert the change honestly | The ordering matters because ranking is the only lever on that list that adds work rather than removing it. It is the right last step and a poor first one. ## The failure mode to expect A team decides responsiveness is everything and marks nearly every update deferred. Now nothing is urgent, so there is no ordering left for the runtime to exploit; worse, under continuous input the deferred passes are repeatedly started and abandoned, so results arrive later than before for more total CPU. The split only helps when it honestly reflects what the user is waiting for, and that is usually a small minority of updates. ## The organisational angle Adopting ranking means adopting the discipline it assumes: output code that is pure, shared mutable data read through the tracked state rather than around it, and reviewers who know why. If those are not in place, the first symptoms are duplicated side effects and screens that occasionally disagree with themselves - bugs that look random and are actually scheduling made visible. I would rather run one ordered queue with an application that does less work per pass than run a ranking scheduler over code that has not earned it. Separately, how long a single unit of work may occupy the thread before yielding is its own subject with its own budgets; ranking decides which work goes first, not how long any piece of it may run.