Абсолютно согласен. Называть код "парашей" (а это есть в статье) — ну верх непрофессионализма. Я не хочу читать про смол и его использовать. Не потому, что он плох, а потому, что его программируют радикалы, мнение которых мне не близко.
По иронии судьбы в статье, что вы написали в комментах есть мое решение. И оно тоже проще некуда. И тоже на редьюс. Незнаю почему его так много людей боятся, это же реально простой метод.
Вы какой-то бред городите. Тот же async/await гораздо затратнее фича, если сравнивать с reduce. Асинк функция все равно завернет это в Promise. Про GC вообще не понятно откуда вы это взяли. Тем более — сейчас оптимизатор работает лучше именно с функциональными паттернами — так как он прекрасно представляет что и где можно ожидать. Чем императивнее (а for-of это именно оно) — тем больше неизвестных для оптимизатора. Reduce — одна из самых банальных функций, которую можно представить и тут она, кстати, вполне к месту.
Речь идет о фундаменте языка, а вы пишете про конкретные API (микрофон и камера). Связи не вижу от слова совсем. Тем более промисы ничего не блокируют.
Промисы решают не только вложенность (если вы про анонимные функции) — а еще массу полезностей, такие как создание переиспользуемого объекта с окончательным состоянием, большим количеством возможных "продолжений" (then-веток) и инкапсулирование значения. Все это на коллбеках конечно тоже реализовать можно, но… зачем, если это уже есть в промисах?
Прозрачность исполнения у промисов абсолютно такая же, как и у коллбеков. Ни промисы, ни коллбеки не затемняют вопрос "когда же исполнится мой код". Ответ очевиден — eventloop. Синхронные таски — здесь и сейчас, асинхронные — мы не знаем (если мы про результат этих тасков), так как эти веще делегируются на low-level API, который закрыт.
В том, что это трудно поддерживать. Если вложенность кода (не важно по какой причине — много if-веток, много вложенных функций, много коллбеков, циклов, whatever) — большая, то читать и понимать такой код гораздо проблематичнее. Любая flat сущность мозгом воспринимается в разы проще, чем иерархия.
Ничего, что async/await напрямую завязаны с работой с промисами? Ничего, что промисы решают огромную вложенность коллбеков (это не надуманная проблема, если что)? Ничего, что промисы более явно инкапсулируют значение, причем это значение можно гибко переиспользовать?
Ну да, х*й с ними с промисами, давайте не читать ничего и не думать, юзать коллбеки и сахар проще.
Так я изначально ничего против async/await не имел, просто сказал что await не всегда то же самое и что, как вы в последующем и выразились: к нему нужен иногда немного другой подход.
Async/await это сахар из сборной солянки из генераторов и промисов. Разница только в том, что пример, где Promise.all — не блокирует последующее выполнение в данном скоупе (просто представьте, что у вас тысяча и одна асинк операция в одном скоупе — лишними эвейтами вы будете блокировать даже делегацию задач на low-level API или регистрацию каких-либо коллбеков. Возможно пример из ноды вам прояснит что я имел ввиду:
Ах да, вы, безусловно, правы. Просто писал в спешке. Асинк/эвейт хорошо, но это не всегда эквивалентно коду выше, так как чисто на промисах вы все таки не блокируете данный стэк, а едете дальше в исполнении кода. Разница не большая, но она есть.
Простите конечно, но вы бред городите.
Во-первых, начнем с того, что ни setTimeout, ни setInterval не запускают код. Они лишь регистрируют коллбек. Запускает код уже внутреннее API, которое напрямую связано с такой штукой, как eventloop. Это и есть сердце асинхронности и работы всех асинк-функций. Так вот, что в случае с setTimeout, что в случае с setInterval, код из следующего коллбека будет запущен только и только тогда, когда в callstack'e не будет никаких операций. Поэтому setInterval ничего не запускает и уж тем более ему не все равно, он просто регает коллбек. Почему анимация дергается когда она на setInetrval — так это потому, что регистраций колбеков setInterval делает больше (в тот момент, когда callstack пустует), чем setTimeout. setTimeout более контролируемый, скажем так. А вообще анимации делать неправильно ни через то, ни через другое. Для анимаций есть давно requestAnimationFrame.
Интересно, почему везде, где поясняют промисы — делают это так поверхностно? Просто мой любимый случай, это когда есть, например, чейн из 5 then, и тебе надо в пятом то, что вычислилось во втором. Многие начинают в такой ситуации вкладывать промисы друг в друга (для общего скоупа) и… тем самым пораждают тот же самый "колбек хелл", только теперь это "промис хелл" с теми же вложенностями.
Вы не на приеме, я на приеме. Бизнес так не работает. Может в России и привыкли к такой подаче, но я есть говно не хочу.
Ага, но, тем не менее, если ты представляешь людям свой продукт, который что-то решает лучше — изволь выразить мысль корректно, а не как обиженка.
Абсолютно согласен. Называть код "парашей" (а это есть в статье) — ну верх непрофессионализма. Я не хочу читать про смол и его использовать. Не потому, что он плох, а потому, что его программируют радикалы, мнение которых мне не близко.
По иронии судьбы в статье, что вы написали в комментах есть мое решение. И оно тоже проще некуда. И тоже на редьюс. Незнаю почему его так много людей боятся, это же реально простой метод.
Вы какой-то бред городите. Тот же async/await гораздо затратнее фича, если сравнивать с reduce. Асинк функция все равно завернет это в Promise. Про GC вообще не понятно откуда вы это взяли. Тем более — сейчас оптимизатор работает лучше именно с функциональными паттернами — так как он прекрасно представляет что и где можно ожидать. Чем императивнее (а for-of это именно оно) — тем больше неизвестных для оптимизатора. Reduce — одна из самых банальных функций, которую можно представить и тут она, кстати, вполне к месту.
Примитивнее reduce — разве что только map. Что там трудного и причем тут вообще типы?
Не совсем так, это не заслуга классов самих по себе. Это делается внутренним механизмом через species.
https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Array/@@species
А, точно, перепутал.
А я писал, что есть проблема с промисами?
Речь идет о фундаменте языка, а вы пишете про конкретные API (микрофон и камера). Связи не вижу от слова совсем. Тем более промисы ничего не блокируют.
Промисы решают не только вложенность (если вы про анонимные функции) — а еще массу полезностей, такие как создание переиспользуемого объекта с окончательным состоянием, большим количеством возможных "продолжений" (then-веток) и инкапсулирование значения. Все это на коллбеках конечно тоже реализовать можно, но… зачем, если это уже есть в промисах?
Прозрачность исполнения у промисов абсолютно такая же, как и у коллбеков. Ни промисы, ни коллбеки не затемняют вопрос "когда же исполнится мой код". Ответ очевиден — eventloop. Синхронные таски — здесь и сейчас, асинхронные — мы не знаем (если мы про результат этих тасков), так как эти веще делегируются на low-level API, который закрыт.
В том, что это трудно поддерживать. Если вложенность кода (не важно по какой причине — много if-веток, много вложенных функций, много коллбеков, циклов, whatever) — большая, то читать и понимать такой код гораздо проблематичнее. Любая flat сущность мозгом воспринимается в разы проще, чем иерархия.
Ничего, что async/await напрямую завязаны с работой с промисами? Ничего, что промисы решают огромную вложенность коллбеков (это не надуманная проблема, если что)? Ничего, что промисы более явно инкапсулируют значение, причем это значение можно гибко переиспользовать?
Ну да, х*й с ними с промисами, давайте не читать ничего и не думать, юзать коллбеки и сахар проще.
Так я изначально ничего против async/await не имел, просто сказал что await не всегда то же самое и что, как вы в последующем и выразились: к нему нужен иногда немного другой подход.
Async/await это сахар из сборной солянки из генераторов и промисов. Разница только в том, что пример, где Promise.all — не блокирует последующее выполнение в данном скоупе (просто представьте, что у вас тысяча и одна асинк операция в одном скоупе — лишними эвейтами вы будете блокировать даже делегацию задач на low-level API или регистрацию каких-либо коллбеков. Возможно пример из ноды вам прояснит что я имел ввиду:
Ах да, вы, безусловно, правы. Просто писал в спешке. Асинк/эвейт хорошо, но это не всегда эквивалентно коду выше, так как чисто на промисах вы все таки не блокируете данный стэк, а едете дальше в исполнении кода. Разница не большая, но она есть.
Простите конечно, но вы бред городите.
Во-первых, начнем с того, что ни setTimeout, ни setInterval не запускают код. Они лишь регистрируют коллбек. Запускает код уже внутреннее API, которое напрямую связано с такой штукой, как eventloop. Это и есть сердце асинхронности и работы всех асинк-функций. Так вот, что в случае с setTimeout, что в случае с setInterval, код из следующего коллбека будет запущен только и только тогда, когда в callstack'e не будет никаких операций. Поэтому setInterval ничего не запускает и уж тем более ему не все равно, он просто регает коллбек. Почему анимация дергается когда она на setInetrval — так это потому, что регистраций колбеков setInterval делает больше (в тот момент, когда callstack пустует), чем setTimeout. setTimeout более контролируемый, скажем так. А вообще анимации делать неправильно ни через то, ни через другое. Для анимаций есть давно requestAnimationFrame.
Немного распишу, раз уж заплюсовали.
НЕ надо решать так:
Пример плохого решения:
Решать надо переиспользованием объектов промисов, которые несут в себе значение. Примерно так:
Интересно, почему везде, где поясняют промисы — делают это так поверхностно? Просто мой любимый случай, это когда есть, например, чейн из 5 then, и тебе надо в пятом то, что вычислилось во втором. Многие начинают в такой ситуации вкладывать промисы друг в друга (для общего скоупа) и… тем самым пораждают тот же самый "колбек хелл", только теперь это "промис хелл" с теми же вложенностями.
Огромное спасибо за труд!