Só pra aprofundar um pouco cada item (que para quem ainda não percebeu, são todos irônicos), e complementar o que já foi dito em outros comentários:
for vs map/reduce/forEach/etc
De fato tenho visto muitos "cursos" e influencers que adoram propagar o uso de map, reduce e forEach pra tudo, e ignoram completamente o bom e velho for. Assim como há os que dizem pra nunca usar. Eu diria, como sempre, que depende. Cada um tem seus prós e contras e casos de uso em que é mais adequado (aliás, esta regra vale para todos os itens, e de forma mais geral, para praticamente tudo em computação).
Um ponto importante sobre map, reduce e forEach é que estes recebem como argumento um callback (uma função, que será executada para cada elemento do array). Ou seja, se o array tem N elementos, o callback será chamado N vezes. E chamadas de função têm o seu custo. Pode não ser significante se forem poucos arrays pequenos, mas não é zero.
Neste post eu faço um comparativo entre reduce e for, usando um array bem grande, e a diferença é clara: reduce foi bem mais lento. Mas para arrays menores a diferença será irrisória, então como sempre depende de cada caso.
Sobre os demais: map serve para fazer algo com os elementos do array, e sempre retorna outro array com os resultados (mesmo que vc não use, ele é criado e retornado). Então se não precisa deste array com os resultados, não deveria usar map (embora "funcione", é um uso torto). Talvez um forEach fosse mais adequado, embora ele não possa ser interrompido com break (neste caso um for simples é o mais adequado, para não ter que fazer essas gambiarras).
Ou seja, cada caso é um caso. Nem oito nem oitenta, entenda o que cada opção faz, seus prós e contras, e escolha a mais adequada para cada situação (e essa dica não se restringe a este item, vale pra tudo na nossa área).
if/else vs early return
Mais um caso de "depende", de entender o que cada um faz, saber os prós e contras, e escolher o mais adequado para cada caso. Além de saber os casos em que tanto faz e passa a ser gosto pessoal (é importante reconhecer isso também, pra não confundir preferências com verdades absolutas).
Teve um post recente sobre early return, e também tem outros mais antigos (esse e esse). De fato é uma técnica que pode ser útil em muitos casos, mas como sempre, não é a bala de prata que sempre deve ser usada pra tudo.
Eu pessoalmente não gosto desses artigos que propagam uma técnica como sendo "a verdade", que deve ser usado "sempre" sem exceções. Muitas vezes eles usam como exemplos somente os casos em que ela é a melhor opção, mas esquecem de mencionar os casos em que ela atrapalha. Daí a quantidade de artigos sensacionalistas do tipo "Não use else". Use sim, sempre que fizer sentido.
for vs while
Dizer que um é mais rápido que outro chega a ser piada, na maioria das vezes não fará diferença significativa.
Pra variar, é mais um caso de saber as características de cada um. Muitas vezes tanto faz usar um ou outro, mas tem alguns casos em que faz diferença. Tem uma boa explicação aqui, mas seguem alguns exemplos abaixo (todos em JavaScript).
No while vc pode controlar quando o incremento ocorre:
var i = 0;
while (i < 10) {
if (alguma_condição) {
continue;
}
i++;
}
E vc pode inclusive ter incrementos diferentes dependendo de cada caso:
var i = 0;
while (i < 100) {
if (alguma_condição) {
i += 3;
} else if (outra_condição) {
i += 15;
} else {
i++;
}
}
Com for seria bem mais complicado...
No for vc pode inicializar e incrementar mais de uma variável:
for (var i = 0, j = 20; i < 10; i++, j++) {
}
Ok, no while também daria pra fazer algo do tipo:
var i = 0, j = 20;
while (i < 10) {
i++, j++;
}
Mas não fica tão "limpo" e idiomático, na minha opinião.
E o while costuma ser mais adequado quando vc não precisa de alguma(s) das 3 etapas do for:
var regex = /[0-9]/g;
var texto = 'a1b2c3d4';
var match;
while ((match = regex.exec(texto)) !== null) {
console.log(match[0]);
}
Até dá pra fazer um for equivalente:
var regex = /[0-9]/g;
var texto = 'a1b2c3d4';
var match;
for (; (match = regex.exec(texto)) !== null; ) {
console.log(match[0]);
}
Afinal, todas as 3 seções do for são opcionais, então basta omitir duas delas. Mas não fica tão "limpo" quando um while, na minha opinião.
Enfim, esses deveriam ser os motivos para optar por um ou outro (novamente, é sobre saber as características de cada um e escolher o mais adequado para cada caso, inclusive sabendo os casos em que tanto faz). Não tem nada a ver com um deles ser "mais rápido".
isEven
Esta é claramente uma crítica aos pacotes inúteis do npm, como o is-even pra ver se um número é par. Pior, este pacote depende de outro igualmente inútil: o is-odd pra ver se o número é ímpar. Sério, olha o código do is-even:
var isOdd = require('is-odd');
module.exports = function isEven(i) {
return !isOdd(i);
};
E o is-odd, por sua vez, tem outra dependência: o pacote is-number, para ver se o valor informado é um número. Três pacotes só pra ver se um número é par...
Nem tudo precisa de um pacote/lib/dependência. Operações simples como ver se um número é par podem ser feitas diretamente, sem firulas. Coisas triviais não deveriam precisar disso, inclusive essa mania de criar dependências pra tudo resultou no famoso caso do leftpad.
function vs arrow function
Tenho notado em muitos projetos uma certa preferência por arrow function, a tal ponto que - pelo menos é a impressão que tenho - muita gente parece achar que elas são "O Jeito Certo™", ou a única opção existente.
Mas existem diferenças entre function e arrow function, explicadas em detalhes aqui e aqui.
Novamente, mais um caso de saber as diferenças, os prós e contras de cada um, e escolher conforme a necessidade (além de saber as situações em que tanto faz, e estar ciente que nesses casos usou por preferência pessoal).
ChatGPT
Já tem trocentos posts aqui e internet afora sobre o assunto. Pra resumir, acho que é uma ferramenta que deve ser usada com ressalvas (como qualquer outra). Tenho um post com links que explicam em detalhes como ele funciona, e porque ele deve ser tratado como um estagiário burro porém esforçado e confiante, e que vc não deve acreditar cegamente em tudo que ele diz (sempre confira o código que ele te dá).