Maybe You Don't Need This Library

JavaScript gives us a library for almost everything.

State management. Authentication. Forms. Charts. Animations. Validation. Date handling. Even checking whether a number is odd.

That is useful. It is also dangerous.

The question is not whether libraries are good or bad. The question is whether this library is worth the trade.

First phase: write it yourself

When I started programming, I did not know libraries existed.

That meant every problem had exactly one path forward: build something.

That was slow, but it taught me a lot:

• I understood what my code was doing
• I could change it however I wanted
• when it broke, I had a fighting chance of fixing it

There is real value in that phase.

Second phase: install everything

Then you discover the ecosystem and it feels amazing.

Why write the hard part when someone else already solved it?

That instinct is not wrong. Great libraries let teams move faster and avoid reinventing things that are already well understood.

If your product is not a charting library, you probably should not spend two weeks building charts.

Third phase: pay the bill

The catch is that libraries are not just helpers. They are dependencies, constraints, abstractions, and future maintenance decisions.

Enough of them and you end up in a codebase where:

• bundle size quietly grows
• stack traces stop making sense
• simple changes require reading third-party internals
• your team starts explaining why something cannot be done instead of doing it

That is the point where convenience starts turning into drag.

The more useful middle ground

These days my view is simpler.

Writing the code yourself is fine.

Using a library is fine too.

What matters is understanding the trade:

• how much complexity the library actually removes
• how much weight it adds
• whether your team still owns the problem or just works around the tool

Sometimes the right move is to install the library.

Sometimes the right move is to pound out a straightforward solution yourself, learn the edges, and only bring in a dependency if the problem turns out to be bigger than it looked.

That tends to produce better judgment than reaching for npm install by reflex.