Every dependency carries a cost. You are effectively outsourcing part of the future maintenance of your project to an external team.

This can often be a very solid bet, but it can also occasionally backfire if the library you chose falls out of date and is no longer maintained.

For this reason I lean towards fewer dependencies, and have a high bar for when a dependency is worth adding to a project.

I prefer a dozen well vetted dependencies to hundreds of smaller ones that each solve a problem that I could have solved effectively without them.

For smol things like left-pad, sure but the two examples given (moment and react) solve really hard problems. If I were reviewing a PR where someone tried to re-implement time zone handling in JS, that’s not making it through review.

In JS, the DOM and time zones are some of the most messed up foundations you’re building on top of ime. (The DOM is amazing for documents but not designed for web apps.)

I think we really need to be careful about adding dependencies that we’re maintaining ourselves, especially when you factor in employee churn and existing options. Unless it’s the differentiator for the business you’re building, my advice to engineers is to strongly consider other options and have a case for why they don’t fit.

AI can play into the engineering blind spot of building it ourselves because it’s fun. But engineering as a discipline requires restraint.