[winkelwagen]

I agree with the main sentiment from the article. Although I do think they are discussing Inversion of control more-so than dependency injection.

One of my first languages was .net and I was never able to really understand DI in that context that well.

Actually using javascript and ducktyping made me understand what it actually was.

I remember a .net job interview where I had to write a micro-service and opted to construct the dependency graph in the main function initialising "all" the classes there. Instead of discussing the pro's and con's of that approach they berated me for not using a DI framework (No I did not land that job, but in hindsight it was the most expensive job interview I've ever had. The room was filled with 8 developers going over my code).

The main thing the article glosses over is state. something people with a functional background hide from. But if you look at something like the httpclient in .net. I think it took the .net world like 10 years to start using the httpclient properly. Scope and lifetime of those kind of objects are important. managing connection pools, retry state, throttling or the incoming http request. DI does make that kind of thing easieR (I'm not saying it makes it better)

Look at clojure's component(https://github.com/stuartsierra/component), I'm not a clojure expert by far. But it is kinda DI/IOC in a functional language.

In closing we can agree that it is underused in the right places and overused in the wrong ones.