И забивают хуй на доступность для всех остальных

Потому что все кое-как формально работает из коробки

У тебя есть бесконечный процесс рендеринга. Как семантически это сделать? return new Promise(() => // never resolve)? Лучше бы какой-то синтаксис, который позволял бы сказать - запусти вот это вот как файбер. (мне так кажется)

Я даже не имею ввиду конкретно эту задачу, а скорее как тип задач.

по поводу passive и хром, https://caniuse.com/#feat=passive-event-listener

Не надо эмулировать ивент луп. Запустили однократный рендеринг в промисе и забыли. Пришло событие - остановили предыдущий рендеринг и запустили новый. Присмотритесь к примеру с рендерингом.

А почему не взять асинхронные генераторы для этого? Они вроде как именно это и делают. И полифиллятся

Ну, транспилируются

И чем они отличаются от async/await?

Наличием yield. Который позволяет явно декларировать уступку потока исполнения

await делает то же самое.

Нет. Await ожидает завершения выполнения операнда, т.е. внутренней сущности. Yield позволяет ожидать вызова внешней сущности.

await не более чем синтаксический сахар над yield с автоматической обработкой обещаний. И чтобы этот yield сработал необходимо, чтобы все функции выше по стеку были генераторами.

Либо сделать дополнительную обёртку над генераторами. Генераторы это инструмент, а не конечный фреймворк, они сделаны максимально гибкими, чтобы их можно было адаптировать для большого списка задач. Я сходу вижу два способа реализации данной задачи на генераторах

То, о чём вы говорите, уже давно реализовано в библиотеке "co", где каждая функция должна быть превращена в генератор и завёрнута в обёртку.

Co - это далеко не единственный способ применения генераторов. Стоит поиграться с ними чуть больше, возможно, придёт понимание того, как на них можно реализовать файберы. У меня нет желания писать код, но это точно можно сделать на async_hooks в ноде и совместить с zone.js в браузере.

Разработчики языка занимаются достаточно сложной работой, и новые фичи языка нужно вводить только если все возможности применения старых исчерпаны - сложность входа в язык является не линейной от количества фич, а скорее экспоненциальной, потому что нужно учитывать их комбинаторную сложность.
Я сильно сомневаюсь, что данная возможность должна существовать в userland-е, потому что она достаточно сложна для восприятия людьми, а люди, создающие библиотеки, априори должны быть готовы к страданиям - если библиотека построена с целью удобства её разработки, а не удобства её пользователей, то это плохая библиотека. Ей просто никто не будет пользоваться.

Создатели библиотек априори делают не очень приятные вещи иногда. И с этим стоит смириться, а не тащить ради удобства новые вещи в язык.

7 лет уже играюсь. http://nin-jin.github.io/article/article_fiber/article_fiber.doc.xml
Я вам больше скажу, на внедрение асинхронных функций и генераторов было потрачено ресурсов на пару порядков больше, чем потребовалось бы на полноценные файберы. При этом файберы использовать на порядок проще и они полностью покрывают возможности асинков и генераторов.

У нас такая же тема:(помылась и остался только инженер

Всем привет!

Если вы еще не знаете, на этой неделе мы запустили новый проект – IT-фестиваль TechTrain. Он будет 1-2 сентября в Питере. Мы планируем собрать пару тысяч участников и несколько десятков стендов сообществ и компаний. Читайте анонс и подписывайтесь на канал в TG и паблики в соцсетях.

Анонс: https://habr.com/p/412541/

Telegram: https://t.me/techtrainfest
VK: https://vk.com/techtrain
Facebook: https://www.facebook.com/IT-%D1%84%D0%B5%D1%81%D1%82%D0%B8%D0%B2%D0%B0%D0%BB%D1%8C-TechTrain-1067349060111345/
Twitter: https://twitter.com/techtrainfest

Oh no

Ы?