currently in my place of work I'm headbutting with some coworkers from other teams (but same repo), since they are in a line of thinking where they prefer this:

const connectionList = Object.values(connections).flat();
const connection = connectionList.find(
  conn => conn.in === Number(connectionId),

Rather than just using a helper library like lodash (that's already integrated into our codebase):

const connection = find(connections, { id: Number(connectionId) })

some of their arguments are:

  • JS is forever. Flavors and libraries come and go. The closer your project stays to the native spec the less tech debt you are bringing yourself multiple years out. So while it may seem easier in the present moment you have to always consider what happens if this third party library goes away 3 years from now and we are stuck maintaining it in our codebases for the next 10-20 years? Is the value prop high enough to take on that potential risk?
  • We source our engineers based on their JS abilities so it is very reasonable for us to assume anyone walking in the door can read vanilla JS their first day, so we are reducing onboarding time. Any 3rd party libraries we green light (including common ones like React, Lodash, Styled Components, etc) we take on a higher employee acquisition cost to get developers who have not worked with those specific libraries up and running, so there needs to be some deep consideration about limiting which ones we are willing to take that hit in order to depend on them.
  • We have a head count of 300 and growing, and everyone has opinions on which helper libraries are best. Wrangling the external libraries each person likes using becomes a bottle neck on enterprise level code. So as we are on our journey to get there it is good practice to start reducing those dependancies now, vs having to go back and clean them from a code base 10x the size we have now.

In my eyes the less code the less likely to have bugs and also since the code is simpler is easier to read is easier for a dev to process it, so I am wondering if I am in the wrong in here or what would you consider the best?

  • they are there, in the screenshot, red vs green, if you can't see the colors, the second section is the one that follows the +
    – elios264
    Commented Nov 8, 2022 at 19:19
  • Ah, you must have a higher gamma setting than I do. I can't see the colors. I take it the lodash line follows the +? Commented Nov 8, 2022 at 19:22
  • 1
    This seems more like an issue around technical governance, and something that the organisation needs to find a way of addressing so that developers aren't getting stuck in mud on these kinds of debates. If it's a debate between developers, then it's most likely going to involve people who do not have a sufficient overall view of the "big picture" around the organisation's long-term plans and strategies. Such issues are often where I'd expect a lead architect or technical authority to step in and make a final decision with the business' best interests in mind. Commented Nov 8, 2022 at 19:56
  • 1
    @BenCottrell all true, but the question is how to make that decision. For all we know this is one of their lead architects. And if not, someone who may need to plead their case to one. Commented Nov 8, 2022 at 20:00
  • 2
    This discussion is not complete without a nod to left-pad incident and how one programmer broke the internet
    – John Wu
    Commented Nov 9, 2022 at 20:13

1 Answer 1


The example is a bit flawed. You take a piece of code, and you replace it by a piece of completely different logic which doesn't do the same thing.

See, your first example doesn't just search for elements. It also flattens them. For example, given:

const connections = { a: { id: 123 }, b: [{ id: 456 }, { id: 789 }] };
const connectionId = 789;

the first piece of code would return { id: 789 }, whereas the second one would return undefined.

So let's compare what is comparable: the plain vanilla JavaScript on one side:

const connection = Object.values(connections).find(x => x.id === Number(connectionId));

and your alternative on the other:

const connection = find(connections, { id: Number(connectionId) });

I haven't used lodash for ages, and I find yours rather cryptic:

  • I don't know where find comes from. An import, maybe? Agreed, a capable IDE will give me the answer pretty quickly.

  • I could guess that find takes an array and an object containing the fields that should be matched against every element of the array. But checking the IDE, it appears that connections is not an array, but an object. Does find search for the keys, or the values? That, I don't know.

  • I'm clueless about the way the actual comparison is made. Is it == or ===?

More questions appear as soon as I want to change the piece of code—or use it somewhere else. For instance:

  • I need to select all connections where id is different from connectionId. I have no idea how to do it with your piece of code, and I would need to search the documentation for that. Same if I need to search for connection IDs superior or inferior to something.

  • I need to sort the connections. Do I use vanilla JavaScript? Or is there a special operation for that in lodash?

  • Instead of an actual connection, I need now the original key. How do I do that in lodash?

The first one, on the other hand, is pretty clear and explicit. One may be hesitant about the meaning of Object.values, but it's still pretty easy to guess. As for the find part, it can't get more readable than that.

  • Hey, thanks for your answer!, agreed if a dev is not familiar with lodash, he would need to check the docs to get the answer to those questions, a steeper (just a bit) learning curve is involved, but all of the proposed changes are also possible in a simple way with lodash. but the question is, is it worth it? do we end up with more benefits (more concise code) vs using just native code (more verbose code)?, after all we want to focus in coding the business requirements, not in reinventing the wheel, that's not so efficient. what I posted is just an instance of the hundreds we have in our code
    – elios264
    Commented Nov 8, 2022 at 22:26
  • and about the flat, I just checked and is not needed, not sure why it was put there.
    – elios264
    Commented Nov 8, 2022 at 22:42
  • "I find yours rather cryptic" - it's not cryptic at all. "I don't know where [...] I could guess that [...]" - in the end you don't really need to know any of that, if the code is tested and works; it's one line in a larger context. All you really need to know is that it finds a connection with the given connection id. If you want to change something (like the other things you mentioned), you're not obliged to use lodash - what you'll use is an implementation detail that you, the dev, will decide on, and insisting on lodash for "consistency" is counterproductive. Commented Nov 10, 2022 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.