Так Google официально призналась в американском суде, что они преднамеренно выдают некорректную выдачу, чтобы люди переходили на вторую, третью, четвёртую страницы выдачи, чтобы показать им больше рекламы (напомню: Google получает бо́льшую часть бюджета за счёт рекламы, и эта стратегия позволила им увеличить прибыль в несколько раз). Плюс они на первые страницы выдачи выводят исключительно сайты, где интегрированы сервисы Google (Google AdWords, Google Analytics и т.д.).
Так что VPN не спасёт. Google больше не работает так хорошо, как работал в 2019 и раньше.
Оплатил Plex (единоразовый платёж, чтобы в мобильном приложении лишние попапы не выскакивали). Оплатил в Amazon Appstore (т.к. с оплатой в Google Play проблемы, сами знаете).
В результате, как только Amazon Appstore объявил о закрытии - ребята из Plex отказались переводить покупку на какую-нибудь другую площадку. При этом поддержка Amazon Appstore уверяла, что покупка бессрочная, и закрытие сервиса Amazon Appstore не является причиной отказа Plex от ответственности.
Ждём 20 августа, когда Amazon Appstore закроется, чтобы начать качать права у них на форуме
Простите, вы оказались абсолютно правы. Оказалось, что использование глубокой пересборки кода с помощью AST - это было только в моих мечтах. Насмотревшись на магию SvelteJS и аналогичных решений с построчной обработкой кода, я предполагал, что и в ReactJS эту же магию используют в компиляторе, а-ля:
Но в финале всё оказалось намного прозаичнее. Действительно, мы при каждом рендере создаём новую функцию внутри useCallback . Как описывают это сами разработчики ReactJS:
The default behavior of useCallback is rather naïve but it is very easy to predict, and you always know that you're gonna "see" fresh values there.
Наверное, это правильно с их стороны. Но в этом случае я теперь 100 раз подумаю, нужно ли мне использовать useCallback или нет.
Вот пример, как проблему с пересозданием функции можно решить (может, кому-то это пригодится):
function useOptimizedCallback<T extends (...args: any[]) => any>(fn: T, deps: readonly unknown[]): T {
const ref: any = useRef(fn);
// we copy a ref to the callback scoped to the current state/props on each render
useLayoutEffect(() => {
ref.current = fn;
}, deps);
return useCallback(
(...args: any[]) => ref.current.apply(void 0, args),
[]
) as T;
}
@winkyBrain@adminNiochenСпасибо, что мотивировали пойти и собственноручно разобраться в этом! А то бы до последнего в это верил, как дурак
Но на каждый ререндер вы всё равно создаёте и прокидываете в него новую функцию
В обычном JS - да, но в JSX (с переводом в AST) - новая функция не создаётся при каждом рендере, если зависимости не менялись.
Если коротко, то JSX - это просто формат файла, который к JS имеет очень косвенное отношение. Синтаксис похож на JS, но он не работает как JS. Из него сначала строится абстрактное синтаксическое дерево (AST), потом отдельный механизм в React обрабатывает каждую часть кода отдельно, и на основе этого уже строится JS. Поэтому привычные законы JS с ним не работают, там происходит очень много магии под капотом при компиляции.
Я в комментарии ниже подробнее описал, не буду здесь дублировать.
Это даже не реакт, а банальное понимание того, как функции и замыкания работают в принципе
Простите, но вы не правы. Ваши доводы логичны, но вы упускаете одну важную деталь, из-за чего все ваши выводы неверны.
useCallback запускается не в чистом JS, а в JSX. А если быть точнее, проходит через транспиляцию в AST (абстрактное синтаксическое дерево), и далее React работает уже с ним. И это касается не только дерева элементов в return, но и всего кода внутри функции компонента (включая и все хуки).
Достаточно простое доказательство этого - это новая версия React, в которой, как пообещали разработчики, useCallback писать не потребуется, ко функциям внутри компонента будет автоматически применяться мемоизация на основании анализа кода компилятором.
Также вы можете посмотреть скомпилированный в JS код, и вы там увидите, что функция из useCallback на самом деле находится за пределами функции компонента и перезаписывается там же (советую включить в React компиляцию компонентов по отдельным бандлам, чтобы проще было читать код, не было лишней логики).
Я рекомендовал бы вам прочитать статью про работу AST (на ней работает большинство современных js-фреймворков, типа React, Vue, Svelte и другие): https://habr.com/ru/companies/ruvds/articles/415269/
Мы инициируем отправку атакуемому нами пользователю на его почту сообщения по сбросу паролю со стороны официального сервера программы, но при этом подменяем хост в урле на свой
Т.к. ссылку отправляет официальный сервер программы, то почтовый сервер помечает данное сообщение как доверенное (да и пользователь видит корректный валидный адрес отправителя, и верит данному сообщению на 100%), а токен сброса пароля генерируется на официальном сервере программы и является полностью действительным и рабочим
Пользователь переходит по нашей немного изменённой ссылке, которая ведёт уже на наш сервер, но при этом содержит реальный действительный токен для сброса пароля, сгенерированный официальным сервером программы - и мы в этот момент получаем этот токен
После этого наш скрипт на нашем сервере за секунду заходит на реальную страницу сброса пароля на официальном сервере программы, и, используя полученный токен для сброса пароля, меняет пароль атакуемого пользователя на свой, после чего получает полный доступ к аккаунту
В результате получение полного доступа к аккаунту происходит по одному нажатию пользователем на одну ссылку. Достаточно элегантно.
Да и это довольно частая ситуация, когда пользователь при получении ссылки на сброс пароля - переходит по ней, чтобы "сменить пароль на всякий случай".
Сейчас дизлайков нахватаю, но не могу не пошутить, что эти увольнения произошли ровно после того, как Таганский суд Москвы оштрафовал Mozilla Foundation на 3.5 млн рублей. Видимо, компания планирует заплатить.
А если серьёзно, то Firefox, наверное, один из немногих браузеров, которые ставят в приоритет приватность пользователей. Надеюсь, что на команду разработки эти события не сильно скажутся.
Сегодня столкнулся с той же проблемой после установки одного приложения. Я не уверен, что автор именно о нём говорил, но по описанию подходит:
Приложение для Android "К врачу", которое обеспечивает возможность записываться к врачам. Приложение очень нужное для пожилых людей, которым SuperApp "ГосУслуги" излишне, они там путаются, а тут - всё просто и удобно, не ошибёшься.
Что самое забавное, рейтинг у приложения за сутки опустился до 2.9 и продолжает падать. По комментариям понятно, что авторизация через ГосУслуги больше не работает (возможно, авторизация через WebView всё же запрещена, и их просто отключили за это нарушение от ГосУслуг).
Мне это напомнило, как лет 15 назад авторизацию во ВКонтакте для сторонних приложений разрешено было сделать через iframe. В то время столько аккаунтов утекло таким способом: просто делали страничку с той же вёрсткой и закидывали вместо оригинальной формы в этот злополучный iframe.
В Giga 2 нет Wi-Fi 5 ГГц, а 2.4 ГГц уже соседи захламили. Так что не вариант.
Но в своё время я был доволен им как слон: там сразу есть поддержка DLNA, Samba, FTP, Transmission Torrent Client, Apple Time Machine. Он и бэкапил мне данные с ноута по воздуху, и на телек транслировал скачанные сериалы/фильмы, кайф.
Мои pet-проекты рождаются из "боли" (какой-то проблемы, которая не имеет готового решения) или из лени делать что-то моторное и однотипное.
Например, когда меня стало напрягать заходить в приложение заметок из-за того, что там СЛИШКОМ много заметок, и когда ищешь нужную - глаз цепляется за другие постоянно - сделал для себя приложение заметок, где поиск только по тегам, и пока не введёшь нужный - ничего не отображается. Плюс потом туда синхронизацию между устройствами (телефон, комп, планшет) прикрутил для удобства с односторонним шифрованием на стороне устройств.
Или сделал себе бота для Telegram, который мониторит сериалы и фильмы из моего списка "Буду смотреть" с КиноПоиска и скидывает нотификацию при выходе новой серии/фильма в цифре (там ещё торренты и медиа-сервер участвуют, но не буду тут описывать).
Ну или в своё время перешли на работе с Jira на Trello, в котором в тот момент не было поддержи parent-child связей между тасками - написал экстеншен доя браузера, чтобы этот функционал добавить.
Могу ещё долго описывать свои проект, у меня их стабильно по 1-2 новых ежемесячно появляется. Но лучше основные требования к pet-проекту, чтобы не выгорать и не бросать их (выгорание от pet-проектов совсем не редкость, и в этом случае он просто забрасывается).
Чтобы не бросить pet-проект до его запуска я придерживаюсь следующим правилам:
Не тянуть с началом работы над ним. Нередко бывает, что загораешься идеей, а потом проходит неделя - и огня уже нет. Поэтому нужно стараться обязательно оценить, насколько сильно желание делать проект, и в зависимости от этого поставить даты, когда им займёшься.
Если над проектом работаешь один - его первую версию нужно сделать за выходные. На следующей неделе будет работа, к концу недели обязательно устанешь, мотивация возвращаться к проекту угаснет - поэтому, как говорится, "куй железо пока горячо", т.е.пока есть мотивация. Первая версия может включать только один маленький кусок функционала или проверку какой-то гипотезы - после неё руки сами понянуться пилить дальше. Но если первас версия будет огромных масштабов, на пару месяцев или хотя бы недель - проект для меня обречён. В лучшем случае я вернусь к нему через полгода, а в худшем - никогда.
Лучший вариант для большого проекта (на месяц и больше) - подключить к нему кого-то ещё, кому, как и тебе, будет не всё равно на этот проект. И важно в том случае созваниваться раз в неделю-две по нему и делиться своими апдейтами (что сделали, что планируете сделать в ближайшее время). Это очень мотивирует, когда ты видишь, что проект нужен не только тебе одному.
Временами на проектах любого уровня (и больших, и маленьких) случается выгорание (когда устал, и работать не хочется). Это нормально. В этом случае спокойно берите паузу на месяц, а потом продолжайте снова. У меня такое было слишком много раз (например, появилась идея нового проекта, которой я загорелся больше, или я просто устал). Но в 90% случаев после паузы я возвращался к проекту. А в 10% случаев понимал, что этот проект мне больше не нужен, и это тоже нормально.
Если проект планируется опубликовать для других - не надо долго заниматься его полировкой. Выпускайте черновую версию и получайте фидбэк как можно раньше. И у меня, и у моих знакомых обязательно есть проект, который делался очень долго, доведён до идеала - а в финале он оказался никому не нужен, или после первых отзывов пришлось переделывать его с нуля согласно пожеланиям. В этом случае руки так и наровят всё забросить и забыть о нём, как о страшном сне. Чтобы этого не было - не тяните с релизом черновой версии. Пользователи очень хорошо относятся к проектам с пометкой "альфа-версия, может работать не стабильно". Нередко мои проекты сразу после релиза содержат с десяток критических ошибок. Но о них я узнаю после фидбэка первых пользователей и сразу исправляю, после чего пользователи только благодарны.
Если проект изначально планируется делать коммерческим - то бизнес-модель нужно продумать ещё до его начала, при чём реально посчитав в Excel-табличке затраты и ожидаемую в пессимистичном сценарии прибыль. У меня есть 2 проекта, которые я делал с мыслью "Вот сделаю бесплатную версию, придут пользователи, а я тогда уже какой-то платный функционал введу и стану получать денежку". А потом была бесплатная версия, были пользователи, а платный функционал либо придумать не получилось, либо эти функции и не нужны никому. А делать часть бесплатных функций платными максимально негативно воспринимается пользователями, рейтинг приложения падает за несколько дней. Или была ситуация, что я свернул довольно популярный проект через полтора месяца после запуска, потому что сжирал он деньги быстро (на сервера, доп.ресурсы), а прибыли почти не было, и она не росла почти при постоянно большом притоке пользователей и, соответственно, увеличению трат.
Это не все правила. Если кому-то будет интересно - могу отдельной статьёй опубликовать более широкий список с более детальными примерами.
В статье не хватает сравнения с memo(). Как понимаю, afc выполняет схожую работу, но после прочтения я, если честно, не понял существенных различий между ними. Возможно, afc глубже работает с хуками?
Если хотите ускорить процесс — используйте for(let i = 0; i < yourArray.length; i++) {}
Это — самый быстрый вариант цикла: jsperf.com/fast-array-foreach
С тех пор (тест 2012-го года, но можно найти и тесты недельной давности — результат будет схожим) хоть и обещали оптимизировать forEach/map в V8-движке, но до сих пор весомых результатов так и не добились.
forEach/map — это удобно, но при их использовании приходится жертвовать производительностью. Сейчас с нынешними возможностями ПК и мобильных устройств это зачастую не критично, но на больших объёмах данных, где падение скорости выполнения цикла в 6 раз — критичный момент (вместо, например, 2-х секунд выполнения процесс обработки займёт 12), стоит пренебречь удобством в пользу скорости выполнения. То же касается и остальных функций, представленных в статье выше.
Прошу прощения, что придираюсь (да и это перевод, не здесь надо делать замечания), но хотелось бы хотя бы в комментарии добавить про forEach (а то про for..of написано, про map написано, а про forEach — нет). Плюс стоит упомянуть про reduceRight (хотя бы через слэш после reduce). И в одном из примеров по моему мнению не хватает второго необязательного аргумента для reduce, который задаёт начальное состояние результирующей переменной (часто использую).
Так Google официально призналась в американском суде, что они преднамеренно выдают некорректную выдачу, чтобы люди переходили на вторую, третью, четвёртую страницы выдачи, чтобы показать им больше рекламы (напомню: Google получает бо́льшую часть бюджета за счёт рекламы, и эта стратегия позволила им увеличить прибыль в несколько раз). Плюс они на первые страницы выдачи выводят исключительно сайты, где интегрированы сервисы Google (Google AdWords, Google Analytics и т.д.).
Так что VPN не спасёт. Google больше не работает так хорошо, как работал в 2019 и раньше.
А почему в санузле для включения вентилятора не поставили датчик влажности, а вместо него поставили датчик шума?
Оплатил Plex (единоразовый платёж, чтобы в мобильном приложении лишние попапы не выскакивали). Оплатил в Amazon Appstore (т.к. с оплатой в Google Play проблемы, сами знаете).
В результате, как только Amazon Appstore объявил о закрытии - ребята из Plex отказались переводить покупку на какую-нибудь другую площадку. При этом поддержка Amazon Appstore уверяла, что покупка бессрочная, и закрытие сервиса Amazon Appstore не является причиной отказа Plex от ответственности.
Ждём 20 августа, когда Amazon Appstore закроется, чтобы начать качать права у них на форуме
Простите, вы оказались абсолютно правы. Оказалось, что использование глубокой пересборки кода с помощью AST - это было только в моих мечтах. Насмотревшись на магию SvelteJS и аналогичных решений с построчной обработкой кода, я предполагал, что и в ReactJS эту же магию используют в компиляторе, а-ля:
->
Но в финале всё оказалось намного прозаичнее. Действительно, мы при каждом рендере создаём новую функцию внутри
useCallback. Как описывают это сами разработчики ReactJS:Наверное, это правильно с их стороны. Но в этом случае я теперь 100 раз подумаю, нужно ли мне использовать
useCallbackили нет.Вот пример, как проблему с пересозданием функции можно решить (может, кому-то это пригодится):
@winkyBrain@adminNiochenСпасибо, что мотивировали пойти и собственноручно разобраться в этом! А то бы до последнего в это верил, как дурак
В обычном JS - да, но в JSX (с переводом в AST) - новая функция не создаётся при каждом рендере, если зависимости не менялись.
Если коротко, то JSX - это просто формат файла, который к JS имеет очень косвенное отношение. Синтаксис похож на JS, но он не работает как JS. Из него сначала строится абстрактное синтаксическое дерево (AST), потом отдельный механизм в React обрабатывает каждую часть кода отдельно, и на основе этого уже строится JS. Поэтому привычные законы JS с ним не работают, там происходит очень много магии под капотом при компиляции.
Я в комментарии ниже подробнее описал, не буду здесь дублировать.
Простите, но вы не правы. Ваши доводы логичны, но вы упускаете одну важную деталь, из-за чего все ваши выводы неверны.
useCallbackзапускается не в чистом JS, а в JSX. А если быть точнее, проходит через транспиляцию в AST (абстрактное синтаксическое дерево), и далее React работает уже с ним. И это касается не только дерева элементов вreturn, но и всего кода внутри функции компонента (включая и все хуки).Достаточно простое доказательство этого - это новая версия React, в которой, как пообещали разработчики,
useCallbackписать не потребуется, ко функциям внутри компонента будет автоматически применяться мемоизация на основании анализа кода компилятором.Также вы можете посмотреть скомпилированный в JS код, и вы там увидите, что функция из
useCallbackна самом деле находится за пределами функции компонента и перезаписывается там же (советую включить в React компиляцию компонентов по отдельным бандлам, чтобы проще было читать код, не было лишней логики).Я рекомендовал бы вам прочитать статью про работу AST (на ней работает большинство современных js-фреймворков, типа React, Vue, Svelte и другие): https://habr.com/ru/companies/ruvds/articles/415269/
Я думаю, тут речь о другом.
Цепочка действий:
Мы инициируем отправку атакуемому нами пользователю на его почту сообщения по сбросу паролю со стороны официального сервера программы, но при этом подменяем хост в урле на свой
Т.к. ссылку отправляет официальный сервер программы, то почтовый сервер помечает данное сообщение как доверенное (да и пользователь видит корректный валидный адрес отправителя, и верит данному сообщению на 100%), а токен сброса пароля генерируется на официальном сервере программы и является полностью действительным и рабочим
Пользователь переходит по нашей немного изменённой ссылке, которая ведёт уже на наш сервер, но при этом содержит реальный действительный токен для сброса пароля, сгенерированный официальным сервером программы - и мы в этот момент получаем этот токен
После этого наш скрипт на нашем сервере за секунду заходит на реальную страницу сброса пароля на официальном сервере программы, и, используя полученный токен для сброса пароля, меняет пароль атакуемого пользователя на свой, после чего получает полный доступ к аккаунту
В результате получение полного доступа к аккаунту происходит по одному нажатию пользователем на одну ссылку. Достаточно элегантно.
Да и это довольно частая ситуация, когда пользователь при получении ссылки на сброс пароля - переходит по ней, чтобы "сменить пароль на всякий случай".
Сейчас дизлайков нахватаю, но не могу не пошутить, что эти увольнения произошли ровно после того, как Таганский суд Москвы оштрафовал Mozilla Foundation на 3.5 млн рублей. Видимо, компания планирует заплатить.
А если серьёзно, то Firefox, наверное, один из немногих браузеров, которые ставят в приоритет приватность пользователей. Надеюсь, что на команду разработки эти события не сильно скажутся.
Более наглядное исключение - доменная зона .su
Сегодня столкнулся с той же проблемой после установки одного приложения. Я не уверен, что автор именно о нём говорил, но по описанию подходит:
Приложение для Android "К врачу", которое обеспечивает возможность записываться к врачам. Приложение очень нужное для пожилых людей, которым SuperApp "ГосУслуги" излишне, они там путаются, а тут - всё просто и удобно, не ошибёшься.
Что самое забавное, рейтинг у приложения за сутки опустился до 2.9 и продолжает падать. По комментариям понятно, что авторизация через ГосУслуги больше не работает (возможно, авторизация через WebView всё же запрещена, и их просто отключили за это нарушение от ГосУслуг).
Мне это напомнило, как лет 15 назад авторизацию во ВКонтакте для сторонних приложений разрешено было сделать через iframe. В то время столько аккаунтов утекло таким способом: просто делали страничку с той же вёрсткой и закидывали вместо оригинальной формы в этот злополучный iframe.
В Giga 2 нет Wi-Fi 5 ГГц, а 2.4 ГГц уже соседи захламили. Так что не вариант.
Но в своё время я был доволен им как слон: там сразу есть поддержка DLNA, Samba, FTP, Transmission Torrent Client, Apple Time Machine. Он и бэкапил мне данные с ноута по воздуху, и на телек транслировал скачанные сериалы/фильмы, кайф.
Мои pet-проекты рождаются из "боли" (какой-то проблемы, которая не имеет готового решения) или из лени делать что-то моторное и однотипное.
Например, когда меня стало напрягать заходить в приложение заметок из-за того, что там СЛИШКОМ много заметок, и когда ищешь нужную - глаз цепляется за другие постоянно - сделал для себя приложение заметок, где поиск только по тегам, и пока не введёшь нужный - ничего не отображается. Плюс потом туда синхронизацию между устройствами (телефон, комп, планшет) прикрутил для удобства с односторонним шифрованием на стороне устройств.
Или сделал себе бота для Telegram, который мониторит сериалы и фильмы из моего списка "Буду смотреть" с КиноПоиска и скидывает нотификацию при выходе новой серии/фильма в цифре (там ещё торренты и медиа-сервер участвуют, но не буду тут описывать).
Ну или в своё время перешли на работе с Jira на Trello, в котором в тот момент не было поддержи parent-child связей между тасками - написал экстеншен доя браузера, чтобы этот функционал добавить.
Могу ещё долго описывать свои проект, у меня их стабильно по 1-2 новых ежемесячно появляется. Но лучше основные требования к pet-проекту, чтобы не выгорать и не бросать их (выгорание от pet-проектов совсем не редкость, и в этом случае он просто забрасывается).
Чтобы не бросить pet-проект до его запуска я придерживаюсь следующим правилам:
Не тянуть с началом работы над ним. Нередко бывает, что загораешься идеей, а потом проходит неделя - и огня уже нет. Поэтому нужно стараться обязательно оценить, насколько сильно желание делать проект, и в зависимости от этого поставить даты, когда им займёшься.
Если над проектом работаешь один - его первую версию нужно сделать за выходные. На следующей неделе будет работа, к концу недели обязательно устанешь, мотивация возвращаться к проекту угаснет - поэтому, как говорится, "куй железо пока горячо", т.е.пока есть мотивация. Первая версия может включать только один маленький кусок функционала или проверку какой-то гипотезы - после неё руки сами понянуться пилить дальше. Но если первас версия будет огромных масштабов, на пару месяцев или хотя бы недель - проект для меня обречён. В лучшем случае я вернусь к нему через полгода, а в худшем - никогда.
Лучший вариант для большого проекта (на месяц и больше) - подключить к нему кого-то ещё, кому, как и тебе, будет не всё равно на этот проект. И важно в том случае созваниваться раз в неделю-две по нему и делиться своими апдейтами (что сделали, что планируете сделать в ближайшее время). Это очень мотивирует, когда ты видишь, что проект нужен не только тебе одному.
Временами на проектах любого уровня (и больших, и маленьких) случается выгорание (когда устал, и работать не хочется). Это нормально. В этом случае спокойно берите паузу на месяц, а потом продолжайте снова. У меня такое было слишком много раз (например, появилась идея нового проекта, которой я загорелся больше, или я просто устал). Но в 90% случаев после паузы я возвращался к проекту. А в 10% случаев понимал, что этот проект мне больше не нужен, и это тоже нормально.
Если проект планируется опубликовать для других - не надо долго заниматься его полировкой. Выпускайте черновую версию и получайте фидбэк как можно раньше. И у меня, и у моих знакомых обязательно есть проект, который делался очень долго, доведён до идеала - а в финале он оказался никому не нужен, или после первых отзывов пришлось переделывать его с нуля согласно пожеланиям. В этом случае руки так и наровят всё забросить и забыть о нём, как о страшном сне. Чтобы этого не было - не тяните с релизом черновой версии. Пользователи очень хорошо относятся к проектам с пометкой "альфа-версия, может работать не стабильно". Нередко мои проекты сразу после релиза содержат с десяток критических ошибок. Но о них я узнаю после фидбэка первых пользователей и сразу исправляю, после чего пользователи только благодарны.
Если проект изначально планируется делать коммерческим - то бизнес-модель нужно продумать ещё до его начала, при чём реально посчитав в Excel-табличке затраты и ожидаемую в пессимистичном сценарии прибыль. У меня есть 2 проекта, которые я делал с мыслью "Вот сделаю бесплатную версию, придут пользователи, а я тогда уже какой-то платный функционал введу и стану получать денежку". А потом была бесплатная версия, были пользователи, а платный функционал либо придумать не получилось, либо эти функции и не нужны никому. А делать часть бесплатных функций платными максимально негативно воспринимается пользователями, рейтинг приложения падает за несколько дней. Или была ситуация, что я свернул довольно популярный проект через полтора месяца после запуска, потому что сжирал он деньги быстро (на сервера, доп.ресурсы), а прибыли почти не было, и она не росла почти при постоянно большом притоке пользователей и, соответственно, увеличению трат.
Это не все правила. Если кому-то будет интересно - могу отдельной статьёй опубликовать более широкий список с более детальными примерами.
В статье не хватает сравнения с
memo(). Как понимаю,afcвыполняет схожую работу, но после прочтения я, если честно, не понял существенных различий между ними. Возможно,afcглубже работает с хуками?for(let i = 0; i < yourArray.length; i++) {}Это — самый быстрый вариант цикла:
jsperf.com/fast-array-foreach
С тех пор (тест 2012-го года, но можно найти и тесты недельной давности — результат будет схожим) хоть и обещали оптимизировать forEach/map в V8-движке, но до сих пор весомых результатов так и не добились.
forEach/map — это удобно, но при их использовании приходится жертвовать производительностью. Сейчас с нынешними возможностями ПК и мобильных устройств это зачастую не критично, но на больших объёмах данных, где падение скорости выполнения цикла в 6 раз — критичный момент (вместо, например, 2-х секунд выполнения процесс обработки займёт 12), стоит пренебречь удобством в пользу скорости выполнения. То же касается и остальных функций, представленных в статье выше.
Прошу прощения, что придираюсь (да и это перевод, не здесь надо делать замечания), но хотелось бы хотя бы в комментарии добавить про forEach (а то про for..of написано, про map написано, а про forEach — нет). Плюс стоит упомянуть про reduceRight (хотя бы через слэш после reduce). И в одном из примеров по моему мнению не хватает второго необязательного аргумента для reduce, который задаёт начальное состояние результирующей переменной (часто использую).