Esto es 2014 y un par de años demasiado tarde. Todavía creo que mi punto es válido:
En mi humilde opinión, esta discusión se volvió bastante desproporcionada. Citando la publicación del blog antes mencionada :
La mayoría de las bibliotecas de utilidades de JavaScript, como Underscore, Valentine y wu, se basan en el "enfoque dual nativo-primero". Este enfoque prefiere implementaciones nativas, recurriendo a JavaScript vainilla solo si el equivalente nativo no es compatible. Pero jsPerf reveló una tendencia interesante: la forma más eficiente de iterar sobre una matriz o colección tipo matriz es evitar las implementaciones nativas por completo, optando por bucles simples.
Como si "bucles simples" y "Javascript vainilla" fueran más nativos que las implementaciones de métodos Array u Object. Dios ...
Ciertamente sería bueno tener una sola fuente de verdad, pero no la hay. Incluso si te han dicho lo contrario, no hay Dios de vainilla, querida. Lo siento. La única suposición que realmente se cumple es que todos estamos escribiendo código Javascript que tiene como objetivo un buen desempeño en todos los principales navegadores, sabiendo que todos ellos tienen implementaciones diferentes de las mismas cosas. Es una perra con la que lidiar, por decirlo suavemente. Pero esa es la premisa, te guste o no.
¡Quizás estén trabajando en proyectos a gran escala que necesitan un rendimiento de Twitter para que realmente vean la diferencia entre 850,000 (subrayado) y 2,500,000 (lodash) iteraciones en una lista por segundo en este momento!
Yo por mi parte no lo soy. Quiero decir, trabajé en proyectos donde tenía que abordar problemas de rendimiento, pero nunca fueron resueltos ni causados por Underscore ni Lo-Dash. Y a menos que comprenda las diferencias reales en la implementación y el rendimiento (estamos hablando de C ++ en este momento) de, digamos, un bucle sobre un iterable (objeto o matriz, disperso o no), prefiero no molestarme con ninguno afirmaciones basadas en los resultados de una plataforma de referencia que ya es obstinada .
Solo necesita una única actualización de, digamos, Rhino para prender fuego a sus implementaciones de métodos Array de tal manera que ni un solo "método de bucle medieval funcione mejor y para siempre", y el sacerdote puede discutir sobre el simple hecho de que todos Los métodos de matriz repentina en FF son mucho más rápidos que su mentalidad obstinada. Hombre, ¡no puedes engañar a tu entorno de ejecución engañando a tu entorno de ejecución! Piensa en eso al promocionar ...
su cinturón utilitario
... la próxima vez.
Entonces, para mantenerlo relevante:
- Utilice el subrayado si le gusta la comodidad sin sacrificar el ish nativo.
- Use Lo-Dash si le gusta la comodidad y le gusta su catálogo extendido de características (copia profunda, etc.) y si necesita desesperadamente un rendimiento instantáneo y lo más importante no le importa conformarse con una alternativa tan pronto como la API nativa eclipse obstinados fondos de trabajo. Lo que va a suceder pronto. Período.
- Incluso hay una tercera solución. Bricolaje! Conoce tus ambientes. Sepa sobre inconsistencias. Lea su código (de John-David y Jeremy ). No use esto o aquello sin poder explicar por qué una capa de consistencia / compatibilidad es realmente necesaria y mejora su flujo de trabajo o el rendimiento de su aplicación. Es muy probable que sus requisitos se cumplan con un simple polyfill que puede escribir usted mismo perfectamente. Ambas bibliotecas son simplemente vainilla con un poco de azúcar. Ambos pelean por quién sirve el pastel más dulce . Pero créanme, al final ambos solo están cocinando con agua. No hay Dios de vainilla, así que no puede haber papa de vainilla, ¿verdad?
Elija el enfoque que mejor se adapte a sus necesidades. Como siempre. Preferiría fallos en implementaciones reales en lugar de trucos de tiempo de ejecución obstinados en cualquier momento, pero incluso eso parece ser cuestión de gustos hoy en día. Apéguese a recursos de calidad como http://developer.mozilla.com y http://caniuse.com y estará bien.
