[wprl]

I too think Angular is overly complex and "magical."

The JavaScript world should be learning from the mistakes of monolithic and semi-monolithic frameworks such as ASP.NET and SEAM not trying to recreate them.

For my part I'd like to see separate libraries for events, views, models, syncing models to persistent storage, and binding models to forms. Small micro-libraries allow maximum flexibility and efficiency, and facilitate more maintainable code.

The way that Angular violates separation of concerns between presentation and view is another symptom of a monolithic approach, and a step backwards in HTML client software design.

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

[grrowl]

One of the first things that "broke my brain" when starting with Angular.js (during its wild 0.x days) was inferred injection — I know Javascript. I know how arguments are passed. What the fuck is happening here??

At that time documentation was sparse and often incorrect, but I'm very glad they're moving to a more predictable and sane DI model.

[cmbaus]

I had this exact experience yesterday.

I was reviewing the code spit out by a Yeoman generator, while reading some Angular docs (admittedly out of order), and I has confused about how variables were being defined. I finally read something that explained what to do (add a variable using a specific naming convention to the function declaration). I realized the framework was doing some sort of backhanded meta-programming, and I didn't feel so bad for not understanding what was going on.

The problem with this is you can be a pretty knowledgable JavaScript programmer and still not understand the code or the documentation. For this reason, I've never been a fan of meta-programming in general. Not only do you (as an application programmer) have to understand the language as defined, you have to understand other frameworks' reinterpretation of the language. If you bring in multiple frameworks that do this, it quickly becomes more difficult to reason about what a program does by simply reading the code.

[pault]

The injector is all crazy pants: https://github.com/angular/angular.js/blob/master/src/auto/i...

When I realized angular actually parses views and module definitions and rewrites them, I lost interest in trying to figure out what was going on under the hood, and decided to stick with backbone. While the angular devs are obviously brilliant, the complexity is horrifying, and I don't want to debug my application code when I can't reason about the framework's internals.

[acjohnson55]

I think one of the nice things about Javascript (man, I wouldn't have seen myself saying that a year ago) is that this kind of hackery isn't really considered idiomatic. You can get so much mileage out of an extra function expression wrapper.

[Encosia]

I wish I could give this comment a million upvotes.

From my perspective as someone who has developed on the MS stack for 15+ years, frameworks like angular and ember strike me as (retroactively) following right in the footsteps of Silverlight and ASP.NET WebForms. To be clear, I don't think that's a good thing.

[EricDeb]

I think simplicity is undervalued in the programmer world in general. It takes so much more mind-energy for someone to implement/refactor/add-to/test complex code written by someone else as opposed to simple/verbose code.

[frou_dh]

> I think simplicity is undervalued in the programmer world in general.

I imagine every programmer will claim to value simplicity. Trouble is, they're all talking past each other because their working definition is "the way I personally do things".

[AdrianRossouw]

maybe, except that I try to improve how I do things on every iteration.

i've been finding that it helps me to think about these things in a more concrete manner, so that i can vocalize to myself what I didn't enjoy in the recent experiences.

[frou_dh]

I found Rich Hickey's dissection of simplicity to be dynamite as usual: http://www.infoq.com/presentations/Simple-Made-Easy

[etherealG]

spot on. his way of putting it that simplicity is objective and ease subjective really nails it. most people say simple and mean easy.

[AdrianRossouw]

this was a great watch. thanks for that.

It helped me focus a lot of things I have been feeling innately for a while.

[calinet6]

You're right, simplicity is undervalued.

The problem is, simplicity is often not a possibility. The problems we're solving are complex, not simple. Simple solutions to complex problems are to be sought after and cherished, but they are also incredibly difficult and idealistic.

Instead, we value pragmatism. We favor structure which simplifies, rather than structure that is simple in itself. We do this because it increases our productivity in solving highly complex problems; problems that simpler foundations would not support or would not assist.

Angular simplifies, hands down. It does this by swallowing the complexity into itself, and dealing with it in some rather intelligent ways so you don't have to. This, above all, you need to understand to use it effectively. Some complexity leaks; a great deal of it is contained and managed well.

You may love a handsaw and hammer and nails for their simplicity and clarity, and there is merit to that, but they can only build so much so quickly.

Angular is not a combination of those simple tools: it is more like a 3D printer, enabling you to build components of things and use them to make final products as fast as you can dream them up. It knows what it is, and so should you. Please excuse the lofty analogy.

[AdrianRossouw]

yeah man.

when i subtitled my blog sensible complexity, I didn't realize that it was actually something I cared so deeply about.