I understand why, and once upon a time I was the guy who would commit code where I replaced jQuery and underscore (at the time) calls with native calls. It works, and is totally fine. But what was the point? Some kind of optimization? It was pretty pointless in hindsight and just made my coworkers trouble. Now all my JS code is Ramda/lodash all the way, and it's great (although I opt for Clojure/script when possible)
These emperor has no clothes posts are very popular, and some may ask what's the point. It's a question worth considering. I think by instinct people especially programmer/engineer types like the idea of purity.
But if you consider that every decision must be put through a cost/benefit analysis, I think the appeal is that - I (or anyone in the future that will ever touch the code) must learn JS. OK. Now they must also learn framework X. That's the added cost.
Our memory is limited too, like a computer chip. When I know JS I can instantly access what I need. If you think of a Google or cheat sheet lookup like a disk access, well memory is faster than disk.
My rationale is that any one of these functions is probably going to be put into a utility function that's documented and named already, and of course tested with some optimizations, in some file somewhere in my code base. If it's useful enough, it'll probably be there. And while I don't often do front end, having these utilities support older versions of browsers or if there exist quirks in certain versions of browsers that render the solution nonviable is just not something I want to spend time caring about. When I did Java, the same articles would come out about Guava and Apache Commons.
One should not be afraid to use battle tested libraries, but don't bring dependencies for no reason.
Is that really true, though? I mean, there most probably is some theoretical limit how much data can fit in a structure of particular shape composed of particular number of neurons, but are we really hitting that limit? Are we even capable of hitting this limit after a lifetime of learning and experiencing? It may feel that way, but it could be a side-effect of some focus-switching and memory-compressing heuristics implemented by the brain.
What I mean is that there are obviously people who learned both JS and a framework, so why wouldn't anyone be able to do this? And I can guarantee that, once you learn it, both JS and a framework fit in your 'cache' perfectly. Actually, I felt no difference between recalling things before I learned a framework and after.
In other words, learning a new framework should be possible for anyone. And programmers are expected to continuously learn new things anyway, it's not "added" cost, it's just part of the job. From this point of view, I can't see any problems with introducing a library, given that it's a good library (docs, active maintainers, community, etc.)
> If you think of a Google or cheat sheet lookup like a disk access, well memory is faster than disk.
I like this analogy - not just its application to the current conversation, but because I consider myself to be understanding of a topic when I no longer have to look it up, but instead I know the topic in principle and all I lookup are minor details (maybe like an address in memory to find something on disk?)
At this point I would consider JS purity to be the One Standard Prelude with all the usually functional goodies in one nice package. You know, with real tests and whatnot. Underscore/Lodash comes pretty close to that.
> I (or anyone in the future that will ever touch the code) must learn JS. OK. Now they must also learn framework X.
Well you can forget the parts of JS covered by the framework. I don't really care about the native Array.map or whatever functions, because they won't always behave as I expect, while the lodash (or equivalent) will. I can't recall off the top of my head how to use XMLHttpRequest. But I don't need to and haven't needed to in a while, because every project I've worked on uses jQuery or another framework which provided better ajax methods.
The main point of this (and similar - you-dont-need-jquery et al) is [should be] for those people who need a tiny piece of functionality that would take maybe a couple of lines of code, and import a dependency to deal with it. That's not too unusual - in a similar vein I spent a fair part of last year tearing hundreds–thousands of Kb of jQuery plugins (jQuery UI put in for one thing was pretty common) out of Rails apps because of this.
Lodash I'd say is unequivocally great (particularly the FP version, which I prefer to Ramda now), but these kind of posts aren't really for those who really need the full suite of functionality. Or at least it's very useful for those starting out on a project, who can then add in Lodash/whatever if/when the need arises, rather than reflexively adding it at the start.
I literally just got into this debate with a coworker yesterday. They didn't want lodash or immutable.js or any utility library in our new project at all, citing their size and the relative ease of doing it all natively. We use lodash or immutable or both in all our other projects but we always start out having these "purity" discussions until cooler heads prevail when we realize it's more important to optimize for convenience than it is to optimize for purity or even size. We're transpiling a future version of our language into an older version of our language just to get it to run, I think using lodash adding size is the least of our problems.
Two things from my memory. 1. They hit some bad PR when they pushed a badly broken release in a point update. Turned out that their testing was not robust, while Lodash's is excellent, which further hurt them (this is when I first remember hearing about Lodash) 2. Lodash adapted better to the module landscape, especially by splitting all of their functions into separate packages.
It's great, but there are better alternatives. Ramda[0] is great, auto-curries everything and has an api similar to Clojures, which is really great. Lodash[1] is a fork of Underscore, with some OOP-isms replaced for FP-isms, which I and many others prefer.
