Why are Javascript libraries like LoDash or UnderScore used more often than raw JS functions like map, minify or filtering
I tend to find the libraries listed are used more often when direct JS functions did the job. I would believe that loading additional libraries always adds more load time, so I'm curious why raw JS functions aren't used more often.
Are there any speed advantages for pure JS-only functions in the language over post-written helper functions?
Wouldn't the advantage of a pre-built library be lost when loading an additional library load?
source to share
Usually using a framework on top of raw JS is interoperable. There are differences in Javascript between browsers, between different browser versions, and some implementations are incomplete. A tool like underscore and the like helps iron out compatibility issues by providing a common layer between your code and raw JS.
If you can rule out the possibility of having different browsers, then be sure to go ahead and do Raw JS, but you end up saving yourself a lot of hassle down the road.
source to share
Three main reasons why I turn to lodash ...
Functions
Yes, there are some overlaps between what JavaScript primitives can do and what lodash can do. For me, at least, it's not just a question of which implementation is map()
better, or which implementation is reduce()
better, and so on. If all you do is render and minify, then lodash doesn't really matter.
If your building has a medium to large size application, on the other hand, you are probably doing a lot more with your data. This lodash area is shining. This gives me everything I need in a very granular form. Granularity matters because it means I can select and combine the parts I want. I could do a lot in myself using my own methods, but why do that when the code is already written for me?
Performance
Lodash works well. Perhaps as well as browser primitives or better in some cases. It doesn't matter, the performance gain is negligible for simple comparisons.
Big performance gains come not from micro-benchmarking, but in real life, where there is a lot of code and a lot of data. Lodash's performance mantra is optimized for the normal case. Lodash does it all over the place.
For example, a more general, more efficient path is tested first in any given function. Slow paths move to the bottom of the function. They can afford to be slow because they are unusual. These checks have a huge cumulative effect in real-world applications.
I believe lodash performance should be consistent when I work on collections because it uses the same iteration techniques for all functions that involve iterating over a collection. So I am not worried about one function being inherently slower than another because it does things differently. Differences are minute and also performance characteristics.
Lodash is also looking at JavaScript JIT and taking steps to make sure internal functions do not incur optimization penalties.
John-David Dalton has a great talk about lodash performance.
Improved code
Because of all the open source features, I am constantly finding ways to improve my code. Often, function calls are ripped out and replaced with another strategy that uses less code.
I find that lodash, especially chained calls, makes it easier to improve on existing code. If I have to write all of these utilities myself, it probably won't be as nifty as the lodash version.
The granularity of the lodash API is forcing me to rethink everything I do as I do it, which is pretty nice.
source to share