1. Profesional software development is an economic activity...
...and as such it must deal with limited resources. But that doesn't mean that the process must be focused in the short term. It's a complex game with some key interdependent business variables: value, cost, options, risk, etc. As :
Quoting David Bonilla:
Good software is one that meets expectations, time and budget without jeopardizing its own evolution.
Overuse of external software can save resources at the beginning but be a bad decision for the future (technical debt).
The weight of the long term factor depends on the type of product: it's not the same to build a start-up company prototype than to be part of a good funded software project.
From here I'm talking about long term projects.
2. The hard part is maintaining and evolving the code
I intro this point with the next quote (source):
Programmers are obsessed with ease rather than simplicity; or, what the experience of programming is instead of what the resulting program is like. (...) We still talk about programming as if typing in the code was the hard part. It's not - the hard part is maintaining the code.
I totally agree: it's almost irrelevant to save some time in the code creation stage (using external frameworks and libraries, of course) when the important issue, in most projects, is to maintain and evolve the code base in the long run.
Look for preventing future problems (e.g. external dependencies) is usually more relevant than speed up the coding at the beginning of the project.
Sometimes frameworks are used as a mean to force best practices and good architecture. At first sight this seems a good decision for long run but these solutions can bring us to future inflexibilities and limitations in our code.
3. Reuse external software means losing control
Reusing code has its dark side: it generates dependencies and this, in general, have big impact in code evolution. Tightly coupled software (project internal code) is hard to change and external dependencies (use of frameworks and libraries) imply loss of control of your code.
There are a lot of flavors of loss of control: it's not the same to add a library to our project with a black-box-attitude than try to understand its internals, nor to use an open source library than a proprietary one, nor to use software backed by a strong organization than one created by a single programmer.
4. If you don't dominate your tools, they will dominate you
Nothing comes for free. When we use libraries, frameworks or tools is highly recommended to master them and understand their internals (except for tools) in order to minimize losing control of our code (frameworks and libraries) and our process (tools).
We have to balance the cost of understanding and depending on this external code against the cost of implement the functionality that library provide us.
Finally, I think is worthy to note that the mere existence of a library/framework doesn't justify its usefulness. Some of them are created and spread by non-technical reasons: commercial, reputation/personal brand, internal needs of companies, etc.. Their interests can not fit ours.--
By type of softwafe
The application frameworks condition all our code base, so we have to be very careful making the decision of using one in our project. Of course, know it properly it will be very costly. The other option is to implement by ourselves the architecture that fits our project better. Like this quote suggest:
Think of your own framework based on the nature of your application. Categorize application components. Look for an existing framework that is close to your derived framework, if you find it then use it, if you do not find it then I suggest going ahead with your own. Creating framework is quite an effort upfront but produces better results in long run. Some basic components in my SPA framework will be:
This means to understand your domain, your project needs and build a good architecture for it. I think this knowledge is quite more valuable than to learn the current trendy framework.
There is a broad range of libraries out there. Some can condition a lot your code base and other can only compromise a concrete aspect of your application. The rationale is the same as above: we hace to balance the cost of a new external dependency and its consequences against the cost of coding the functionality you want to get from that.
The tools chosen only condition the development process, not the code. So, it seems they are less dangerous, especially in small or medium-sized projects; we can regret using without large consequences.--
Reuse knowledge instead of reusing software
The alternative model to intensive reutilization of software is the intensive reutilization of knowledge. In this internet era it's simpler than ever to learn and leverage ourselves by shared knowledge and experience.
It can seem an inefficient philosophy but I do not think that: nowadays to learn is highly efficient and cheap. If we devote to go deeply into basic knowledge: languages, standards, patterns, protocols, etc. we can get rid of most of trendy libraries and fads (and save much time) and focus on what our application really requires; by the way, we will become better professionals.
People say: Do not reinvent the wheel!. But the wheel is already invented, and you can take advantage of that knowledge to create the wheel that fits your needs.
I am not denying the usefulness of many libraries, I'm saying that I have to have an important reason to use external software and I usually try to understand its internals in order to not lose the control.
I claim against the use of libraries 'by default', against the lack of knowledge on basic standard and technologies and against the pile of software layers that fit all. I do it not because I think I have the absolute reason but to resist and protect the value of my approach from what I consider over-engineering fad and the trendy library culture.
Basically it's a personal decision -we are economic beings too- we can spend your time trying trendy and transient libraries and frameworks or do it learning fundamentals: standards, architecture, patterns, protocols, etc.