Not loving the Dependency Injection Pattern

tldr; Highlighting a few of the key problems that dependency injection has solved in comparison to global importing and what’s left desirable.

Many modern developers are well aware that the pattern of importing all libraries from the root of the app is going out of style. Especially with the advent of Webpack, Browserify, etc, emerging as the popular choice of technology. However, today we’re going to take a different route. A route that explains how we would much rather prefer to not move along with this trend. We are opening this comparison as a biased and personal preference, as we are confidently sticking to the lower-level method of importing all dependencies into the app directly without the use of “require” statements. Not to mention, Grunt/Gulp are bare-bones enough to where you’re allowed to have an unquestionable amount of control, to where you can define the layout of your package directory as you please.

Benefits of using global imports:

  1. One attractive aspect of dependency injection is the encouragement of code modularization, without it however, you do not have to have to import dependencies in every file. Charming. With global importing, every dependency that is used in almost every file is globally available to you, and larger dependencies (D3.js, three.js, etc) can be imported programmatically as needed.
  2. Memorizing where packages are in larger projects becoming slightly complicated and cumbersome when rapidly developing or prototyping. require(‘src/project/demo/main/assets/styles/images/logos/icons/…’) versus just having it available…
  3. You’re at the mercy of Webpack configurability which have come to cause some issues when a several of the requirements for the application are assumed.
  4. While a lot is given to you in Webpack, from a dev server with everything you will ever need at the convenience of a one line command-line entry, to a wide support of Typescript or Babel that can be imported in one line within the webpack config; the lack of understanding of what went into the libraries is concerning. Many developers may be blissfully unaware of the lack of performance in achieving a result or assumptions the libraries are making until it’s too late and the project has scaled beyond repair.
  5. For teams who are in favor of building a static set of assets as an end result, Webpack may have been a dream come true. Building your code base in a modularized way and having the output come out as a set of static html, JS, CSS; all without having to bother with writing more code than you needed to. This can be achieved with global importing, and the same premise remains: the expense is a loss of control.

In summary, with Grunt/Gulp you have a lot more preparation of the outcome and scale of your project, you install what you need and ignore what you don’t want. With Webpack, you must adhere to the framework and its limitations.

The idea of utilizing a Dependency Injection management framework is absolutely attractive in many fronts. Although, any similar result could be achieved with a bit of practice with Grunt/Gulp, and would end up being more rewarding in the long run. Lastly, we’re not trying to convince anyone that Webpack is an inferior paradigm or anything of the sort. Webpack is great, but it just wasn’t for us. Also, for anyone else who has had the same feeling, you’re not alone!