Develop Reference

Is there a point to dependency injection container in Javascript?

I'm a long time back-end developer but recently I have managed to develop some medium sized one-page web-app.
On server side I have worked with many modern frameworks like Spring, Grails, Symfony, Silex, Slim and other and I really liked the concept of micro-framework of Silex or Slim (in all case MVC frameworks).
On client side, due the different application nature I think MVVM is the best approach.
Quickly evaluating some micro JS framework (riot, backbone) and comparing to my server side background I have noted that in JS Frameworks the Dependency injection Container (DIC) is not considered a fundamental part of a framework (micro frameworks at least).
On every server side mordern MVC (Micro)Framework the DIC is the foundation of the framework but I don't see this happen on Javascript Frameworks (micro frameworks at least, I know heavy fat Angular have it).
From my searches the only standalone DIC container for JS with some followers is bottlejs
that has only 672 Stars on GitHub. Comparing this to PHP where there are many standalone DIC projects, for example Pimple (1570 Stars) or PHP-DI (1040 Stars) you can see a great disparity
Do you think is a critical mistake or subvalutation that many js micro-framework do?
Or the modularity, testability and mantainability of DIC is achievable in other way in JS.

Singletons can be naturally produced with JS modules, so this isn't a concern for DI. And testability is achievable with JS module mocking, too (proxyquire, etc). This is what some frameworks (Durandal, React-like) rely on.
In testing rig ES6 modules usually use require under the hood any way, so the method is still applicable. proxyquire and other cache-mangling libraries may have their limitations (deep dependencies), but in well-written test you usually mock the units one level higher, so this generally works. This is how this is done in Jest internally, which is conventionally used to test React and React-like.
So this depends on what these 'micro-frameworks' really are. As for current-gen macro-frameworks, React is supposed to not need DIC (also, it isn't opinionated, it's developer's responsibility to extend it's functionality). While Angular, Aurelia, Ember, Polymer and Vue 2 feature DIC - because it generally benefits application design.

why dojo 2 doesn't take an already created framework as base?

why dojo2 doesn't take an already created framework as base. For example they could use angular2 as base and then only create the widgets.
why they want to create everything from scratch? Is there any advantage on doing that?

Angular and Dojo are two different things.
Dojo is a JavaScript toolkit. Provides everything you need to build a Web app. From widgets, utilities, pub/sub, aol programming even a build tool and much more.
AngularJS is a specialized structural framework for dynamic web apps.
The advantage of dojo is that cover majority of aspects needed for a complex Web app with a standard API.
If you would use instead several combination of frameworks, would be more difficult to achieve such uniformity.
Interestingly Dojo2 now use an external library for virtual dom called maquettejs for its widget system, but I believe it is a special case otherwise dojo itself is quite comprehensive toolkit.

Hm, apart from dojo's modularity and different goal :
dojo appeared in 2005 (history)
and angular appeared in 2009
Note that dojo2 is beta.
They could use angular (but why a new isolated product) or polymer (but not serverside) or react (but not typescripted) but why should they change the philosophy behind the widget system at all. They recently decided to support TSX which is a react like syntax.

Are all Flux for Angular Libraries Experimental?

Facebook React can use a unidirectional data flow pattern called Flux to give structure to applications by using Views, Actions, Stores and a Dispatcher.
I have found the following Flux libraries for Angular:
ng-flux: https://github.com/JustinWinthers/ng-flux
angular-flux: https://github.com/brentvatne/angular-flux
song-flux: https://github.com/gah-boh/song-flux
And this sample: http://victorsavkin.com/post/99998937651/building-angular-apps-using-flux-architecture
Are any of these production ready?
Which ones have plans to migrate to Angular2 and integrate with the Component Router?
I can't seem to find any large application samples using any of these libraries. Additional links would be useful.

