10 ms·

Lists of JavaScript methods which you can use natively

249 points by tilt 10y ago

alixaxel 10y ago
The native version of find is still using _.find.
- jacobr 10y ago
  What?
- RobertKerans 10y ago
  Eh? No it's not, it's just using Array.protoype.find
jlebrech 10y ago
maybe lodash itself should warn when something is available natively, but for it to add extract browser detection for this is overkill. the real way to do this is to write ES6 and compile to ES5 and provide both to the browser.
onion2k 10y ago
https://github.com/cht8687/You-Dont-Need-Lodash-Underscore#_find https://github.com/cht8687/You-Dont-Need-Lodash-Underscore#_... - the Array.prototype.find() method that's suggested has no support on Android's stock browser or Chrome for Android. That's a huge chunk of the browser market, but there's no mention of it on the list. In fact, there's no consideration for mobile at all on any of the suggestions. If you're going to use any of the suggestions, check MDN or CanIUse first.
- lloyd-christmas 10y ago
  Here's another useful resource, I think I found it from HN a while ago. http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/
have_faith 10y ago
Instead of searching for the compatibility of each individual function I would much rather just use a custom build of Lodash with the collection of functions I need (which can even be handled by your build process now and some tree shaking). And I get a lot of utility functions with it too that I use a lot like Throttle and Debounce.
- test1235 10y ago
  Throttle and debounce are top of my list as well
- eknkc 10y ago
  Might be a good idea to use a polyfill (like core-js) to ensure the api exists. On modern browsers it would just use the native impl. Not much to gain though. Just importing lodash works fine.
  - shados 10y ago
    core-js is the truck factor single point of failure of modern JS development. There's not many good alternative (there's a lot of alternative, but none that are as comprehensive), essentially has ONE person really working on it (and threatening to stop imminently), and the code is unreadable, so hopping into it once said maintainer goes poof will be tricky. We still depend on it (no great alternative), but it's a ticking time bomb IMO.
- xiaoma 10y ago
  If you just use lodash from a CDN, many, many users will already have it. If you make a custom build, then everyone has to download.
  - Klathmon 10y ago
    Didn't someone do a study and found that cache hit rates for CDNs were in the 10-20% range? You might be better off bundling lodash and tree shaking everything you don't actually use away.
mduerksen 10y ago
_.filter is NOT equivalent to Array.prototype.filter. The array could be null/undefined, in which case the _.filter just works fine, but Array.protoype.filter does not. I hate to riddle my code with null checks I actually do not care about.
- eknkc 10y ago
  (arr || []).filter... Is something I do when I'm not sure if the array is null or not. Looks shitty but works fine. (Now if arr is not falsy and not an array either, this blows up. But I don't know what lodash does then too) To be honest, I'd rather check / handle nulls rather than to rely on an external library semantics. They might also change it tomorrow and upgrading would be a pain.
  - jdd 10y ago
    The language changes too. In ES5 `Object.keys` throws an error for `Object.keys('abc')` but in ES6 it returns an array.
    - eknkc 10y ago
      Still a pretty conservative breaking change. Something you'd expect from a committee of people. Lodash has more wiggle room to make absurd changes in future.
      - jdd 10y ago
        Lodash follows semver so major changes are opt-in unlike lang level ones though.
the_duke 10y ago
You'll be stuck with using a shim for old browsers for quite a while to come, especially when it comes to mobile. The good thing is, at some point in the future you can just drop the shim and everything keeps working. Lodash does has a lot of additional nice utility functions though.
s369610 10y ago
waiting for non mutating versions of sort and sortby
- Bahamut 10y ago
  [].concat(array).sort()
hkjgkjy 10y ago
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)
- dpweb 10y ago
  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.
  - _asummers 10y ago
    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.
  - rtpg 10y ago
    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.
