Messages are dispatched while microtask queue is not empty about ws HOT 6 CLOSED

That's because this is what happens under the hood.

queueMicrotask(function () {
  console.log('received: something1');
  Promise.resolve().then(() => {
    console.log('microtask something1');
    return Promise.resolve().then(() => {
      console.log('microtask-nested something1');
    });
  });
  queueMicrotask(function () {
    console.log('received: something2');
    Promise.resolve().then(() => {
      console.log('microtask something2');
      return Promise.resolve().then(() => {
        console.log('microtask-nested something2');
      });
    });
  });
});

We can get the expected behavior by resuming the parser when the microtask queue drains, for example by using setImmediate() instead of queueMicrotask(), but in that case we don't have one event per microtask but one event per loop iteration.

from ws.

The WebSocket spec defines one event to be dispatched per task and not per microtask so setImmediate sounds appropriate. I am not sure if that degrades the performance though.

from ws.

Isn't a task in that context/spec a microtask?

I am not sure if that degrades the performance though.

It almost certainly does but there is the allowSynchronousEvents option now. Anyway setImmediate() might also have unintended side effects. I have to think about it.

from ws.

It is a task but it is on a different queue, a microtask queue, in the html spec. The spec also says that a microtask queue is not a task queue so I am not sure. I think people also refer to tasks/global tasks as macro tasks as opposed to micro tasks.

from ws.

https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-task definitely puts a task on a task queue and not a microtask queue though.

from ws.

It looks like browsers do not dispatch one event per microtask so I guess I misunderstood the spec in #2160.

from ws.