I too think Angular is overly complex and "magical."<p>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.<p>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.<p>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.
While I do the think author makes too big a deal about this, I <i>very much agree with them</i>.<p>The main issue is whether or not we should be teaching people, as a first brush with Angular, to code things with "automatic Dependency Injection", where the types are inferred from variable names. The alternative, and only way to code a "real" application, is to pass the names of things you want injected as strings.<p>For people unfamiliar with Angular, this difference means turning: myFunction(Dep1, Dep2) into myFunction(['Dep1', 'Dep2', Dep1, Dep2) (more or less).<p>Doesn't seem like a big deal, does it? But I think the decision to teach people the "bad" way to do things, all for the sake of making things "simpler", is completely wrong, and misunderstands what kinds of complexity people have a problem with.<p>Complexity isn't telling people "write the same word twice, cause that's how it works". Complexity is telling people "here's <i>another thing</i> you have to learn about this framework".<p>This is a small matter, but it isn't trivial, and is a common mistake with Angular.js (hiding the wrong kinds of complexity).
This is part 3 of this series of articles<p>1. i was wrong to be afraid of angular.js
<a href="https://news.ycombinator.com/item?id=7384937" rel="nofollow">https://news.ycombinator.com/item?id=7384937</a><p>2. why i was wrong to be afraid of angular.js
<a href="https://news.ycombinator.com/item?id=7394959" rel="nofollow">https://news.ycombinator.com/item?id=7394959</a><p>This is where i discovered the exact thing about angular that freaked me out the most, and how I was finally to get down in words what I felt about it.<p>I made a github issue about it, and the devs acknowledged the issue, saying it was no longer part of angular 2.0
As far as the particular issue he picks on, he is making a big deal about something that's not, at least if you accept the general premises of Angular, and trying to pin the core of his whole argument on that. Which is dumb.<p>Anyway, I have used many, many different UI frameworks on different platforms over the years. Including different .NET systems, Backbone, Angular and to some degree web components. And many other lightweight and heavyweight systems.<p>I am actually amazed that developers are not immediately seeing the obvious advantages of Web Components (with Polymer for now).<p>I am amazed that people are still trying to master AngularJS when we have Polymer. (At least the people who can tell their users to use a new version of Firefox or Safari, which is actually quite a lot of web apps these days, although obviously not all).<p>Angular is very obviously more complex than necessary.<p>Very few people are going to be with me on this, but this whole idea of separating out scope and avoiding global variables at all cost has got to the point where it is just ludicrous. And the only explanation is that this stigma about global variables has a religious and un-questioned association with incompetence. Unfortunately that particular cargo cult can lead to things like Angular DI.<p>Why aren't more web developers excited about Polymer and Web Components? Because many web developers, despite experience with Angular, get distracted by DI and other over-complex topics and somehow fail to completely grasp the basic concepts and advantages of what a user interface component is and does.
It isn't ready yet (another few weeks until a 0.1) but I'm working on a simpler UI framework that lets you bind HTML elements directly to REST-ful URLs, cutting out a big swath of complexity for many apps:<p><a href="http://intercoolerjs.org/" rel="nofollow">http://intercoolerjs.org/</a><p>Again, <i>this is not ready yet and I'm actively changing things</i>, but if you are interested in an AJAX framework that is concerned with keeping complexity to a minimum, it might be worth checking out. Comments and criticisms very welcome.
I think DI in Angular should be an opt-in thing, too confusing otherwise. I've had moments where I thought I was just writing a regular function, and then Angular started throwing exceptions because it was trying to inject dependencies based on the argument names. (And the solution was to write a function with no arguments that returned the actual function with arguments!)<p>There are conventions around what string maps to what thing, so that sometimes strings like "controller" or "provider" are inferred and not required to be specified. This is bad -- things should just be referred to by their full names.<p>It would be nice to have the ability to ask for things directly in require-style function calls instead of having them be parameters to a function. It's actually sort of crazy that you can define a controller (for example) with angular.controller('MyController', function(){}), but then you can't ask for it back with angular.getController('MyController'), or whatever.<p>All this makes it a lot harder to try things out in the console, and lengthens the feedback loop of determining what works and what doesn't.<p>And I didn't even know about the minification thing. That is legitimately terrible.
It's interesting that he has a visceral reaction to the "hackiness" of Angular's clever way to do runtime DI but no visceral reaction to the fact that the problem was created by a third-party program which was instructed to purposefully obfuscate the actual source code of his program before delivering it to the runtime... the JavaScript world is indeed a funny place.<p>That said, I am empathetic to his argument. But as a very happy Angular user, the benefits that are gained by having a runtime DI layer that works such that it can be built into the entire platform so far outweigh the one-time tooling change that it doesn't bother me at all.<p>The rest is a slippery-slope argument that I don't think is fair. If you trust Angular as a project, then you have to trust to some extent that they'll make sane decisions. Since this particular clever hack is the only one that won't get "better" over time as runtimes improve, I think that they deserve the trust so far.
AngularJS is not complex , when I think complex , I think SpringMVC or Struts complexity. AngularJS has problems ,but complexity is not one of them, definetly.<p>Seems like JS programmers who only know JS think they can get away with ignoring patterns like dependency injection, Guess what, in order for code to be maintainable and testable it needs it.<p>Front-end is about GUI dev,and that's where OOP shines. It's high time for JS folks to read classics like "Design Patterns" books, and embrace SOLID principles , or AngularJS wont even help when developping their so called "fairly large" apps.
The author is concerned about <i>the future</i> of Angular because of the idiosyncrasies of <i>one method</i> of including dependencies. I mean, really? Is it so bad, the stench of automatic dependency injection, it overcomes all other beneficial features of Angular, it would jeopardise it's future as a web framework, such that it would lose compatibility with future browsers and your web app built in angular will stop working, with no support available? IMO it's a bit hyperbolic to suggest this is the case.
This seems like a one-sided overthinking of the auto dependency injector (which is like 30 lines of code).<p>1. The auto DI means beginners can get to "Hello World" in angular without learning some wonky injector syntax. If Angular's goal was to bring some of the jQuery crowd on board, then it was a smart move.<p>2. The auto DI doesn't survive minification, so not all code can be copy-pasted, and there are two different syntaxes. Unnecessary complexity?<p>I see no reason to make a bunch of analogies to argue on one side.
- AngularJS is a tool for building complex single-page web applications, not brochureware.
- If you're building complex SPAs, you're going to require a decent level of tooling.
- If you have a decent level of tooling, the points in this article are meaningless.<p>As an aside, ngMin is the most trivial thing in the world to set up, and if you can't figure it out, array notation is slightly painful but well worth it for all of the tools Angular provides.
I still can't decide if angular dependency injection is more amazing or revolting.<p>It's magic, it's non-intuitive, it breaks the standard paradigm that function arguments have no external significance, and it doesn't add much real value by just saving one extra line per function - <i>inject(fn, ...)</i><p>On the other hand, it's elegant if you ignore all the above criticisms.
I'm a huge fan of dependency injection, it makes life infinitely better when designing your code & testability.<p>That said, I'm somewhat sympathetic to this complaint - it turns me off towards Backbone. However, I argue that it isn't nearly as bad as views with Backbone. In addition, this is changing in 2.0 with a much cleaner injection mechanism.