Ｉt's not really about the performance. It's about the readability. The performance don't even matter if you are just grouping dozens or hundreds items on the gui.

Abuse Lodash or Underscore everywhere means the code is not readable unless you know what is every used lodash function intended to do. Combing with weak type and undocumented business logic (and api types), it's a true nightmare experience to work with.

It's probably irrelevant in a personal project. But it's a headache if you are collaborating.

Sometimes it got even worse that original user don't know the exact specification of the utility function either. And the code works just by pure luck. (something like, the method work if all keys are numeric) It will give you a hard time to troubleshoot the problem if it happens.

▲

mwcz 3 days ago | parent [-]

"It's not really about the performance" the parent comment was about the performance of lodash.

▲

mmis1000 2 days ago | parent [-]

That's exact why I reply this though (or probably I should reply to your parent comment?). The place these get used are mostly performance insensitive location, it don't really do anything except ruins the readability. And the project is not that old either(It's a past es6-era project), I don't really get why it is used at all.

	▲	mwcz 2 days ago \| parent [-]
		I'm not a lodash stalwart or anything, but years ago when I used it heavily, it made navigating and manipulating large/complex/irregular objects much easier. It's LINQ for JavaScript. And it was very readable and consistent, since most functions in lodash have the same signature.