I authored ng-flux and I wouldn't say it's production ready since I haven't had the time to test it in a variety of projects. However I am using it in a fairly large enterprise class application currently. I agree that flux-angular has a good team around it and I'd recommend their library. Regardless, flux is simply a pattern that you can incorporate on your own. The issue with any Angular 1.x based approach is always the way Angular manages digest cycles and you have to sometimes jump through hoops for views to update in the background if you process data outside of the Angular namespace. In ng-flux I force a digest cycle if one hasn't occurred.
Flux as a pattern works well to me because it makes debugging and code separation much easier on larger projects, so my goal was to use this pattern on a project that already had substantial legacy Angular code and decrease the time it was taking to triage errors. It's an actuarial application with lots of calculations, so finding small data discrepancies fast was necessary. Writing ng-flux achieved this for me.
Regarding Angular 2, I think it will be easy enough to incorporate Facebook's dispatcher in your project and allow it to manage data flow. I think once Angular 2 is ready, based on what I've read so far it should be easier to use third party JS libraries - especially since Angular 2 will follow more of a web component based architecture somewhat similar to React. I've even seen promises that it will be easier (or more organic) to use third party routers, etc.... If this holds true, I doubt you'll actually need a library to manage a flux based data architecture in your Angular 2 apps. It should be fairly seamless to simply use something like the Facebook Dispatcher as a singleton (properly namespaced) object in your app that you can reference in your Angular components. I think most of the library authors out there realize this - it's more a problem for Angular 1.x apps to use this pattern than it will/should be for Angular 2 apps.
https://github.com/facebook/flux/blob/master/src/Dispatcher.js

I am not a pro in ReactJS, however I am not sure that integrating Flux with AngularJS is really a focal point for many Angular developers. With the release of 2.0, the Angular teams is continuing to make the framework more and more self-sufficient so people do not have to jumble together different libraries, but instead can just rely Angular to accomplish the task at hand.
That said, it seems like this flux-angular libary is stable with versions' 1.x, and it seems like it has pretty good support. I know it does not help your case when dealing with 2.0, however, it does seem like a solid enough API; but, then again, maybe I am just biased because of the functionality I have been able to replicate using Angular 1.2 & 1.3 :)

Is it possible to combine Dojo with other JS frameworks?

We are using Dojo (1.9.3) as a JS framework for building a single page application. We are however spending too much time on the quirks of Dojo, so even simple tasks take a long time to implement. And since there is lack of proper documentation, we often have to resort to reading the source code and then implementing a workaround.
I feel that we would speed up development, and make it easier to maintain the code if we moved to some other framework. Our codebase is rather large, since it is a complex application, so we do not have time to re-write the whole thing at once. I was therefore hoping that it might be possible to combine Dojo with some other framework, so that we can move away from Dojo incrementally. I have only dabbled with these other framework in my spare time, and only wrote some small example apps, so I do not feel that I can really say whether or not they would play well with another framework, so I'm hoping that some of you out there can.
The frameworks I've been looking into - in the order of what I'd prefer based on my short investigation, but feel free to convince me otherwise.
Ember
React
Polymer
Angular (last due to me being scared of the major 2.0 overhaul)
While the main question is whether or not it is possible, please also advice on if you think it is a bad idea to do so.

The most I can say from the Dojo end of things is that Dojo itself is a toolkit, not a framework per se, and thus generally should not interfere with other scripts or frameworks. The reverse, on the other hand, can't always be said. So while I can't speak for all of the choices in your list, I do not think that Dojo itself will get in your way.
One possible exception I can think of is if any of the frameworks in question augment native prototypes, particularly Object, since that will affect enumerable properties in all objects and can wreak havoc on any scripts that use for...in loops without hasOwnProperty.
The only other exception I can think of is whether any of the frameworks in question for some reason do not coexist well with an AMD module loader.
That being said, I would also advise you to take the "promise" of frameworks with a grain of salt - you say that right now you are finding that implementing things with Dojo takes effort, and naturally the frameworks you list are attractive because they make certain parts of application development easy by offering patterns and conventions - but the question you should ask is, how hard does your framework make your job the moment you need to do something outside or against those conventions? Dojo may have a learning curve, but it generally doesn't prevent you from doing anything.

