These questions are already answered in the post.

Yes, both microtask and task execution is specced by html. Using a task rather than a microtask costs performance by the time it takes to do other between-task things such as rendering. There was an opinion that promises were slow that was really only down to poor callback scheduling.

Ok, thanks. Haven't read the spec, that's why I was asking.

>However, the general consensus is that promises should be part of the microtask queue, and for good reason.

That's the only bit I found in the post regarding that. Didn't sound like 'it's in the spec' to me.

Regarding the example, (I'm gonna sound like the SO posters that I hate but) there are other appropiate places where you should hook up that callback. If the one you chose does not play well with Promises yet (because you want to access an object thats at the end of its lifetime and not guaranteed to exist), then ¯\_(ツ)_/¯.

I asked for an example where the program breaks because I thought that if you queue up things 'for later dispatch' you shouldn't be worriyng about the order where they dispatch. If you're actually worried, then chain them together with the classic callback stuff.

But, I'm not demeaning your post (I see you're the author), it was really good. The main issue is see is (as you stated in your comment) that Promises as microtasks would increase their performance. It is a shame, however, that we as developers are not able to queue microtasks directly (like when using setImmediate, process.nextTick) :(

The spec defines the execution of tasks vs microtasks tightly, the bit that's less clear is how ECMAScript promise jobs interact with microtasks - the consensus is they're in the same queue, but it isn't explicit.

I agree that we should have an API to queue microtasks, although as soon as promises use microtasks, Promise.resolve().then(func) becomes that API. Some promise polyfills also use mutation events to queue microtasks.