While I don't completely agree, I think your thesis does have some merit.
I think using a framework/library (like React, or Express, or Flask, or SQLAlchemy, or Rails, or Spring etc.) isn't inherently a bad thing. In some cases it speeds up development a lot without really having any major down sides. If the cost is something like a performance penalty down the line, as the application begins to really scale, I'd say that falls into the "good problem to have" category.
However, it's true that the current ecosystem is just rife with frameworks, libraries, addons, plugins, extensions, and so on. It's very easy to reach for one after the other. Below are some ad-hoc guidelines I've built up for myself over time:
I've run into situations where I try an extension or plugin, and discover that to use it, I have to install at least one more extension! When that happens, I generally will remove the initial extension if at all possible.
Another scenario that happened to me recently: I tried using an extension and found a bug in it. When I searched online to figure out what was going on, I discovered that the proposed solution was to go back to an earlier version of the code. Furthermore, the project appeared to be completely inactive for several years with the owner not responding to any issues. Of course I removed this dependency from my project.
Boilerplate is one more thing that I think one should watch out for. Redux has some interesting properties, and it looks pretty good on paper. But When I tried using it in my project, I discovered that I really had to create a lot of confusing boilerplate to do simple things. For now I've removed Redux in favour of the new React Context API. It's not perfect either, but it did simplify my project a lot.
More generally, as one adds more dependencies to a project, all of the above scenarios become potential problems later on, even if they might not be a problem right now. So I think developers and teams should indeed be very cautious about just throwing more and more dependencies into a project.
The first questions should be "Can we make our own simple implementation that will do the job for the time being? Can we do it without taking too long to develop it? Can we do it without creating a lot of complex logic in our codebase?" If the answer is "yes," then don't use the 3rd party code. If the answer is "no," then it's more likely worth considering that external dependency.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While I don't completely agree, I think your thesis does have some merit.
I think using a framework/library (like React, or Express, or Flask, or SQLAlchemy, or Rails, or Spring etc.) isn't inherently a bad thing. In some cases it speeds up development a lot without really having any major down sides. If the cost is something like a performance penalty down the line, as the application begins to really scale, I'd say that falls into the "good problem to have" category.
However, it's true that the current ecosystem is just rife with frameworks, libraries, addons, plugins, extensions, and so on. It's very easy to reach for one after the other. Below are some ad-hoc guidelines I've built up for myself over time:
I've run into situations where I try an extension or plugin, and discover that to use it, I have to install at least one more extension! When that happens, I generally will remove the initial extension if at all possible.
Another scenario that happened to me recently: I tried using an extension and found a bug in it. When I searched online to figure out what was going on, I discovered that the proposed solution was to go back to an earlier version of the code. Furthermore, the project appeared to be completely inactive for several years with the owner not responding to any issues. Of course I removed this dependency from my project.
Boilerplate is one more thing that I think one should watch out for. Redux has some interesting properties, and it looks pretty good on paper. But When I tried using it in my project, I discovered that I really had to create a lot of confusing boilerplate to do simple things. For now I've removed Redux in favour of the new React Context API. It's not perfect either, but it did simplify my project a lot.
More generally, as one adds more dependencies to a project, all of the above scenarios become potential problems later on, even if they might not be a problem right now. So I think developers and teams should indeed be very cautious about just throwing more and more dependencies into a project.
The first questions should be "Can we make our own simple implementation that will do the job for the time being? Can we do it without taking too long to develop it? Can we do it without creating a lot of complex logic in our codebase?" If the answer is "yes," then don't use the 3rd party code. If the answer is "no," then it's more likely worth considering that external dependency.