You can use them together, but it also depends on what you're trying to do. Some actions might take more time for integration than others.
Dijit
I only have experience with Ember.js and AngularJS, but a common concept in these frameworks is data binding. Data binding allows you to simply update the model and the view will reflect the changes in the model.
However, these usually do not work nicely with widgets. Widgets (like the Dijit library) create their own DOM and because of it, frameworks like Ember.js or AngularJS are not "aware" of these changes and cannot update the view in that case.
To make it work, you will have to wrap your widgets into components (Ember.js) or directives (AngularJS). An example of such wrapping can be found in this answer.
Dependency loading
Dependency loading might be confusing. AngularJS comes with their own dependency injection system, and means that you will have to use the Dojo AMD loader for Dojo modules and AngularJS dependency injection for AngularJS. The two work nicely together as far as I know (I've seen examples with the RequireJS AMD loader, so it should be possible).
With Ember.js I had a bit more troubles integrating with the AMD loader. The creator of Ember.js (Tom Dale) does not believe in AMD, and I've seen several issues trying to load Ember.js components with an AMD loader.
It all depends on how you wish to use these frameworks and what extra effort you want to make. To me it looks like you're not even sure what to use these frameworks for, since React.js or Polymer has a completely different purpose than AngularJS or Ember.js for example.

Is Google's Polymer a fully functioning Frontend Framework to Subsitute OR Complement other Frontend Frameworks?

The question is in regard to AngularJS, BackboneJS, EmberJS and the other frameworks.
I have to translate a project from php to javascript and I have to decide, if I am going to use:
AngularJS
Polymer
A combination of them
I prefer using Polymer, because I like it.
Yet, I am missing (and correct me where I am wrong) the ability to make:
Views and link between them (like in Angualar)
Controllers
I know that the structure is up to me, on how to build my application, but it seems that angularjs has a well predefined structure for building mvc-applications.
Therefore I want to know: Is Polymer a substitute for Angular, if you want to build a well structured web application or is Polymer complementary library to be used along other existing frameworks?
EDIT 21.09.2014
No one really answered the question to my fullest satisfaction, therefore I marked it as not answered yet. Many say it just "DEPENDS". But no one is able to elaborate, on what exactly it depends.
On the complexity of the application? On the needs of the application? For what needs does Polymer fit and for which doesn't it fit? These are the answers I was looking for.
Some say it can be used as a frontend framework. Others say that is just a library and others say "Yes and No". Unfortunately rather confusing answers.
I wish there was an official answer to this, but I let you in on what my feeling is. I believe it is a substitute, but Polymer hasn't yet reached the structure, that other frameworks require to work. Maybe this is intentional, maybe it is just a matter of unreached maturity, because the framework is new.
I hope that the creators will explain, when it is best to use AngularJS and when should someone use Polymer for building large scalable web applications.
EDIT 15.08.2015
Polymer 1.0 is out. And it turns out Polymer is officially NOT a framework and is supposed to work in a complentary way with other frontend frameworks.
https://youtu.be/fD2As5RmM8Q?t=6m42s

IMHO both are two different things and they both are to serve two different purposes. Though they have some common features to offer, data-binding can be one of them.
Polymer
If you truly want to use the Awesome Webcomponents, Polymer is one way to achieve that. There are other options like you can go with your vanilla JS, or use other libraries like X-Tag from Mozilla or Bosonic. These libraries polyfill the webcomponent features which are still in drafted state. So, these libs help us have/provide the same user experience across browsers even where there is no native support for the webcomponents.
Angular
This is a full fledged MVC framework. And people here know what Angular as an MVC framework includes/provides.
That all said to answer your question
Google's Polymer is not exactly a fully functioning Frontend Framework and can be used as a Subsitute OR Complement to other Frontend Frameworks. It can be used as a substitution for the V part in Angular as MVC. Like people use React as V in different frameworks. It is not much a different case for me. Being more specific in case of Angular, Polymer is like directives in Angular 1.x while like components in upcoming Angular 2.x.
References
To be more sure of what I am talking about and for additional sources on how to use the Polymer with Angular2 (Angular2 not released to this date)
you can check this video at "https://youtu.be/7WgEuNZCCHk?t=32m15s" starting from time 32:15 where Rob explains how to use the generic webcomponents/polymer as the components/View in the Angular2.
you can check this project "https://github.com/rkirov/youtube-app" which uses Angular2 and google-youtube web component.
https://github.com/ebidel/polymer-experiments/tree/master/polymer-and-angular/together
From the polymer-starter-kit
Framework-free, or framework-compatible
Build your app out of elements, or wire in an external framework to handle business logic. It's up to you!
So, in my view these two projects are not competing each other.
Webcomponent Specs
The webcomponent specs are here for one's reference
Custom Elements - http://w3c.github.io/webcomponents/spec/custom/
HTML Imports - http://w3c.github.io/webcomponents/spec/imports/
Shadow DOM - http://w3c.github.io/webcomponents/spec/shadow/
I just wish the webcomponents are native to the evergreen browsers ASAP.

From the Polymer Starter Kit:
"Framework-free, or framework-compatible
Build your app out of elements, or wire in an external framework to handle business logic. It's up to you!"
Update:
What was described as Carbon Elements seems to fall under:
Polymer(version 2) App Toolbox
Component-based architecture using Polymer and web components.
Responsive design using the app layout components.
Modular routing using the elements.
Localization with <app-localize-behavior>.
Turnkey support for local storage with app storage elements.
Offline caching as a progressive enhancement, using service workers.
Build tooling to support serving your app multiple ways: unbundled for delivery over HTTP/2 with server push, and bundled for delivery over HTTP/1.
Carbon Elements adding framework features
During The Polymer Summit 2015 Keynote, Google announced a new "Polymer idiomatic and framework oriented" set of elements, tentatively named the Carbon elements.
Some quotes from the longer tjsavage answer regarding Angular 2 vs Polymer Carbon:
"The trick is in thinking about the web platform as an application framework... Polymer the library is to the web components component model as the carbon elements will be to using the web platform itself as an application framework: the opinionated rails to make it easier to understand and achieve."
"Angular 2 will provide one way of structuring your application that uses Angular's view of what makes a good application structure. The carbon elements will provide a different way of structuring your application that more directly uses what the web platform itself provides as its structural underpinning."

Polymer is almost fully functional.
Currently it is missing routing for example but this doesn't mean you can't do this with Polymer.
There is now https://elements.polymer-project.org/elements/app-route
In Dart also dependency injection works fine with Polymer because of the types. If it's possible in Dart, it's possible in JS as well because Dart transpiles to JS. DI in plain JS might be more cumbersome though.
In this package (Dart)
https://github.com/bwu-dart/bwu_polymer_routing
I made the routing and DI packages used by Angular.dart available for Polymer. There are also routing packages for Polymer.js available.

I put together some router demos. The "missing parts" really depend on what type of application you're building.
https://github.com/erikringsmuth/polymer-router-demos

I've used it as both, as an enhancement to an app written in another framework, and as the full framework itself, where it was responsible for every element on the page.
I really like just about everything about Polymer, so I've been very happy using it for the whole app, even built my own router. If you've got an existing app I'd recommend dipping your toe in the water, as Polymer works great composed into other apps to see if it's to your liking.

Let me give this another try:
The key behind web-components (and thus Polymer) is, that they are self-contained. You have a web-component somewhere, you import it, and (if you're lucky) it just works, wherever it comes from. The web-component will NOT interfere other components. So doing things like MVC is not Polymers business (although it provides a data-binding mechanism), as this belongs to the process of tying things together. It is considered to be best practice that these kind of things are solved by creating new elements too, that create and react to events. When it comes to the model you code non-visual web-components, that don't have/need a template. TodoMVC has an (outdated) example for that (https://github.com/tastejs/todomvc/tree/gh-pages/examples/polymer).
So Angular gives you a path to follow on how to do MVVM, whereas it is up to you on how to do the "logic" in your app when using Polymer. IMHO Angular is for more complex and rather enclosed apps, whereas Polymer is for any kind of app, that embraces the web. You even can use Polymer, if you're not writing an app at all ;)