Using helper libraries to improve readability and conciseness of code vs adhering to native functions

Question

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?

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.