Separating your glue code from your business logic is a good idea for several reasons. That's all dependency injection, or inversion of control is. It's more of

Separating your glue code from your business logic is a good idea for several reasons. That's all dependency injection, or inversion of control is. It's more of a design pattern than a framework thing. And structuring your code right means that things are a bit easier to test and understand as well (those two things go hand in hand). Works in C, Rust, Kotlin, Javascript, Java, Ruby, Python, Scala, Php, etc. The language doesn't really matter. Glue code needs to be separate from whatever the code does. Some languages seem to naturally invite people to do the wrong thing. Javascript is a great example of this that seems to bring out the worst in people. Many of the people wielding that aren't very experienced and when they routinely initialize random crap in the middle of their business logic executed asynchronously via some event as a side effect of a butterfly stirring its wings on the other side of the planet, you end up with the typical flaky untestable, and unholy mess that is the typical Javascript code base. Exaggerating a bit here of course but I've seen some epically bad code and much of that was junior Javascript developers being more than a little bit clueless on this front. Doing DI isn't that hard. Just don't initialize stuff in places that do useful things. No exceptions. Unfortunately, it's hard to fix in a code base that violates that rule. Because you first have to untangle the whole spaghetti ball before you can begin beating some sense into it. The bigger the code base, the more likely it is that it's just easier to just burn it down to the ground and starting from scratch. Do it right and your code might still be actively maintained a decade or more in the future. Do it wrong and your code will probably be unceremoniously deleted by the next person that inherits your mess.