map/filter/reduce часто выглядят «чище», чем for/while. Но чистый синтаксис сам по себе не делает решение ни быстрее, ни надёжнее.

Функциональный стиль действительно силён в этих случаях 👇

❗️ Шаги линейные и независимые. ❗️ Преобразования декларативны и легко тестируются по отдельности. ❗️ Пайплайн нужно переиспользовать в нескольких местах. ❗️ Стоимость промежуточных структур не критична.

Императивный код выигрывает в другой зоне 👇

❗️ Нужен ранний выход (break/return) и контроль потока. ❗️ Несколько аккумуляторов собираются за один проход. ❗️ Важно минимизировать аллокации и давление на сборщик мусора. ❗️ Есть ветвления, состояния, короткие пути и исключения.

Самая частая ошибка, на мой взгляд, превращать reduce в универсальный «DSL для всего». В итоге читаемость падает, логика упакована в один callback, который одновременно фильтрует, маппит, агрегирует и мутирует состояние.

Ещё одна практическая ловушка - каскад из filter().map().flatMap() на горячем пути. Да, код красивый. Но это несколько проходов + промежуточные массивы + лишняя работа сборщика мусора.

Инженерный критерий выбора простой: какой вариант даёт более прозрачную модель вычисления и меньшую цену сопровождения через N месяцев.

Не «функциональный 🆚 императивный». Лучше так: декларативность там, где она уменьшает сложность; явный контроль там, где он снижает риски и стоимость выполнения. #js