When we talk about dependencies, the natural sense is about dependencies from bottom to top, just like how buildings are built. But unlike a building that stands for tens of years with little change, software keeps changing during its life cycle. Every change costs, more or less.
The dependency inversion principle declares that entities should depend on abstractions, not on concretions. Higher level code should not depend directly on low-level implementations, instead, it should depend on abstractions that lead to those implementations. And this is why things are inverse.
Still taking the HTTP client and API hub as an example, which obviously violates the dependency inversion principle, taking the foreseeable application into consideration, what the API hub should depend on is a messaging mechanism bridging client and server, but not bare HTTP client. This means we should have an abstraction layer of messaging before the concrete implementation of HTTP client:
Compared to other principles discussed in this chapter, the dependency inversion principle cares more about the scope of modules or packages. As the abstraction might usually be more stable than concrete implementations, by following dependency inversion principle, we can minimize the impact from low-level changes to higher level behaviors.
But for JavaScript (or TypeScript) projects as the language is dynamically typed, this principle is more about an idea of guidance that leads to a stable abstraction between different layers of code implementation.
Originally, an important benefit of following this principle is that, if modules or packages are relatively larger, separating them by abstraction could save a lot of time in compilation. But for JavaScript, we don't have to worry about that; and for TypeScript, we don't have to recompile the entire project for making changes to separated modules either.