[AdrianRossouw]

How I feel about angular now is that it's a vision of what web development could be like in the future.

A lot of this stuff only really makes sense once the entire environment is present. Polymer is actually fairly similar, but trying to tackle the problem from a different angle.

It has the potential to do less in the future, and I think right now it's an interesting proving ground for and ideas and teaching people to think about things differently.

You should see this slideshow about their plans : https://docs.google.com/presentation/d/1Gv-dvU-yy6WY7SiNJ9QR...

I'm much much more comfortable with backbone myself. If I didn't specifically set out to build a couch-app, i would not have been able to justify using angular.

interestingly, i realized i like backbone for the opposite reason i like angular. I don't actively expect it to get more complex over time. It just feels like each new release 'tightens up' the formula.

[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.