> I would like to hear the author's thoughts on Concurrent Mode in general, and how Crank.js addresses the same issues. There's no mention here of time slicing, which is what Concurrent Mode really unlocks

I think Concurrent Mode is a really interesting project, but I also think that the developer experience of using CM as the React team has defined it is really lacking.

There’s the issue of querying when a specific component (or the whole tree) has finished rendering. With React, rendering is treated as a black box, and this was mostly okay when rendering was synchronous, but people often ask with concurrent mode, how do I know when rendering has finished, locally or globally. The answer the React maintainers would give would be, probably, useEffect hooks, but that’s not enough for me.

Promises are like the Planck constant of asynchrony in javascript; they’re the smallest units of time possible for executing code later and their callbacks have the highest priority. To not have a promise-backed API for CM seems like a step backwards. Even if I were to implement time slicing, I would want it to be promise based. Also, React fiber time slicing comes at a cost, in the sense that you have to check the clock for every unit of work to make sure you don’t exceed your budget. I would want any sort of priority-based it to be done on an opt-in, limited basis. I definitely don’t think every component should be a possible asynchronous breakpoint, that sounds like a nightmare to debug.

I dunno, I need to write a longer, better structured blog post about this stuff, but here’s something to think about: if you want concurrent mode or time slicing or scheduling priorities, the tools to implement it in user space are probably already there with Crank.