В чём прикол использования Map (и прочих подобных) в JS против for?
Часто вижу, что более молодые программисты используют только map (и прочие подобные) вместо for. Причём очень негодуют когда видят for, говорят, что это устаревшая техника и пережиток прошлого. При этом, map невозможно остановить, он будет проходить до конца массива, даже если тебе это не нужно. Но они походу лепят это просто для красоты или даже не понимают что пишут. Хотя иногда говорят: ну и что, главное что это более читабельно, а так это ерунда по нагрузке. При этом у них раз ерунда, два ерунда, а потом ерунда получается по производительности когда накапливается много такой ерунды.
Какое ваше мнение на этот счёт?
Функция все же несколько иная по типу действия и как следствие применимости, нежели чем for. Основное и самое главное отличие, это новый-независимый контекст работы с элементом массива при каждом проходе(функция обратного вызова), с моментальным сбором результатов в новый массив. Да, в for все это тоже можно организовать, но кода потребуется несколько больше, а тут получается очень кратко. И еще, при переборе массива, не нужно указывать индекс элемента массива, как это делается в for. В общем map действительно хорош, но применять его понятное дело надо там - где это уместно.
Также в условиях решения одинаковой задачи(простого перебора массива):
+ Быстрое написание кода
+ Код более читабелен, в том числе теми кто будет потом работать с вашим творением
И еще, при переборе массива, не нужно указывать индекс элемента массива, как это делается в for.
Что не позволяет сравнить значение с предыдущим ведь :)
Если полная обработка массива (и то, только одного значения), то вполне уместно, но во всех остальных случаях...
SEOD, Да for позволяет больше. Но речь не о том, какой инструмент более универсален, а об особенностях того или иного, и о том почему применяют собственно map, а применяют его там - где очевидно его функционала достаточно.
SEOD, Окупается с лихвой во времени чтения и разбора кода программистом. Выше уровень абстракции — меньше времени на чтение кода. Вы пишите о ресурсах системы, но забываете о человеческом ресурсе, который на сей день гораздо важнее! Сетуете на "молодых программистов", что мол они не понимают, что пишут. Но, создается впечатление, что вы как раз не поняли саму философию разработки, по чести отношения к человеческим ресурсам — все улучшения ЯП, непременно сводятся к экономии в первую очередь именно их. Советую прочитать "Совершенный код — С. Макконнелл"
П.С,, также с чего вы вообще взяли что map ест ресурсов больше чем тот же for, при выполнении одинаковой задачи — перебор всего массива с сохранением результата в новый?
Если нужна остановка цикла - можно использовать some, если нужен именно map с остановкой цикла - тут следует использовать for либо какую-нить либу, которая это умеет.
Если эти некие "они" с оверхедом используют обычный map там где должен быть прерван цикл или там где не нужно получения нового массива - они говнокодеры.
Если вы используете классический for там где идеально справился бы map - вы старпёр, бессмысленно раздувающий и усложняющий код.
А производительность надо оптимизировать там и только там, где надо оптимизировать производительность.
Так с другой стороны, пока код находится в процессе разработки, логика меняется. Там где "идеально бы справился map" - может не справиться и его придётся исправлять на другой. А for универсально работает везде.
Я бы тут на личности не стал переходить. И сказал бы обратно, что кто-то может слишком чайник, что юзает их. Покуда for-овый код легко переносится с языка на язык, к тому же, он реально независимый, потому что эти конструкции во многих языках есть. В случае с map придётся попотеть при портировании такого кода. Так почему бы не писать сразу такой код, который легко переносится и работает производительнее везде?
На "говнокодеров" вот вы не среагировали, потому что считаете это верным. Так вот: как "говнокодеры" верно к противоположному лагерю, так и "старпёры" верно к вашему. Я не хочу никого оскорбить, это просто реальное положение дел: привычка к "проверенным методам" и нежелание меняться.
for-овый код легко переносится с языка на язык
Что не имеет никакого (абсолютно) применения в front-end разработке.
работает производительнее
На самом деле прирост производительности минимален, все браузеры прекрасно оптимизируют встроенные методы. К тому же преждевременная оптимизация - вредная практика, оптимизировать надо исключительно узкие места уже после написания аккуратного кода. А если уж очень хочется - всегда можно настроить babel чтоб он транспилировал все методы массивов прямо в for и радоваться.
Нет ни единой объектовой приличны использовать for вместо методов массива, зато объективные против имеются: увеличивается количество ненужного кода, увеличивается шанс на ошибку.