SamiTriki 10y ago
Well, Lodash is focused on performance, and 3.X.X supports IE8 and a lot of older browsers, it's a pretty solid util library. If you add in all the good utilities function. As long as you use them a lot in your code, Lodash is definitely worth it
frostik 10y ago
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.
- DrJokepu 10y ago
  Object.keys() is rather well supported these days though.
  - frostik 10y ago
    Yes, but means that you need to implement map, foreach, filter yourself. So you might be better off with lodash.
    - deleted 10y ago
      [deleted]
    - mullsork 10y ago
      I think he's referring to `Object.keys(object).reduce`. We polyfill `Object.entries` so we do `Object.entries(object).reduce((result, [key, value]) => ...)`
  - crucialfelix 10y ago
    Related: for (var key of Object.keys(imps)) { } I figured that would work with babel-2015 and it did work on Chrome and Safari but on Firefox visitors were getting: Symbol.Iterator undefined You need http://babeljs.io/docs/plugins/transform-es2015-for-of/ http://babeljs.io/docs/plugins/transform-es2015-for-of/ as well. So there is much less risk in using _.each(imps, (value, key) => and not having to discover what you don't know. I also added Firefox to the unit tests after that.
  - jacobr 10y ago
    And Object.values is supported in Chrome and Firefox, and has polyfills for other browsers.
- 10y ago
andrewvijay 10y ago
"However, when you are targeting modern browsers" - possibly one of the worst mistakes companies do. Then they decide to support older browsers after customers complaints. Then shit goes down!
- j_jochem 10y ago
  It depends. Most of the really bad internet explorers are officially deprecated by now, so unless your customers are big enterprises with badly managed IT, it's completely fine to scrap support.
- LoSboccacc 10y ago
  I've yet to see a company going under and citing lack of old browser support as principal culprit.
