DI vs. Module Loader

di.js

// The DI pattern assumes that MyService will be a class or constructor function
import {MyService} from './myService';

@Inject(MyService)
export class MyThing {
  constructor(myService) {
    this.myService = myService;
  }

  someAction() {
    this.myService; // the injected instance
  }
}

// Here you can use DI to inject mocks and test

moduleLoader.js

// Versus the module loading pattern where you can just return the service object. Javascript
// has objects aka singletons by default. The `new` keyword was a hack. Classes are better but
// still not necessary to create a "singleton".
import {myService} from './myService';

export class MyThing {
  someAction() {
    myService; // it's just an object
  }
}

// Here you use Jest, injectr, or Squire to mock and test

x_thoughts

Both of these approaches work. The DI pattern is more powerful. You can wire up more
complex objects as show here https://gist.github.com/domenic/5753428. On the other
hand, the module loading pattern is simple and you see exactly what's happening.
Mocking is just as easy. You just lose some of the wiring power that DI provides.
In my experience you typically don't need the extra layer of DI and you can get away
with the module loader by itself.