Sure, making a new wheel is fine if you're never actually going to use it. But if you're actually being serious, remember that you'll have to maintain it.
There's no free meal and adding a dependency is far from being free. Each dependency you add needs to be carefully reviewed, each of its update as well.
Though, apparently many people just YOLO this part.
I don't disagree, and it really depends on the complexity of what you are trying to do. If it's a simple util function, it makes total sense. But for complicated solutions where open source alternatives already exist, its a hard argument to spend your time reinventing it unless just for learning purposes.
As a team you constantly need to assess whether a dependency should be brought in or of a re-implementation is not better.
Sometimes, the re-implementation is so specific to you actual problem that maintenance becomes almost free. A generic solution always open more doors to problems and require more effort to maintain.
For a rich client web application, you need a really good reason not to bring an external dependency such as React.
> But for complicated solutions where open source alternatives already exist, its a hard argument to spend your time reinventing it unless just for learning purposes.
Even if the open source alternatives already exist, does not necessarily mean that they do what you want them to do. In some cases they can be fixed to do what you need (since it is open source, that is an advantage), but sometimes it cannot really be done without rewriting it and making a new one.
If "this will be properly maintained" was the bar for dependencies, hello world React projects would have a double-digits number of dependencies instead of 1484 [1].
Plus, most professionally programmed React apps from the last 10 years were created like this. Vite only replaced CRA as the recommended tool quite recently.