bshimmin 10y ago
It took me a moment to figure out what this was for: https://github.com/cht8687/You-Dont-Need-Lodash-Underscore/blob/master/convert/convert.js https://github.com/cht8687/You-Dont-Need-Lodash-Underscore/b... Cripes!
elmigranto 10y ago
You might also not need to write any code at all, just set up a form for customers to send in their requests and hire a bunch of people to manually process them. Bam! 0K, no dependencies, almost instantly working web service. But that's not your priority when building website, it doesn't matter if your JS is 60Kb or 20. No one cares how much dependencies you build system pulls. You need tested, reliable and working libs to do their job, and not write your own routines for 3 months.
moron4hire 10y ago
Getting rid of unnecessary dependencies can have a huge impact on site download performance, especially on mobile. Even in the case of having the site cached, every resource you link will have to perform an HTTP request to at least receive NOT-MODIFIED. It can add up, especially if you're on a semi-spotty connection and trigger TCP congestion avoidance.
- Klathmon 10y ago
  Don't miss the forest for the trees. Re-implementing _.forEach, _.map, and _.reduce to do something like loop over objects yourself is going to most likely end up taking more code than just using those functions from lodash. Not to mention that you most likely won't have the same amount of testing, speed/optimization, or "familiarity" across devs with a home-grown solution. Yeah, don't pull in lodash if you are making a small library and you only need it once, but if you avoid lodash in a codebase where you use it a non-trivial amount, it's most likely going to be worth it. Plus with modern (at least to js land) tree shaking, and/or the way that lodash can package each function individually, you don't need ALL of lodash in order to use one or 2 functions.
  - moron4hire 10y ago
    I do not agree at all. What is so hard about for loops? I do not agree that using the native-to-the-platform looping constructs will create as much code as half a megabyte. I'm looking at it right now: the full build of Lodash is 503KB. That's also half-a-meg of code that needs to be parsed by the JS engine. And nothing else you said has anything to do with site performance. Do users care if it took you 10 seconds versus 11 seconds to write a particular looping construct? Do clients care?
    - Klathmon 10y ago
      Well you conveniently skipped right over the part of my comment where I said that you shouldn't be using the whole 500kb lodash library... (also, it's disingenuous at best and borderline lying to say that lodash is 500kb. The DEVELOPER version is 500kb, the production version is 67kb before gzipping, and 22kb after gzipping) If you are only using _.forEach, then you should only include _.forEach, which comes out to about 10kb before gzip compression, 5kb after (i just built it myself to test). And all but about 1.2kb of that is "core" code, so if you add additional lodash functions, most of them will increase the code size by about 2kb at the most. That means that for an overhead of about 8kb, you can start adding extremely useful functions all throughout your codebase with very little overhead. 1.2kb to easily and quickly iterate over an object using the key and the value in each block; _.forEach(obj, function(value, key) { // do stuff }) Pure js: Object.keys(obj).forEach(function(key) { var value = obj[key] // do stuff }) Not that much of a difference space wise, but the performance is terrible if you are iterating over a large object, and by using Object.keys you exclude some UAs. Now let's look at _.find in an object... _.find(obj, { 'age': 1}) // returns the first object (in the object) that has a property 'age' that equals 1. Pure JS: var objKeys = Object.keys(obj) var retval for(var i; i < objKeys.length; i++) { var value = obj[objKeys[i]] if ('age' in value && value.age === 1) { retval = value break } } And that's untested, will only work for an object of objects, has unknown performance, and sure as shit took me more than 1 extra second to write (about 5 minutes once i looked up what the compatibility of the 'in' operator is). You could use the native .find() function, but that won't work on chrome for android, android browser, IE (any version), safari 7 and older, and opera. Plus you'd still need something like Object.values() in order to convert the "parent" object into an array to search through. Plus what if i want to find an object in an array and in another object? (which I actually just had to do, which is why i thought of this use case) Well now you've just doubled your code, doubled the amount of tests you need to write, doubled the chance for random bugs to crop up (what happens if one of the object values is undefined? What happens if obj is null?). With stuff like the lodash cli where you can make builds that literally only contain what you need, the lodash babel plugin that will allow you to require lodash functions and it will build only what you need, or webpack which will tree-shake away everything you don't need (and actually does a better job than the lodash-cli does!), there's no need to avoid lodash like the plague. I'm not saying include all of it, i'm not saying use it in everything, i'm saying that you should use your brain and include it if it's going to increase the speed that you can develop, reduce the number of bugs you will face, simplify your codebase, and won't negatively impact your users. (after all, a single image will blow the 5kb of js you'll be saving out of the water)
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
piotrkubisa 10y ago
That's interesting why some of functions (_.repeat, _.findIndex) were marked as "Not supported" in Opera but all of them are supported in Chromium-based browsers. Did the author only consider Presto-powered Opera?
cel1ne 10y ago
Would it be possible to build an tool that scans your code for simple helpers you wrote yourself or that you include from dependencies and replace them with equivalent functions of lodash or native?
worldsayshi 10y ago
I would consider switching from underscore if there was a reliable polyfill so that I wouldn't need to be aware of all these browser compatibility constraints. That way I can just drop the polyfill in a couple of years instead of replacing every underscore use. I guess the babel polyfill would do this.
- shados 10y ago
  babel polyfill is roughly core-js.
erokar 10y ago
I prefer Ramda to Lodash and Underscore. It has a lot of functions that are missing in vanilla JS.
- jdd 10y ago
  You might dig https://github.com/lodash/lodash/wiki/FP-Guide https://github.com/lodash/lodash/wiki/FP-Guide
seanwilson 10y ago
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.
- nailer 10y ago
  The stdlib (and whatever polyfill you're using for old browsers) also abstracts away subtle browser differences. However stdlib looks more like the rest of JS. Totally agreed about size though: it's tiny. There are other reasons to prefer stdlib but size isn't one of them.
- spriggan3 10y ago
  If the 25KB are packaged with each library you add to your webpage, + ads , + analytics then maybe. 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.
- kerker123 10y ago
  nopes estas noche
- smrtinsert 10y ago
  Talking about the size of a lib in kb will fall on deaf ears here at hacker news. It's all about micro libs and nothing you don't need. Never mind the first few images on the site you are working for change daily and come out to several megs each will completely eclipse any library that changes once in blue moon.
- sotojuan 10y ago
klibertp 10y ago
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, there always be a need for some kind of utility belt-style library ("if only for convenience", as another commenter write, which is actually the main point of such libraries). It's just a matter of choosing the best library for your coding style and project at hand. It may be a hassle, but an alternative is an stdlib the size of Python's - and I'm not sure if it's a good direction. [1] http://ramdajs.com/0.21.0/index.html http://ramdajs.com/0.21.0/index.html [2] https://github.com/DrBoolean/pointfree-fantasy https://github.com/DrBoolean/pointfree-fantasy
- skrebbel 10y ago
  The Ramda API changes with every version. If you don't pay attention for a few months and accidentally upgrade (Ramda doesn't seem to want to do Semver, I'm not sure why), then suddenly half your code is broken. 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.
  - ascagnel_ 10y ago
    Technically, Ramda is using semver; 0.x releases are used for when the API is still changing substantially[0]. [0] http://semver.org/#spec-item-4 http://semver.org/#spec-item-4
    - skrebbel 10y ago
      Ahyes, good point. In the Ramda authors' defense, they never claimed it to be good for anything production level.
emodendroket 10y ago
Yes, you could implement every feature of just about any library yourself. Why, though?
- pgl 10y ago
  I think the point of the page is to demonstrate that for many, many lodash functions, there are direct equivalents in native JS - not rewritten features.
  - emodendroket 10y ago
    They don't have the lazily-executed features though, right?
jacobr 10y ago
My main concern with Lodash is not necessarily the size, but that it adds to the API surface a new developer has to learn when entering a project. You get a lot more value from the cost of learning a dozen API methods from React compared to having a developer looking up pluck, pull, xor, zip, flow, etc from lodash. I really recommend "Sebastian Markbage: Minimal API Surface Area - Learning patterns instead of frameworks" http://2014.jsconf.eu/speakers/sebastian-markbage-minimal-api-surface-area-learning-patterns-instead-of-frameworks.html http://2014.jsconf.eu/speakers/sebastian-markbage-minimal-ap...
spriggan3 10y ago
That list ignores mobile browsers though, the ones that are mostly never updated.
deleted 10y ago
[deleted]
rafinha 10y ago
or you can just use lodash
EliAndrewC 10y ago
Alternate title for the article: "Lists of lodash features replaced by ES6 if you don't mind throwing an exception when given invalid input such as null or undefined". All kidding aside, a lot of our lodash code ends up looking something like this: function (xs) { return _(xs).pluck('foo').filter().value(); } That code clearly expects that xs is an array of objects. However, we might occasionally end up with xs being undefined, or with xs being an array but one of the elements is null, etc. Most of the time, we want our function to just swallow those errors and return an empty array in such cases. This is exactly what lodash does, but if we tried to call xs.map(...) in that case we'd get an error. Similar caveats apply for grabbing the foo attribute if one of the array elements ends up being null or something. For this reason, I recommend continuing to use lodash almost all of the time, even when there's a native Javascript method available.
- smt88 10y ago
  > we want our function to just swallow those errors and return an empty array in such cases No no no no. That's a silent failure and a bug. That means our code is doing something we don't intend or understand.
  - savanaly 10y ago
    How could you know without seeing what code he's talking about? Why not take his word?
    - smt88 10y ago
      There's a reason linters/smell-detectors try to catch things like unexpected type coercion, and there's a reason the web software industry is aggressively moving toward typed languages (JS -> TypeScript, for example). If you tell a computer something it doesn't understand, it should tell you that it doesn't understand. There's no scenario where "just guess what you think I wanted to do and then do it" is a safe or reliable way for a program to run. By definition, sometimes it will work as intended and sometimes it won't. That's a bug. It's the worst kind of bug, actually: silent and undetectable until you catch the problem in the final output.
hnskeptik 10y ago
Functions like repeat() still need lodash - it's not supported on IE and Opera: https://github.com/cht8687/You-Dont-Need-Lodash-Underscore#_repeat https://github.com/cht8687/You-Dont-Need-Lodash-Underscore#_...
oblio 10y ago
What do the checkmarks mean?
jzig 10y ago
A nice thing Lodash has that Native doesn't is the 'matches' shorthand for things like find. I find it easier to read and quicker to write than a callback. _.find(items, {id: 10});
acbabis 10y ago
I don't use Lodash, but I remember reading that it does lazy evaluation[1]. For example, if you map an array, then take the last 3 items, it only calls the map function for those 3 items. Does anyone know if V8 can do any optimizations like this for native Array functions? That would be a good thing to know before downloading lodash. 1) http://filimanjaro.com/blog/2014/introducing-lazy-evaluation/ http://filimanjaro.com/blog/2014/introducing-lazy-evaluation...
- spaethnl 10y ago
  This cannot be done with native array functions as they exist now. The reason Lodash is able to do this is because the collection is wrapped in an a special object that keeps track of all of the functions you call on it. Those functions don't run until you call .value() on the whole pipeline that you have setup, and then the optimization happens. Note that this requires a separate API. One API returns your results immediately, the other (lazy) API instead returns a wrapper object after each call without yet doing the mapping/filtering/etc, ready to add more instructions to the pipeline that you must ultimately call .value() on in order to actually run. Native functions don't have this separate lazy API that does the wrapping with this special object, and don't have/return an object with a similar .value() method.
fbreduc 10y ago
This seems like a great post on why you should be using lodash.. especially all those IE unsupported things. Like mentioned in the comments, it's not just about having one or two of these features, it's about how they compose so nicely in lodash

249 points by tilt 10y ago

alixaxel 10y ago

The native version of find is still using _.find.

jacobr 10y ago
What?
RobertKerans 10y ago
Eh? No it's not, it's just using Array.protoype.find

jlebrech 10y ago

maybe lodash itself should warn when something is available natively, but for it to add extract browser detection for this is overkill. the real way to do this is to write ES6 and compile to ES5 and provide both to the browser.

onion2k 10y ago

https://github.com/cht8687/You-Dont-Need-Lodash-Underscore#_find https://github.com/cht8687/You-Dont-Need-Lodash-Underscore#_... - the Array.prototype.find() method that's suggested has no support on Android's stock browser or Chrome for Android. That's a huge chunk of the browser market, but there's no mention of it on the list. In fact, there's no consideration for mobile at all on any of the suggestions. If you're going to use any of the suggestions, check MDN or CanIUse first.

lloyd-christmas 10y ago
Here's another useful resource, I think I found it from HN a while ago. http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/

have_faith 10y ago

Instead of searching for the compatibility of each individual function I would much rather just use a custom build of Lodash with the collection of functions I need (which can even be handled by your build process now and some tree shaking). And I get a lot of utility functions with it too that I use a lot like Throttle and Debounce.

test1235 10y ago
Throttle and debounce are top of my list as well
eknkc 10y ago
Might be a good idea to use a polyfill (like core-js) to ensure the api exists. On modern browsers it would just use the native impl. Not much to gain though. Just importing lodash works fine.
- shados 10y ago
  core-js is the truck factor single point of failure of modern JS development. There's not many good alternative (there's a lot of alternative, but none that are as comprehensive), essentially has ONE person really working on it (and threatening to stop imminently), and the code is unreadable, so hopping into it once said maintainer goes poof will be tricky. We still depend on it (no great alternative), but it's a ticking time bomb IMO.
xiaoma 10y ago
If you just use lodash from a CDN, many, many users will already have it. If you make a custom build, then everyone has to download.
- Klathmon 10y ago
  Didn't someone do a study and found that cache hit rates for CDNs were in the 10-20% range? You might be better off bundling lodash and tree shaking everything you don't actually use away.

mduerksen 10y ago

_.filter is NOT equivalent to Array.prototype.filter. The array could be null/undefined, in which case the _.filter just works fine, but Array.protoype.filter does not. I hate to riddle my code with null checks I actually do not care about.

eknkc 10y ago
(arr || []).filter... Is something I do when I'm not sure if the array is null or not. Looks shitty but works fine. (Now if arr is not falsy and not an array either, this blows up. But I don't know what lodash does then too) To be honest, I'd rather check / handle nulls rather than to rely on an external library semantics. They might also change it tomorrow and upgrading would be a pain.
- jdd 10y ago
  The language changes too. In ES5 `Object.keys` throws an error for `Object.keys('abc')` but in ES6 it returns an array.
  - eknkc 10y ago
    Still a pretty conservative breaking change. Something you'd expect from a committee of people. Lodash has more wiggle room to make absurd changes in future.
    - jdd 10y ago
      Lodash follows semver so major changes are opt-in unlike lang level ones though.

the_duke 10y ago

You'll be stuck with using a shim for old browsers for quite a while to come, especially when it comes to mobile. The good thing is, at some point in the future you can just drop the shim and everything keeps working. Lodash does has a lot of additional nice utility functions though.

s369610 10y ago

waiting for non mutating versions of sort and sortby

Bahamut 10y ago
[].concat(array).sort()

hkjgkjy 10y ago

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)

