[anotherangrydev]

Does the spec explicitly tells about how to time tasks vs microtasks? I was under the impression that it was up to the implementation and not relevant.

To add something more, I would really like to see an example where this actually ruins a program execution.

Edit: And this is wrong because... ?

[jaffathecake]

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.

[anotherangrydev]

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) :(