Estamos em 2014 e dois anos tarde demais. Ainda acho que meu argumento é válido:
IMHO esta discussão ficou fora de proporção um pouco. Citando a postagem do blog acima mencionada :
A maioria das bibliotecas de utilitários JavaScript, como Underscore, Valentine e wu, conta com a "abordagem dual nativa em primeiro lugar". Essa abordagem prefere implementações nativas, voltando ao JavaScript básico somente se o equivalente nativo não for suportado. Mas o jsPerf revelou uma tendência interessante: a maneira mais eficiente de iterar sobre uma matriz ou coleção semelhante a uma matriz é evitar completamente as implementações nativas, optando por loops simples.
Como se "loops simples" e "Javascript vanilla" fossem mais nativos que as implementações de métodos Array ou Object. Eita ...
Certamente seria bom ter uma única fonte de verdade, mas não existe. Mesmo que você tenha dito o contrário, não há Deus Vanilla, minha querida. Eu sinto Muito. A única suposição que realmente vale é que todos nós estamos escrevendo código Javascript que visa ter um bom desempenho em todos os principais navegadores, sabendo que todos eles têm implementações diferentes das mesmas coisas. É uma merda lidar com isso, para dizer o mínimo. Mas essa é a premissa, goste ou não.
Talvez vocês estejam trabalhando em projetos de grande escala que precisam de desempenho twitterish, para que você realmente veja a diferença entre 850.000 (sublinhado) vs. 2.500.000 (lodash) iterações em uma lista por segundo agora!
Eu, pelo menos não sou. Quero dizer, trabalhei em projetos nos quais tinha que resolver problemas de desempenho, mas eles nunca foram resolvidos ou causados por Underscore nem Lo-Dash. E, a menos que eu compreenda as diferenças reais de implementação e desempenho (estamos falando de C ++ agora), digamos um loop sobre um iterável (objeto ou matriz, esparso ou não!), Prefiro não me incomodar com nenhum reivindicações com base nos resultados de uma plataforma de benchmark que já é opinativa .
Ele precisa apenas de uma única atualização, digamos que o Rhino ative suas implementações do método Array de uma maneira que nem um único "método medieval de loop tenha um desempenho melhor e para sempre e outros" sacerdotes possam argumentar sobre o simples fato de que todos Os métodos de matriz repentina na FF são muito mais rápidos do que o seu cérebro opinativo. Cara, você simplesmente não pode enganar seu ambiente de execução enganando seu ambiente de execução! Pense nisso ao promover ...
seu cinto de utilidades
... próxima vez.
Portanto, para mantê-lo relevante:
- Use Sublinhado se preferir, sem sacrificar o ish nativo.
- Use o Lo-Dash se você gosta de conveniência e gosta do catálogo de recursos estendido (cópia detalhada etc.) e se precisa desesperadamente de desempenho instantâneo e, o mais importante, não se importa em optar por uma alternativa assim que a API nativa ofuscar soluções alternativas opinativas. O que acontecerá em breve. Período.
- Existe até uma terceira solução. FAÇA VOCÊ MESMO! Conheça seus ambientes. Saiba sobre inconsistências. Leia o código deles (de John-David e Jeremy ). Não use isso ou aquilo sem poder explicar por que uma camada de consistência / compatibilidade é realmente necessária e aprimorar seu fluxo de trabalho ou melhorar o desempenho do seu aplicativo. É muito provável que seus requisitos sejam satisfeitos com um polyfill simples que você possa perfeitamente escrever. Ambas as bibliotecas são simplesmente baunilha com um pouco de açúcar. Os dois brigam por quem está servindo a torta mais doce . Mas acredite, no final, ambos estão apenas cozinhando com água. Não existe Deus da baunilha, então não pode haver Papa da baunilha, certo?
Escolha a abordagem que melhor atenda às suas necessidades. Como sempre. Eu preferiria fallbacks em implementações reais do que truques opinativos de tempo de execução a qualquer momento, mas mesmo isso parece ser uma questão de gosto hoje em dia. Atenha-se a recursos de qualidade como http://developer.mozilla.com e http://caniuse.com e você ficará bem.
