Echo JS 0.11.0

@tracker1 - For me it makes a lot of sense for a couple of reasons:

1) The module system in JS is OK as long as you are targeting client side code. When we're talking about server side (thinking universal apps) as well it suddenly becomes an issue where you need a *certain* instance and not sharing it thus sharing the state. What you end up with is a need to manually somehow get your dependencies while you cannot (at least not by default) just require your dependency. 
Moreover, I find it that using a DI system makes testing much cleaner vs mocking the require and thus hiding the actual dependencies a certain module needs. Not saying it is a bad way to do it but it just makes sense for me like this, especially coming from a PHP background. I saw that the industry also starts to see this. Check redux (if you are familiar with it) with the latest release for the redux-thunk, where they allow you to pass a "DI" object which contains whatever you want.

1) We at Middleout are using Typescript exclusively for everything so we have types for almost everything, thus types injection via constructor (or method) seems much cleaner overall.

2) We are working quite a bit in an OOP fashion so classic dependency injection makes more sense than the current module system IMHO. 

I do agree that DI systems usually make it harder to track stuff down (In some worst case scenarios I had to add logs to see what is being constructed from where) but I find the gain of having explicit constructor dependencies *and* auto creation of objects an overall positive gain. 

If you are developing a small app then of course, DI is usually an overkill, especially if you are not actually hitting any of the universal code issues (thus making the modules system perfectly fine in theory).

Thanks for the comment!