51–60 of 162 posts
There's a huge gotcha: _.map, _.forech, ... can iterate over objects (often used as associative arrays) - Native map can't. At some point you'll need lodash and co again - at least for convinience.
The need for Lodash and Underscore is diminishing, but not because of JS getting native support for a subset of utilities, but because there are already better alternatives. Utility libraries like Ramda[1] or pointfree-fantasy[2] with related modules which offer a better support for FP idioms and more useful higher-order functions are what made me drop Underscore. I think that, with a language with such tiny stdlib,…
We depend heavily on Ramda and I like its API better than Lodash and friends (it's more guessable, more consistent), but with the changes it keeps having I regret choosing it.
Our core product is currently on a Ramda version that's so old that there's no online documentation published for it, so we just look in the source. We ought to upgrade but I'm not convinced all code paths that use R are sufficiently covered by automated tests.
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)
For the sake of 25KB for the full Lodash library, is it really going to make much difference? That size will be eclipsed by just a single small image on your website. Development is all about tradeoffs. Liberal use of Lodash can make for clean code that abstracts away subtle browser differences. For a small download size it sounds like a great tradeoff to me.
Totally agreed about size though: it's tiny. There are other reasons to prefer stdlib but size isn't one of them.
I really recommend "Sebastian Markbage: Minimal API Surface Area - Learning patterns instead of frameworks" http://2014.jsconf.eu/speakers/sebastian-markbage-minimal-ap...
Yes, you could implement every feature of just about any library yourself. Why, though?
For the sake of 25KB for the full Lodash library, is it really going to make much difference? That size will be eclipsed by just a single small image on your website. Development is all about tradeoffs. Liberal use of Lodash can make for clean code that abstracts away subtle browser differences. For a small download size it sounds like a great tradeoff to me.
One often doesn't need lodash. In fact, the only methods one does need are Object.keys to get the keys of an object and Array.prototype.reduce to iterate over an array, 90% of the time.
But yes, difference, zip, chunk, assign... are semantic and make for cleaner code. And yes flatten, xor are non trivial to implement, and the code one doesn't write is the code one doesn't have to test if already tested.
Of course, the best solution would be for the ECMA spec to implement most of lodash methods. I would also like to see an official way to curry, the same way Function.bind allows partial application.
There's a huge gotcha: _.map, _.forech, ... can iterate over objects (often used as associative arrays) - Native map can't. At some point you'll need lodash and co again - at least for convinience.
Object.keys() is rather well supported these days though.
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 als…
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.)