[wbillingsley]

Thematically, I'd say Angular's dependency injection is "supposed" to be resolved by the tooling. If you look at Angular.dart, it doesn't have this particular hack because it uses the type system to resolve what to inject. But Javascript doesn't have static typing... "specify it twice (as a list of strings, and then a list of arguments)" is a fairly ugly and error-prone solution. Specify it once and let the tooling do the work seems like a reasonable idea.

I tend to find that most of the awkwardnesses I come across in Angular likewise come from the underlying nature of Javascript and HTML. As a concept, Angular.js seems to me to be fairly straightforward -- client-side compositing of templates against data (without imposing constraints on the type of data), plus routes and a promises library for http calls.

[AdrianRossouw]

"specify it twice (as a list of strings, and then a list of arguments)" is going to result in localized errors, in your own code, not spread through all 7 levels of dante's museum of abstractions.

Doing it at build time is also preferable to trying to do it at runtime, like it does now.

I would agree with your assessment, otherwise. I just think that this specific technique was railing against JS a bit too much, and was ultimately a dead end.

Interestingly, the new DI framework also uses ES6 and traceur.