dpweb 10y ago
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.
- _asummers 10y ago
  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.
- rtpg 10y ago
  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.

SamiTriki 10y ago

Well, Lodash is focused on performance, and 3.X.X supports IE8 and a lot of older browsers, it's a pretty solid util library. If you add in all the good utilities function. As long as you use them a lot in your code, Lodash is definitely worth it

frostik 10y ago

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.

DrJokepu 10y ago
Object.keys() is rather well supported these days though.
- frostik 10y ago
  Yes, but means that you need to implement map, foreach, filter yourself. So you might be better off with lodash.
  - deleted 10y ago
    [deleted]
  - mullsork 10y ago
    I think he's referring to `Object.keys(object).reduce`. We polyfill `Object.entries` so we do `Object.entries(object).reduce((result, [key, value]) => ...)`
- crucialfelix 10y ago
  Related: for (var key of Object.keys(imps)) { } I figured that would work with babel-2015 and it did work on Chrome and Safari but on Firefox visitors were getting: Symbol.Iterator undefined You need http://babeljs.io/docs/plugins/transform-es2015-for-of/ http://babeljs.io/docs/plugins/transform-es2015-for-of/ as well. So there is much less risk in using _.each(imps, (value, key) => and not having to discover what you don't know. I also added Firefox to the unit tests after that.
