Live data from Hacker News

Lists of JavaScript methods which you can use natively

github.com

91–100 of 162 posts

Re: Lists of JavaScript methods which you can use natively

#91

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,…

Lodash v4 has support for FP syntax/modules – https://github.com/lodash/lodash/wiki/FP-Guide

Re: Lists of JavaScript methods which you can use natively

#92
post #20
post #9

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…

If losash provides a more consistent API than the built-ins, then the memory requirements actually go down.

Re: Lists of JavaScript methods which you can use natively

#93

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.

Lodash has published packages with their individual functions, so you can strip down to what you need (and put together your own build if you so desire). For example: https://www.npmjs.com/package/lodash.throttle https://www.npmjs.com/package/lodash.debounce

Alternatively, if you use a modern web bundling system (like Webpack, for all its warts), you can just import the function directly

    import merge from `lodash/merge`
    merge(options, overrides)
There's also the ES6 build which you can use better with a bundling system that supports tree shaking.

Re: Lists of JavaScript methods which you can use natively

#94
post #18

Earlier quoted context omitted.

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.

> 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. Only if each site is using the exact same version of Lodash which is unlikely. Lodash is tiny anyways.

Actually, a full version of loadash is not insignificant.

Re: Lists of JavaScript methods which you can use natively

#95

Earlier quoted context omitted.

> 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. Only if each site is using the exact same version of Lodash which is unlikely. Lodash is tiny anyways.

Actually, a full version of loadash is not insignificant.

You might dig

https://github.com/lodash/lodash-webpack-plugin

Re: Lists of JavaScript methods which you can use natively

#96

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.

You should check out

https://github.com/lodash/babel-plugin-lodash

https://github.com/lodash/lodash-webpack-plugin

Re: Lists of JavaScript methods which you can use natively

#97

Earlier quoted context omitted.

> 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. Only if each site is using the exact same version of Lodash which is unlikely. Lodash is tiny anyways.

Actually, a full version of loadash is not insignificant.

Core build (~4 kB gzipped)

Full build (~22 kB gzipped)

Re: Lists of JavaScript methods which you can use natively

#98

Earlier quoted context omitted.

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 a…

I skipped over it because it's a solution in search of a problem. I think developers should be expected to understand the native constructs of the language they use. You previously also talked about "being more familiar to onboarding developers". Why should Lodash be more familiar than the native looping constructs to anyone? Why would Lodash be more familiar to a developer you're onboarding who is more used to some…

>You had to take time to look up operator-in because you're not used to using operator-in

I'm using in (`if('age' in value)`), but not for..in. There's a difference. I don't need to use that (you didn't in your example, even though you should have), but then my code would blow up in many of the same cases as yours will.

Anyway, what's wrong with that code is you'll need a hasOwnProperty check, you'll need to break out of the loop when done, it blows up if 'age' isn't a property on one of the objects in the object, it blows up if one of the properties of obj isn't an object, it blows up if obj is null/undefined, and it will deoptimize the entire function it's in in most cases in V8.

To at least fix the bugs that yours has that mine didn't, your code should be:

    for (var key in obj) {
      if (obj.hasOwnProperty(key)) {
        var val = obj[key]
        if ('age' in val && val.age === 1) {
          // there you go
        }
      }
    }
but again that still needs some undefined/null guards at a few spots, and it needs to be able to handle both an array and an obj at where obj is to really be an equivalent of what i was using _.filter for.

>You default assume other people's code is better than yours.

No, I know the lodash code i'm using is better than mine because i've looked at it, i've looked at it's test coverage, i've looked at it's performance numbers, and i've looked at it's usage.

Also... >I skipped over it because it's a solution in search of a problem.

Then why did you skip this part in my last comment:

>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

You made me curious, so i actually took a look at my current in-development app i'm writing that i include lodash. The grand total from all lodash functions is 22k un-gzipped, and 7k gzipped.

For that i've significantly reduced my code complexity, increased compatibility, reduced the amount of tests i needed to run and maintain, and improved performance in one pretty out-there edge case.

You don't need to use lodash, and in many cases you shouldn't. But don't act like your applications are better than others in any way because you aren't using lodash.

Re: Lists of JavaScript methods which you can use natively

#99
post #11

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.

Lodash is helping with JavaScript language additions like

https://github.com/leobalter/object-enumerables

https://github.com/bterlson/proposal-flatMap

Re: Lists of JavaScript methods which you can use natively

#100

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,…

I find lodash infinitely useful to this day. It even provides a build with auto-curried, iteratee-first, data-last functions if FP is your jam. Just require it like this:

    var _ = require("lodash/fp");
Post reply on HN