When to add an extra dependancies to your app

Grow faster, but while adding debt.

Hey there! I’m looking for a new gig as a fractional senior frontend or fullstack developer (15h-20h a week). I have experience building software for public transportation, employee management operations, cybersecurity, and a bit of IoT, but I’m open to any industry. Please reach out if you need some help!

Last week, I have written a technical blog post last week about managing state with the built-in React Context only. It was a long time coming, but I wanted to get it done since this sounded so complex when I started out with React a few years ago. https://cindypotvin.com/managing-state-with-react-context/

I don’t mind pulling in an extra dependency, library or tool when required, and with a JavaScript project you’ll end up with many of them anyway, but each dependency still have an upgrade and maintenance costs. It’s also more complex to onboard new developers (even if it’s just a tiny bit of extra help) if there are lots of tools they need to learn.

When you get started and have a very small code base you can look at every piece of code, and throw in all the tools that will help you move faster and ship something.

But as the application it grows bigger you risk missing some changes to external tools and breaking the application: it’s time to start pulling back and keeping only what’s really necessary. The team for each of those dependencies can take different decisions that require refactoring on your side, break a feature, or can have a security issue.

Tests will help a lot, but no integration or end to end test can perfectly check for every use case and each pixel.

If on top of this you have vanilla JavaScript everything is allowed, you can carry around a parameter value that doesn’t do anything for a long time since it will be valid JavaScript, breaking your application in subtle or not so subtle ways.

TypeScript helps a lot there: even if you don’t use it much for your own things, it’s a lot easier to track down many types of upgrade problems such as deprecated/renamed parameters.

But it’s also the normal process of growing an application: quickly at first and them more careful since you now have users with existing data and features.