- jacobr 10y ago
  And Object.values is supported in Chrome and Firefox, and has polyfills for other browsers.
10y ago

andrewvijay 10y ago

"However, when you are targeting modern browsers" - possibly one of the worst mistakes companies do. Then they decide to support older browsers after customers complaints. Then shit goes down!

j_jochem 10y ago
It depends. Most of the really bad internet explorers are officially deprecated by now, so unless your customers are big enterprises with badly managed IT, it's completely fine to scrap support.
LoSboccacc 10y ago
I've yet to see a company going under and citing lack of old browser support as principal culprit.

bshimmin 10y ago

It took me a moment to figure out what this was for: https://github.com/cht8687/You-Dont-Need-Lodash-Underscore/blob/master/convert/convert.js https://github.com/cht8687/You-Dont-Need-Lodash-Underscore/b... Cripes!

elmigranto 10y ago

You might also not need to write any code at all, just set up a form for customers to send in their requests and hire a bunch of people to manually process them. Bam! 0K, no dependencies, almost instantly working web service. But that's not your priority when building website, it doesn't matter if your JS is 60Kb or 20. No one cares how much dependencies you build system pulls. You need tested, reliable and working libs to do their job, and not write your own routines for 3 months.

moron4hire 10y ago

Getting rid of unnecessary dependencies can have a huge impact on site download performance, especially on mobile. Even in the case of having the site cached, every resource you link will have to perform an HTTP request to at least receive NOT-MODIFIED. It can add up, especially if you're on a semi-spotty connection and trigger TCP congestion avoidance.

