Questo è il 2014 e un paio d'anni in ritardo. Penso ancora che il mio punto valga:
IMHO questa discussione è stata sproporzionata abbastanza. Citando il suddetto post sul blog :
La maggior parte delle librerie di utilità JavaScript, come Underscore, Valentine e wu, si basano sul "doppio approccio nativo". Questo approccio preferisce le implementazioni native, tornando a JavaScript vanilla solo se l'equivalente nativo non è supportato. Ma jsPerf ha rivelato una tendenza interessante: il modo più efficiente di scorrere su una raccolta array o simile a una matrice è evitare completamente le implementazioni native, optando invece per semplici loop.
Come se "semplici loop" e "vanilla Javascript" siano più nativi delle implementazioni del metodo Array o Object. Accidenti ...
Sarebbe certamente bello avere un'unica fonte di verità, ma non lo è. Anche se ti è stato detto diversamente, non c'è Dio alla vaniglia, mio caro. Mi dispiace. L'unico presupposto che vale davvero è che stiamo tutti scrivendo codice Javascript che mira a funzionare bene in tutti i principali browser, sapendo che tutti hanno implementazioni diverse delle stesse cose. È una stronza da affrontare, per dirla in modo lieve. Ma questa è la premessa, che ti piaccia o no.
Forse state lavorando a progetti su larga scala che necessitano di prestazioni ottimistiche in modo da vedere davvero la differenza tra 850.000 (trattino basso) e 2.500.000 (lodash) iterazioni su un elenco al secondo in questo momento!
Io per primo non lo sono. Voglio dire, ho lavorato a progetti in cui dovevo affrontare problemi di performance, ma non sono mai stati risolti o causati da Underscore o Lo-Dash. E a meno che non riesca a comprendere le reali differenze nell'implementazione e nelle prestazioni (stiamo parlando C ++ in questo momento) di diciamo un ciclo su un iterabile (oggetto o array, scarso o no!), Preferisco non preoccuparmi di alcun affermazioni basate sui risultati di una piattaforma di benchmark già considerata .
Ha solo bisogno di un singolo aggiornamento di diciamo a Rhino di dare fuoco alle sue implementazioni del metodo Array in un modo che non un singolo "metodo del ciclo medievale funziona meglio e per sempre e quant'altro" il sacerdote può discutere il suo semplice fatto che tutti un improvviso metodo di array in FF è molto più veloce del suo cervello immaginato. Amico, non puoi semplicemente imbrogliare il tuo ambiente di runtime truffando il tuo ambiente di runtime! Pensaci quando promuovi ...
la tua cintura di utilità
... la prossima volta.
Quindi, per mantenerlo rilevante:
- Usa Underscore se sei a tuo agio senza sacrificare l'ish nativo.
- Usa Lo-Dash se sei a tuo agio e ti piace il suo catalogo di funzioni estese (copia profonda ecc.) E se hai un disperato bisogno di prestazioni istantanee e, soprattutto, non ti dispiace accontentarti di un'alternativa non appena il outshine dell'API nativa workauround supponente. Che succederà presto. Periodo.
- C'è anche una terza soluzione. FAI DA TE! Conosci i tuoi ambienti. Conoscere le incongruenze. Leggi il loro codice ( John-David e Jeremy ). Non utilizzare questo o quello senza essere in grado di spiegare perché un livello di coerenza / compatibilità è davvero necessario e migliora il flusso di lavoro o migliora le prestazioni della tua app. È molto probabile che le tue esigenze siano soddisfatte con un semplice polyfill che sei perfettamente in grado di scrivere da solo. Entrambe le biblioteche sono semplicemente vaniglia con un po 'di zucchero. Entrambi litigano per chi sta servendo la torta più dolce . Ma credimi, alla fine entrambi cucinano solo con acqua. Non c'è Dio alla vaniglia, quindi non può esserci papa alla vaniglia, giusto?
Scegli l'approccio più adatto alle tue esigenze. Come di solito. Preferirei i fallback sulle implementazioni effettive rispetto ai cheat di runtime presunti in qualsiasi momento, ma anche oggi sembra essere una questione di gusti. Attenersi a risorse di qualità come http://developer.mozilla.com e http://caniuse.com e andrà tutto bene.