Comparisson with other frameworks

[aSugarRush]

I'll like to see a comparison between this library and other approaches followed by some frameworks, like react or solid.js (the latter being a simplified version of the former).

I know that solid for example doesn't have different priorities for its scheduler, I'll like to know how much it benefits to do the distinction between 'user-visible' and 'background' in your approach.

[astoilkov]

Hi!

That's an interesting idea. How do you imagine for the comparison to look? For example, React scheduler can't be used outside of React so it won't be a direct comparison. I guess something more like A works like that and B works like that written in text and not in code examples or test cases?

I'm using Solid in my own projects. As far as I know, Solid doesn't have async scheduling that goes beyond a single task.

[aSugarRush]

Yeah, I think that a comparison more on technicalities would be good, code examples would be more difficult to do since they are not directly comparable (as you mentioned).

I noted for example that your API is more centered about utility functions for more granular control (isTimeToYield and yieldControl).
Solid's one is more like a queue of task that are resolved ASAP without priority distinction, and you can only give it tasks to enqueue (not in the public API I think).

It would also be cool to know how the Prioritized Task Scheduling API could be used for the same purpose.

I did some digging into this rabbit hole since I wanted to create my own scheduler for a personal project, I took some inspiration from this library (thank you in advance), as well as Solid's one, and tried to mix it with some ideas from Idle Until Urgent strategy.

[astoilkov]

Great ideas. Thanks! I can work on some of those. Maybe first, I want to improve the library in general. I have ideas for a refactoring and better scheduling techniques in general.

What are you working on? Would you like to share it or is it something for private use?

[aSugarRush]

Sounds interesting, I'll be paying attention on that.

In my case I find it fun to work on complicated, sometimes low-level things to code.
So... why not to make an entire javascript framework as a side project? there are not many of them out there (/s).

I worked on how to schedule the tasks it may perform, In my case I have 4 priorities, from highest to low. I use the highest priority for DOM updates and the other tree depending the case.
My API is something like:

export type Priority = Low | Medium | High | Highest;
export type Process = Generator<VoidFunction>

function batchProcess(process: () => Process, priority: Priority): Promise<void>

A Process is a bunch of tasks that needs to be executed, I went for a Generator since I found it more practical.

The highest priority executes as many tasks as possible using MessageChannel and checking if a yield is necessary.
The other 3 priorities only execute one task at a time and yields, it uses the Prioritized Task Scheduling API (if available), or uses Promises that are resolved depending on the priority:

• Hight: queueMicrotask.
• Normal: requestAnimationFrame.
• Low: requestIdleCallback (if available) or setTimeout.

Dunno if it's the optimal way to do it, but I'm pretty happy with the result (wouldn't mind some opinions)

[astoilkov]

I like what you are doing. I think it makes sense. Thank you for the entire discussion as it gave me ideas for my own project as well. I started exploring the possible use of postTask() inside of main-thread-scheduling, we will see how it goes.

About the comparisons, I think a webpage with examples and showcase + benchmarks would be ideal for the project because the project itself is hard to wrap your head around.

[astoilkov]

Also, please add a link to your repo here in the comment if you decide to open-source your implementation. If it's in a bigger project, point to the part that handles scheduling.