Klathmon 10y ago
Don't miss the forest for the trees. Re-implementing _.forEach, _.map, and _.reduce to do something like loop over objects yourself is going to most likely end up taking more code than just using those functions from lodash. Not to mention that you most likely won't have the same amount of testing, speed/optimization, or "familiarity" across devs with a home-grown solution. Yeah, don't pull in lodash if you are making a small library and you only need it once, but if you avoid lodash in a codebase where you use it a non-trivial amount, it's most likely going to be worth it. Plus with modern (at least to js land) tree shaking, and/or the way that lodash can package each function individually, you don't need ALL of lodash in order to use one or 2 functions.
- moron4hire 10y ago
  I do not agree at all. What is so hard about for loops? I do not agree that using the native-to-the-platform looping constructs will create as much code as half a megabyte. I'm looking at it right now: the full build of Lodash is 503KB. That's also half-a-meg of code that needs to be parsed by the JS engine. And nothing else you said has anything to do with site performance. Do users care if it took you 10 seconds versus 11 seconds to write a particular looping construct? Do clients care?
  - Klathmon 10y ago
    Well you conveniently skipped right over the part of my comment where I said that you shouldn't be using the whole 500kb lodash library... (also, it's disingenuous at best and borderline lying to say that lodash is 500kb. The DEVELOPER version is 500kb, the production version is 67kb before gzipping, and 22kb after gzipping) If you are only using _.forEach, then you should only include _.forEach, which comes out to about 10kb before gzip compression, 5kb after (i just built it myself to test). And all but about 1.2kb of that is "core" code, so if you add additional lodash functions, most of them will increase the code size by about 2kb at the most. That means that for an overhead of about 8kb, you can start adding extremely useful functions all throughout your codebase with very little overhead. 1.2kb to easily and quickly iterate over an object using the key and the value in each block; _.forEach(obj, function(value, key) { // do stuff }) Pure js: Object.keys(obj).forEach(function(key) { var value = obj[key] // do stuff }) Not that much of a difference space wise, but the performance is terrible if you are iterating over a large object, and by using Object.keys you exclude some UAs. Now let's look at _.find in an object... _.find(obj, { 'age': 1}) // returns the first object (in the object) that has a property 'age' that equals 1. Pure JS: var objKeys = Object.keys(obj) var retval for(var i; i < objKeys.length; i++) { var value = obj[objKeys[i]] if ('age' in value && value.age === 1) { retval = value break } } And that's untested, will only work for an object of objects, has unknown performance, and sure as shit took me more than 1 extra second to write (about 5 minutes once i looked up what the compatibility of the 'in' operator is). You could use the native .find() function, but that won't work on chrome for android, android browser, IE (any version), safari 7 and older, and opera. Plus you'd still need something like Object.values() in order to convert the "parent" object into an array to search through. Plus what if i want to find an object in an array and in another object? (which I actually just had to do, which is why i thought of this use case) Well now you've just doubled your code, doubled the amount of tests you need to write, doubled the chance for random bugs to crop up (what happens if one of the object values is undefined? What happens if obj is null?). With stuff like the lodash cli where you can make builds that literally only contain what you need, the lodash babel plugin that will allow you to require lodash functions and it will build only what you need, or webpack which will tree-shake away everything you don't need (and actually does a better job than the lodash-cli does!), there's no need to avoid lodash like the plague. I'm not saying include all of it, i'm not saying use it in everything, i'm saying that you should use your brain and include it if it's going to increase the speed that you can develop, reduce the number of bugs you will face, simplify your codebase, and won't negatively impact your users. (after all, a single image will blow the 5kb of js you'll be saving out of the water)

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

piotrkubisa 10y ago

That's interesting why some of functions (_.repeat, _.findIndex) were marked as "Not supported" in Opera but all of them are supported in Chromium-based browsers. Did the author only consider Presto-powered Opera?

cel1ne 10y ago

Would it be possible to build an tool that scans your code for simple helpers you wrote yourself or that you include from dependencies and replace them with equivalent functions of lodash or native?

worldsayshi 10y ago

I would consider switching from underscore if there was a reliable polyfill so that I wouldn't need to be aware of all these browser compatibility constraints. That way I can just drop the polyfill in a couple of years instead of replacing every underscore use. I guess the babel polyfill would do this.

shados 10y ago
babel polyfill is roughly core-js.

erokar 10y ago

I prefer Ramda to Lodash and Underscore. It has a lot of functions that are missing in vanilla JS.

jdd 10y ago
You might dig https://github.com/lodash/lodash/wiki/FP-Guide https://github.com/lodash/lodash/wiki/FP-Guide

seanwilson 10y ago

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.

nailer 10y ago
The stdlib (and whatever polyfill you're using for old browsers) also abstracts away subtle browser differences. However stdlib looks more like the rest of JS. Totally agreed about size though: it's tiny. There are other reasons to prefer stdlib but size isn't one of them.
spriggan3 10y ago
If the 25KB are packaged with each library you add to your webpage, + ads , + analytics then maybe. 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.
kerker123 10y ago
nopes estas noche
smrtinsert 10y ago
Talking about the size of a lib in kb will fall on deaf ears here at hacker news. It's all about micro libs and nothing you don't need. Never mind the first few images on the site you are working for change daily and come out to several megs each will completely eclipse any library that changes once in blue moon.
sotojuan 10y ago

klibertp 10y ago

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, there always be a need for some kind of utility belt-style library ("if only for convenience", as another commenter write, which is actually the main point of such libraries). It's just a matter of choosing the best library for your coding style and project at hand. It may be a hassle, but an alternative is an stdlib the size of Python's - and I'm not sure if it's a good direction. [1] http://ramdajs.com/0.21.0/index.html http://ramdajs.com/0.21.0/index.html [2] https://github.com/DrBoolean/pointfree-fantasy https://github.com/DrBoolean/pointfree-fantasy

skrebbel 10y ago
The Ramda API changes with every version. If you don't pay attention for a few months and accidentally upgrade (Ramda doesn't seem to want to do Semver, I'm not sure why), then suddenly half your code is broken. 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.
- ascagnel_ 10y ago
  Technically, Ramda is using semver; 0.x releases are used for when the API is still changing substantially[0]. [0] http://semver.org/#spec-item-4 http://semver.org/#spec-item-4
  - skrebbel 10y ago
    Ahyes, good point. In the Ramda authors' defense, they never claimed it to be good for anything production level.

emodendroket 10y ago

Yes, you could implement every feature of just about any library yourself. Why, though?

pgl 10y ago
I think the point of the page is to demonstrate that for many, many lodash functions, there are direct equivalents in native JS - not rewritten features.
- emodendroket 10y ago
  They don't have the lazily-executed features though, right?

jacobr 10y ago

My main concern with Lodash is not necessarily the size, but that it adds to the API surface a new developer has to learn when entering a project. You get a lot more value from the cost of learning a dozen API methods from React compared to having a developer looking up pluck, pull, xor, zip, flow, etc from lodash. I really recommend "Sebastian Markbage: Minimal API Surface Area - Learning patterns instead of frameworks" http://2014.jsconf.eu/speakers/sebastian-markbage-minimal-api-surface-area-learning-patterns-instead-of-frameworks.html http://2014.jsconf.eu/speakers/sebastian-markbage-minimal-ap...

spriggan3 10y ago

That list ignores mobile browsers though, the ones that are mostly never updated.

deleted 10y ago

[deleted]

rafinha 10y ago

or you can just use lodash

EliAndrewC 10y ago

Alternate title for the article: "Lists of lodash features replaced by ES6 if you don't mind throwing an exception when given invalid input such as null or undefined". All kidding aside, a lot of our lodash code ends up looking something like this: function (xs) { return _(xs).pluck('foo').filter().value(); } That code clearly expects that xs is an array of objects. However, we might occasionally end up with xs being undefined, or with xs being an array but one of the elements is null, etc. Most of the time, we want our function to just swallow those errors and return an empty array in such cases. This is exactly what lodash does, but if we tried to call xs.map(...) in that case we'd get an error. Similar caveats apply for grabbing the foo attribute if one of the array elements ends up being null or something. For this reason, I recommend continuing to use lodash almost all of the time, even when there's a native Javascript method available.

smt88 10y ago
> we want our function to just swallow those errors and return an empty array in such cases No no no no. That's a silent failure and a bug. That means our code is doing something we don't intend or understand.
- savanaly 10y ago
  How could you know without seeing what code he's talking about? Why not take his word?
  - smt88 10y ago
    There's a reason linters/smell-detectors try to catch things like unexpected type coercion, and there's a reason the web software industry is aggressively moving toward typed languages (JS -> TypeScript, for example). If you tell a computer something it doesn't understand, it should tell you that it doesn't understand. There's no scenario where "just guess what you think I wanted to do and then do it" is a safe or reliable way for a program to run. By definition, sometimes it will work as intended and sometimes it won't. That's a bug. It's the worst kind of bug, actually: silent and undetectable until you catch the problem in the final output.

hnskeptik 10y ago

Functions like repeat() still need lodash - it's not supported on IE and Opera: https://github.com/cht8687/You-Dont-Need-Lodash-Underscore#_repeat https://github.com/cht8687/You-Dont-Need-Lodash-Underscore#_...

oblio 10y ago

What do the checkmarks mean?

jzig 10y ago

A nice thing Lodash has that Native doesn't is the 'matches' shorthand for things like find. I find it easier to read and quicker to write than a callback. _.find(items, {id: 10});

acbabis 10y ago

I don't use Lodash, but I remember reading that it does lazy evaluation[1]. For example, if you map an array, then take the last 3 items, it only calls the map function for those 3 items. Does anyone know if V8 can do any optimizations like this for native Array functions? That would be a good thing to know before downloading lodash. 1) http://filimanjaro.com/blog/2014/introducing-lazy-evaluation/ http://filimanjaro.com/blog/2014/introducing-lazy-evaluation...

spaethnl 10y ago
This cannot be done with native array functions as they exist now. The reason Lodash is able to do this is because the collection is wrapped in an a special object that keeps track of all of the functions you call on it. Those functions don't run until you call .value() on the whole pipeline that you have setup, and then the optimization happens. Note that this requires a separate API. One API returns your results immediately, the other (lazy) API instead returns a wrapper object after each call without yet doing the mapping/filtering/etc, ready to add more instructions to the pipeline that you must ultimately call .value() on in order to actually run. Native functions don't have this separate lazy API that does the wrapping with this special object, and don't have/return an object with a similar .value() method.

fbreduc 10y ago

This seems like a great post on why you should be using lodash.. especially all those IE unsupported things. Like mentioned in the comments, it's not just about having one or two of these features, it's about how they compose so nicely in lodash