8 ms·

I mean...sure? But this isn't very compelling when: 1. Many of these examples are just implementing the function (e.g., _.chunk). Yes, Lodash is written in Jav

• afavour 4y ago
  Maybe a better writeup would be "the Lodash functions you don't need to bother with any more". Like _.fill, which this article correctly states can just be replaced with Array.fill these days. But e.g. _.zip still has no equivalent. It would actually be cool if lodash started deprecating functions like _.fill (via semver so nothing breaks, of course) someday.
  • nightski 4y ago
    I hope lodash does not deprecate because I prefer non-instance methods personally.
    • afavour 4y ago
      Semver means you'd always be welcome to use the old versions of the library if you wished.
      • nightski 4y ago
        I understand Semver, but then I'd get no new updates and for no good reason. It doesn't make any sense to remove it.
        • afavour 4y ago
          They'd be able to publish updates to older versions of the library if they so wished. Like v2.6.0 -> v3.0.0 deprecates _.fill(), then a security fix comes along so they publish 3.0.1 2.6.1 > It doesn't make any sense to remove it. It does. Once the native platform supports the functionality it's redundant to keep it around and makes it less clear to a developer that the library isn't required any more. I'd argue it doesn't make any sense to use it but I'm not going to tell you that you can't. It's possible to accommodate everyone.
          • nightski 4y ago
            They'd be able to, but they won't. I disagree. Keeping it in accommodates everyone (not just your needs). You are not forced to use it, or even bundle it. I use lodash-es w/ tree shaking as it is.
            • afavour 4y ago
              > They'd be able to, but they won't. Why not? Until recently they were publishing individual packages for every single Lodash function. Publishing different versions that just do or do not exclude a single function is pretty simple by comparison. It seems like you want the project to hold itself back for no good reason.
              • deleted 4y ago
                [deleted]
              • nightski 4y ago
                Having to maintain older versions because you pulled out a function is much more burdensome than just keeping it in. I prefer the lodash way of doing things, you don't. So don't use it, that is fine.
                • afavour 4y ago
                  > Having to maintain older versions because you pulled out a function is much more burdensome than just keeping it in. Right. But we're talking about group that until recently maintained 281 separate packages. "much more burdensome" is a relative term here and publishing two versions simultaneously is absolutely not that burdensome. > I prefer the lodash way of doing things, you don't. So don't use it, that is fine. The solution I'm proposing lets you and me both use it exactly how we want to. I honestly find this debate to be quite baffling.
    • hn_throwaway_99 4y ago
      > I prefer non-instance methods personally. Why?
  • petre 4y ago
    The problem with these utility functions is that they're not chainable. It would also be nice if they made more use of Array.map or reduce rather than using for loops and mutating things. If I couldn't do it using a simple Array.map, reduce, filter or sort, I'd still use loadash or underscore if it was loaded.
    • afavour 4y ago
      I'm curious why? It's my understanding things like for loops are used for performance reasons, which makes sense: running .map().reduce().filter() involves creating three separate arrays which can be a drag if you're dealing with a large array. For loops don't have that issue (and more broadly a utility library like lodash surely ought to prioritize performance over code readability)
      • petre 4y ago
        Not what I meant, as one can obviously also filter or map in a reduce block, but maybe one needs to do a sort afterwards.
        • afavour 4y ago
          > one can obviously also filter or map in a reduce block Sure but you can't filter in a map, or map in a filter.
          • leipert 4y ago
            Reason why I like flatMap. It’s like map with a simple shortcut for filtering.
          • dpkirchner 4y ago
            You can filter in a compactMap (called just compact in lodash, apparently), FWIW. Not that this negates your point.
          • dragonwriter 4y ago
            sure. Reduce is the generic array -> anything operation, flatMap is the generic array -> array operation (and, as such, a special case of reduce), and map and filter are specialized array -> array operations (and, as such, special cases of flatMap and, transitively, of reduce.) So you can do both map and filter as part of a reduce or flatMap, but not either as part of the other. (You may be able to get close by doing ugly things in a map/filter that abuses the second and third arguments, but I don't think you can get a general map out of filter or vice versa, and you shouldn't do the kind of things you'd need to do to get close, just use flatMap.)
  • thrownaway561 4y ago
    I would think that lodash would check to see if the browser supports the methods and then use those method natively instead of a polyfil. this is the approach jquery takes
  • pavon 4y ago
    I find these fairly comprehensive writeups to be useful, because even if you would never use the more complex replacements, it makes it easy to verify that yup this is really the best you can do with pure javascript, I'll use a library for these calls.
• toastercat 4y ago
  > 2. Lodash is tree-shakeable, so if you import the functions you use directly, only those will be included in your JS bundle. I don't use Lodash, but recently began work on a project that does. I was surprised (along with the rest of the team) to find out that Lodash is not tree-shakeable by default. So if you do `import { debounce } from 'lodash';`, you're actually including the entirety of lodash in your bundle. More info here: https://lodash.com/per-method-packages https://lodash.com/per-method-packages The recommended solution by the lodash team is to use `babel-plugin-lodash` (including a babel plugin to use less code? no thanks) or import the single modules directly like `import throttle from 'lodash/throttle';`. In the end, since we only used about 3 functions from lodash that were trivial to replicate, we just ditched lodash. EDIT: There is also a `lodash-es` package with native ESM modules which may solve this issue for some. We avoided this also because it had implications with our toolchain.
  • emptysea 4y ago
    Yeah I switched a project over to lodash-es which fixed the tree shaking problem but it was painful to migrate everything
    • lobo_tuerto 4y ago
      How so? You only search and replace: "from 'lodash'" => "from 'lodash-es'" and you should be good. Unless you were importing individual functions.
      • toastercat 4y ago
        Can't speak for them, but we had some CJS/ESM interop issues with our (large and overcomplicated) babel toolchain as well as with our test suite.
        • emptysea 4y ago
          Yeah exactly what happened to us, it’s solvable but annoying Also we did have a mix of things like import _ from ‘lodash’ and import foo from ‘lodash/foo’, etc
• jagged-chisel 4y ago
  I was expecting more of a 'write your own implementation' kind of thing, but it's not really that. For example, the replacement for _.concat() is really just advice on how to concatenate arrays in-line. In such cases, I think learning that a packaged function is not needed is pretty nifty.
• TehShrike 4y ago
  Tree-shaking doesn't help much when the tree-shaken implementation is so bloated. Here's the one you referenced, lodash.chunk: https://unpkg.com/lodash.chunk https://unpkg.com/lodash.chunk – 140 lines after removing comments and whitespace. That's pretty small compared to a lot of the lodash utilities. Try spot-checking a few on unpkg. I prefer angus's `just` utilities: https://github.com/angus-c/just https://github.com/angus-c/just
  • deleted 4y ago
    [deleted]
  • deleted 4y ago
    [deleted]
  • phailhaus 4y ago
    Do you have any examples that show that `just` is more efficient than lodash? It doesn't even have a `chunk` implementation, so it's hard to say that it's better. The "bloat" is the result of being battle tested. A slimmer implementation would cut out edge cases that I may or may not run into. If I use Lodash, I know I'm all set.
    • TehShrike 4y ago
      The point of the OP is that you don't need dedicated functions for most of these utilities, let alone hundreds of lines of code. 0 lines of code is preferable to battle-tested code. 10 lines of code is preferable to 1000 if you don't need them.
      • phailhaus 4y ago
        The point of the OP was that _.chunk is 140 lines, which is apparently too much. But `just` doesn't even support chunk(), so it's unclear what the advantage is. Sure, you can theoretically spend your time crafting your own implementation, but why? For the self-satisfaction? I'd rather just get on with my work.
        • 4y ago
• philwelch 4y ago
  Introducing a supply chain vulnerability in order to import utility functions that any novice could write is a choice, I suppose. By the way, did you know it’s been seven years since left-pad?
• itslennysfault 4y ago
  I honestly haven't needed lodash in years. So much is built into JS now or very trivial to do. If I want to diff an array I don't create a diff function. I just diff it. Then there are things like fill, flatten, drop, etc, which are really just part of JS now.
• joshstrange 4y ago
  There are 2 big categories for lodash functions: 1. Functions that have equivalently terse native versions (fill, map, etc) 2. Function that have multi-line equivalents (chunk, zip, etc) Yes you can _.map an object and you can't myObject.map but I prefer Object.[keys/values](myObject).map(...) but for something like _.chunk I absolutely prefer to use lodash. Maybe one day we will see a new major version of lodash that deprecates all the near-native versions of functions so you can still use them but your editors will do a strikethrough and the JSDoc for the function can steer you to the native version but there are still a lot of useful lodash functions.
• jonahx 4y ago
  > Lodash is tree-shakeable... > Just use Lodash, it's better than having to maintain your own hodgepodge of poorly documented and tested utility functions. There are good reasons not to: - You don't want to add a build step to your project - You don't want to introduce any additional knowledge burden on contributors to your code, other than knowing JS. Your "chunk" is the few lines of source code in your repo -- not an external thing with documentation you have to lookup. - You don't want to deal with the security issues every dependency introduces Let's specifically address this claim, which is often used in roll-your-own vs use-a-library debates: > to maintain your own hodgepodge of poorly documented and tested utility functions I feel, in this particular case, this argument is a straw man. The functions in question are basically 1-liners. The likelihood of bugs are low. The need for documentation is nil: the implementations self-document.
  • phailhaus 4y ago
    > The functions in question are basically 1-liners. No, they're not. The first one is not a one-liner. What's the point of spending the time writing your own interface, implementation, and tests of every single util that you end up needing, if you could just import lodash and move on?
    • jonahx 4y ago
      The first one is 157 characters, and what it is doing can be grokked at a glance, in less than 10 seconds, by a competent developer. Choosing to format the body across 5 lines for clarity does not change that. I consider that "basically" a one-liner. > What's the point of spending the time writing your own interface, implementation, and tests of every single util I would not write tests for many of these, and the interfaces usually require no design because these are familiar functions like map, filter, etc, to most experienced developers. I gave the main reasons answering your questions in my last post, and I think those reasons are powerful enough that I would consider using a lodash a mistake in most situations. You are essentially making the "leftPad" argument, it's a kind of inverse "NIH" ethos: Why should you ever write your own anything when someone else has done it? And the answer, again, is the same: dependencies have a non-trivial cost.
• brundolf 4y ago
  Even if you have Lodash in your codebase, there are a bunch of functions it offers that have direct built-in analogues at this point, and I think it's still best to skip the library versions of those Ironically I don't see all of those in this list. Maybe OP just assumes everyone already knows how not to use those
• olalonde 4y ago
  The thing is that the JavaScript version is often more readable than the lodash one (unless you have a lot of experience with lodash of course). For example: _.compact(array) vs array.filter(value => !!value); Most JavaScript programmers will immediately know what `array.filter(value => !!value)` does but many will have to lookup the lodash documentation to understand what `_.compact(array)` does.
  • amadeuspagel 4y ago
    That's a good example. I looked at the first example "chunk" where the replacement is just a "chunk" function in javascript, and I asked myself what the purpose of this is, why I would copy-and-paste this chunk function rather then importing it from lodash. I think this site would be much better if it only included examples where the vanilla JS version is actually more readable.
  • hajile 4y ago
    But if you chain both of those, the `.compact()` will use Lodash iterators while the builtin will repeatedly iterate over the array.
• haswell 4y ago
  TFA does not claim that you shouldn't use Lodash (the HN title is incorrect and misleading). It leaves it up to the reader to decide why they might not want to use Lodash and makes no arguments for or against such a stance. What remains is a pretty useful overview that lets the reader see what each function is doing with emphasis on the how. It is presented as "if you wanna replace this, here's how". If I'm not already familiar with Lodash and trying to decide whether or not to bring it in as a dependency, and see that all I need is a 1-2 liner in native JS, that's useful information. I might still conclude that Lodash is the right choice, but I think that when examined in the context of the broader industry, where 3rd party libraries are often unnecessary and sometimes actively unhelpful, I think such a page is useful. Whether or not it's "compelling" will entirely depend on the problem you're currently trying to solve.
• bstar77 4y ago
  If you are using code splitting then importing directly gains you nothing.
• flippinburgers 4y ago
  This points at a larger problem: the junior developers who gleefully pull in tons of third party requirements which, as far as I can tell, is the supposed "senior" approach in javascript development.