If I have seen further than others, it is by standing upon the shoulders of giants. — Isaac Newton

This phrase about standing upon the shoulders of giants is widely used in programming circles. After all, it would be impossible to actually start from “zero”.

If you wish to make an apple pie from scratch, you must first invent the universe — Carl Sagan

The programming “universe”

More than any dependency, there’s a lot that we just take for granted.

Quantum computing is, in some sense, creating a new universe where the most basic thing we take for granted, binary, doesn’t exist.

From there they really need to create everything and even then, I could argue that everything they learned with “normal” computing is being used, in other words, even they aren’t starting from “zero”.

Why you want dependencies

Someone will always know more than you in one thing. The same thing is mostly true for dependencies.

Unless you’re doing something tiny or something totally new, whatever else you will do will probably be big enough that you will have to choose between two things: adding dependencies or recreating the universe.

As programmers, we get that itchy of “I think I can do better”, some try to improve current projects, but sometimes it’s not really possible so people start new projects.

This is not exactly a problem, but while you can be confident in creating one thing better than any other option available, few people if any can say the same about creating something better spanning an overlap of multiple projects.

The surface area is just too big and we just aren’t that good at seeing in detail anything outside our main goals. So, while it might work great for those cases you’re actually considering, anything that slightly deviates might not be covered.

Pick your battles

Nest.js is a Node backend framework, some people don’t like it takes a lot to do something simple. On the other hand, someone working on a big project has a lot more support and a solid base for growth.

Whatever you might think, one thing I can argue that it does better than another backend framework, AdonisJS, is that Nest might have defaults but you can just replace parts.

It defaults to using Express under the hoods, but you can easily change it for Fastify, Koa, or another one. Same for so many other parts that you might rightly think: “What do they even do then?”.

On the other hand, AdonisJS has an umbrella of projects for each part of the application. While I’m using a legacy version, I don’t know how the current versions fare against the “non-Adonis” alternatives. But from what I know, it can be harder to integrate an alternative for one of the Adonis solutions and from what I found, it seems you can’t use those pieces outside of an Adonis project.

This means that contributing to the project needs you to know the whole context of the projects, and it. As many and as good contributors as they might have, it certainly doesn’t compare with how much use and contributions standalone projects get.

If Adonis were for Node as Laravel for PHP, Rails for Ruby, or Django for Python, then having everything deeply integrated could have its advantages. But for at least one of those languages, I’m sure you can name other frameworks.

The “App of Theseus”

Nothing is too big to fail in programming, even those big frameworks can and probably will be replaced with time. And in Node, it changes so much and so fast that any project started more than a few years ago is as legacy as it can be.

In a universe like this, you can see more appeal in making your app the Ship of Theseus, because while changing the whole ship would mean actually rewriting a new ship, you can keep maintaining the same ship just by changing its parts.

(By the last paragraph you might be thinking: “Ackchyually, Theseus didn’t build the ship. Ackchyually, the comparison doesn’t even make sense.”. I know, I don’t care and you shouldn’t also.)

A big rewrite seems like an inevitability in our field, but we learned better from the giants of yore. There are ways to implement external parts in our applications and still be able to change them on a “whim”. That is if we build an application already expecting to change things that might get outdated faster or even some core parts that would benefit from a better approach.