Задачи, микрозадачи, очереди и планы

[codemake]

А почему не использовать явный вызов задач в Заданном порядке?
Вместо setTimeout использовать callback и управлять очередью по вашему сценарию
(без гадания как это будет работать в разных браузерах).

[arusakov]

Так вроде речь идет именно про асинхронные задачи. А тут уж без setTimeout, Promise и тд не обойтись.

[codemake]

Promise — это и есть callback,
a setTimeout — это костыль.

[Dlussky]

тогда как все окна с одного домена (по правилу same origin) делят между собой один и тот же событийный цикл, ведь они могут синхронно коммуницировать между собой.

Я специально полез в оригинал, но там «all windows on the same origin», что тоже не проясняет ситуацию. Собственно фраза абсолютно некорректна, т.к. просто случайные окна с одного домена коммуницировать синхронно не могут. Коммуницировать они могут, если, например, одно открыто из другого через window.open. Тогда они действительно будут иметь общий event loop. Обычные же окна или вкладки будут иметь независимые event loop'ы, что легко проверить, если заблокировать поток выполнения в одной из вкладок через alert или prompt, и убедиться, что остальные окна/вкладки продолжают выполнять код (интересно, что хром соблюдает глобальную модальность подобных сообщений, не давая уйти с заблокированной вкладки но код в других вкладках выполняет, и интерфейс обновляет).

[nilfalse]

На самом деле «могут синхронно коммуницировать» не обязательно означает «должны», но всё же замечание дельное, согласен.
Вероятно, под «окнами» автор неявно подразумевал глобальные window объекты у same-origin фреймов одной вкладки, а также окна вкладок, открытых с помощью window.open, однако не берусь утверждать.

[StreetStrider]

Коммуницировать-то они могут, через storage event, но обработка такого события делается ровно так же, как и обработка любого другого, асинхронно (в отдельном фрейме). А синхронность проверить очень просто, нужно открыть две вкладки с одного домена и подвесить одну из них бесконечным циклом. Если, как говорится в статье, все вкладки с одного домена делят между собой один событийный цикл, то подвесятся они все (в чём я сомневаюсь).

[Dlussky]

Если все вкладки открыты через window.open — подвиснут все.
И в то же время, какие-то события будут продолжать обрабатываться, несмотря на бесконечные циклы или например confirm(), потому что EVENT LOOP IS A LIE!
подробнее: http://stackoverflow.com/questions/2734025/is-javascript-guaranteed-to-be-single-threaded/2734311#2734311

[StreetStrider]

В мире ECMAScript микрозадачи именуют заданиями («jobs»).

Вот это место смутило. По идее как раз стандарт и определяет что и как называется. Тогда неясно откуда взялась «авторское» именование и почему оно противоречит стандарту и, мало того, указывается как основное, более правильное (!).

Что касательно задач и микрозадач, то, опять же, я думаю, ситуация здесь несколько проще, чем автор пытается нам описать.
Задача, в терминологии автора, соответствует функции, прилетевшей из события или таймера (setTimeout, setInterval), а микрозадача соответствует setImmediate. Таким образом, микрозадача будет выполняться раньше, чем любая задача (потому что первая ставится в начало очереди, а вторая — в конец). Это же проясняет и ситуацию с промисами. Если имплементация промиса для вызова уже резовленного промиса «использует» setImmediate (ставит обработку в начало очереди), то мы получаем правильный порядок, если setTimeout(fn, 0) (ставит обработку в конец очереди), то будет некорректная последовательность в выводе.

[rock]

Вы не правы. Начнем с того, что ECMAScript не единственный стандарт, регулирующий это дело. Мало того, до ECMAScript 6 в нем вообще отсутствовали упоминания микрозадач (ок, назовём так) в любом виде, а задач там нет и сейчас. setImmediate это как раз задача (task) — он не блокирует основной событийный цикл. Микрозадачи это, например, Promise (по стандарту), process.nextTick (сравните с setImmediate на ноде), микрозадачи создаются MutationObserver.