10 ms·

AngularJS: The Bad Parts

226 points by lars 12y ago

moogleii 12y ago
Our team chose to use angular admittedly because of its popularity (it's also why we chose bootstrap over foundation, though that probably had smaller repercussions). Most of the rest of the team then ran off to work on other stuff, so I ended up with most of the angular work. It's been at least 8 months now, and I've gotta say the article is pretty spot on. But I don't really mind anymore for two reasons: I know most of the gotchas now (probably after some loss/whitening of hair), and I haven't used any of the other major frameworks (like ember) to really be able to make an informed comparison. I don't know if there's a real takeaway here. Maybe "evaluate major contenders even if one is super popular" or "be more vocal when someone tries to blindly railroad in a candidate"?
- serve_yay 12y ago
  That happened to me at my last job too. There was no real, actual discussion about what we would use, the party line was "Angular looks like the future of web development" (this claim came from people who spend all their time in C#, not front-end devs).
EugeneOZ 12y ago
that's why 2.0 is complete rewrite - exactly to eliminate all these bad parts.
- DonHopkins 12y ago
  And to make up for it, they threw in some even worse parts. Like breaking the syntax of HTML with their templates, making it impossible to edit, validate, transform, generate or consume templates with any of the thousands of existing HTML and XML processing tools. That, in my opinion, was one of the most terrible ideas I've ever heard come out of the Angular community. And even worse, they refuse to acknowledge that it's a bad idea. That's a very bad sign indeed.
  - EugeneOZ 12y ago
    They moved away from that idea: https://github.com/angular/angular/issues/133 https://github.com/angular/angular/issues/133
- lukifer 12y ago
  Can you specify some of the forthcoming improvements? I want to like Angular, but every time I've actually used it has been a practical and conceptual headache. (Also, the idea that they're creating a new compile-to-JS language seems strange and unnecessary.)
  - ddoolin 12y ago
    A decent overview: http://www.infoq.com/news/2014/10/angular-2-atscript http://www.infoq.com/news/2014/10/angular-2-atscript The kicker is elimination of these concepts: Controllers, Directive Definition Object, $scope, angular.module, and jqLite
    - michaelchisari 12y ago
      The addition of a whole new scripting language seems... overly complicated.
      - paulhodge 12y ago
        It's TypeScript with the addition of a few key features that are helpful for Angular's design. Technically, Angular 1.0 also had its own scripting language too. It's kind of inevitable, since Javascript itself is one of the obstacles to making a better web framework.
        emilis_info 12y ago
        I think it is more Dart... At least the AtScript specification mentions Dart more often than any other language.
      - kuni-toko-tachi 12y ago
        It's utterly insane. Just as in AngularJS 1.3 they have invented there own expression language which floats around in HTML attributes, thereby eliminating the use of Javascript itself and all it's functional goodness. And worst, the user has to incur the cost of downloading this needless code for the expression language to bootstrap the framework.
- andybak 12y ago
  Does it eliminate 2-way data binding? It's the realisation that this is a fundamentally bad idea that was the real kicker for me. The more you try to write clearly structured, maintainable Angular, the more it begins to resemble React.
  - doczoidberg 12y ago
    Angular 1.3 already has one way binding: http://blog.thoughtram.io/angularjs/2014/10/14/exploring-angular-1.3-one-time-bindings.html http://blog.thoughtram.io/angularjs/2014/10/14/exploring-ang...
  - EugeneOZ 12y ago
    default binding planned to be one-way.
- smacktoward 12y ago
  Because "let's rewrite it all from scratch!" always ends well.
xfalcox 12y ago
I can't get the script who counts the bindings to run. Any help? Uncaught TypeError: Cannot read property '$$nextSibling' of undefined
- lars 12y ago
  Maybe you're not using ng-app? In that case, document.querySelectorAll("[ng-app]") wont return any elements, and it wont find the root scope. Replacing "[ng-app]" with a selector that finds your root element should work I think.
  - xfalcox 12y ago
    I'm using the deferred bootstrap indeed. Changed to body and now the script works, thanks! By the way, very nice article, and after working with some real time angular apps, the thing that haunt me the most is the number os binds. People just want more information, and it can hard to explain that we have a limit.
- grumblestumble 12y ago
  I use https://gist.githubusercontent.com/DTFagus/3966db108a578f2eb00d/raw/b1cfa662f8b777dbe07fec51d49d3fc5d3d9cb87/analyse_watchers.js https://gist.githubusercontent.com/DTFagus/3966db108a578f2eb...
hcho 12y ago
The dependency injection thing is really a non issue. Just use something like ng-min before you minify and you are set. Just for the price of another entry in your grunt.js file.
- DrJokepu 12y ago
  He talked about ng-min and why he thinks it's a bad idea.
  - grumblestumble 12y ago
    And his reasoning around that was inanity disguised with high concept. He already advocates for a build process to minify code, ng-annotate simply expands the condensed DI syntax to the array notation.
    - saidajigumi 12y ago
      > And his reasoning around that was inanity disguised with high concept. To elaborate: invoking the argument "you reduce to the Halting Problem, suxxor!" without some concrete examples of how the practical problem (i.e. ng-min implementation) encounters difficulties is disingenuous. It's not uncommon to be able to cover some very useful space of a real-world problem, skirting "inside" a problem which is theoretically limited by the Halting Problem or similar. Occasionally you hit a limitation in your algorithm and add a special case, further claiming practical territory from The NP-Complete Beast. In this case, the strict di enforcement that baconner mentioned in this thread provides an escape hatch: if you're using ng-min while having di enforcement enabled, you'll at least get warned if something goes amiss. If so, add your manual DI annotations, maybe file an ng-min bug, and move along.
- baconner 12y ago
  There's also a new strict di enforcement option that'll make angular error if you don't have the min friendly di syntax in use. That's the best way imo and probably what angular should've always done.
- 12y ago
grannyg00se 12y ago
The scoping should be made more explicitly against a particular controller. The issue is resolved simply by using controller as syntax which is recommended in many blogs. Point taken about the pit of dispair though. http://jsfiddle.net/sndyxfdk/1/ http://jsfiddle.net/sndyxfdk/1/
saosebastiao 12y ago
I'm pretty new to front end development, and a few months ago I started learning Javascript by experimenting with a few front end frameworks. When I got to Angular, I dropped it the moment I saw string-based expressions. How is that even remotely acceptable? I can't even imagine the bugs I would be embedding everywhere.
- hawkice 12y ago
  So, on one hand, yes. As a clojurian, I feel as if I should add an additional level of condemnation (the whole syntax of my favorite language is good old-fashion data structures, as is almost every construct within the language). That being said, it's frontend stuff. The turnaround times are so small that those kinds of bugs are pretty hard to ignore, and very easy to find. Note: I have used Angular, but don't use it anymore, for other reasons.
  - rohamg 12y ago
    What are your reasons?
    - hawkice 12y ago
      Their model for dom composition is substantially more complex than I would prefer. Angular, at it's core, is something like a re-imagining of the dom + js-event-loop that is hackable and modifiable. Good goal, but the complexity doesn't buy you much over e.g. reagent or meteor, which are _much_ simpler.
- general_failure 12y ago
  And your suggested alternative is?
  - DonHopkins 12y ago
    You ask that as if not suggesting an alternative to Angular invalidates suggesting avoiding Angular like the plague. There are MANY viable alternatives. No one solution fits all, but some solutions, like Angular, fundamentally suck at everything, because they're terribly designed, and their developers refuse to acknowledge or correct that fact. In order to answer your off-topic question, which is outside the scope of this article, you'll have to explain in detail all about what your actual requirements and experience and expectations are, and for that you should expect to pay a reasonable hourly rate for an experienced developer to listen to you and give you advice. If that's what you really want, then good luck finding someone to help you with your problems choosing a decent web framework, but at least you now know that Angular simply doesn't qualify. But if you're just trying to imply that it's not right to criticize Angular without evangelizing an alternative, you're wrong.
wnevets 12y ago
This article the bad parts: all of it.
- RussianCow 12y ago
  Could you be more specific about what you don't like about it?
  - wnevets 12y ago
    Extremely derivative and already talked to death here on HN. There is virtually nothing original in this article.
    - mistermumble 12y ago
      This is the first time I have read some of these criticisms of Angular on HN. Can you point to threads where there was discussion of these issues? Would like to get more info on these. Thanks.
      - tim333 12y ago
        There's some stuff here https://news.ycombinator.com/item?id=8507632 https://news.ycombinator.com/item?id=8507632 and here https://news.ycombinator.com/item?id=8527230 https://news.ycombinator.com/item?id=8527230
    - DonHopkins 12y ago
      Please give us links to all the articles criticizing Angular that you think make this article redundant?
      - wnevets 12y ago
        lmgtfy https://hn.algolia.com/#!/story/forever/0/angularjs https://hn.algolia.com/#!/story/forever/0/angularjs
    - talmand 12y ago
nawitus 12y ago
Just today I lost half an hour figuring out why my ng-show worked for all other strings except for "f" and "F". AngularJS definitely has it's own traps..
- Guillaume86 12y ago
  What is the trick? I usually use "!!variable" to ensure boolean conversion so I guess I would have been fine?
  - nawitus 12y ago
    Yeah, "!!variable" works, and in my case I used ".length > 0". Boolean(variable) works too. It's just unfortunate when you're assuming that the expression or typecasting works like in JavaScript, and then AngularJS had to invent these unnecessary rules that make no sense. JavaScript's type coercion is tricky enough, you don't need to make it worse.
- EugeneOZ 12y ago
  Any tool has.
  - nyir 12y ago
    But it would be good if the obvious way to do something didn't have certain magic conditions in which reasonable expectations aren't met (e.g. a variable is evaluated to its value, regardless of its name, or rather don't just change the language semantics in some places; yes I know it's fixed, still a good example), thereby minimizing those pitfalls.
kuni-toko-tachi 12y ago
Glad the truth is coming out! This will save a lot of developer time and will make SPA's even better.
psp 12y ago
I think digest loop is one of the best parts of AngularJS. I wonder how it ended on this hate list. I dont think I will agree with much of the rest either.
- sanderjd 12y ago
  Out of curiosity - what do you like about the digest loop? I have never thought of it as anything other than a necessary evil in implementation to achieve some high level goals.
serve_yay 12y ago
I've built a couple things with it, and I wouldn't use it again. But it's very popular!
msoad 12y ago
I understand most of it, but digest loop is a great idea! It's much better than manual `model.on('change', view.render)` of backbone for example. Developer might forget to do this manual rendering for certain actions which is bad
- kuni-toko-tachi 12y ago
  Even if you like the digest loop, why do you need the rest of the framework? Why not just use a lightweight alternative that provides that functionality? The digest loop is highly flawed, as the article describes - it is not performant, and requires disabling for many common scenarios. Worse, and I don't see this mentioned, is that the digest loop is not tied to any notion of lifecycle - you can accidentally keep retriggering it until you bomb out after 10 loops.
- orthecreedence 12y ago
  I view it as an icky hack. I much prefer the `model.on(...)` explicit wrapping of model data/eventing in an object. It's a lot more performant and easier to look at and say "that is a model" vs "this is a javascript object, but I don't know if it's being listened to or not." Forgetting to set up your eventing fabric is not a great reason to choose a framework. If you forget to hook up the wires, the view doesn't render properly. This is easily debuggable.
deleted 12y ago
[deleted]
serve_yay 12y ago
Actually, I think an opportunity was missed in the section about dependency injection. The problem of minifying is easy enough to avoid - you just don't use that form. (I do agree that the tutorials shouldn't be teaching the dangerous form, and the dangerous form shouldn't even be a thing.) No, what I hate about Angular's DI is that it tries to make inferences about the name you give it, instead of the name being an unambiguous identifier. It does this for "convenience" but it just ends up causing problems and making incorrect guesses. I'm talking about how, for example, if you have a class called WobbleController, you don't inject 'WobbleController', you inject 'Wobble' and Angular just "figures out" the 'Controller' part. Pretty sweet when it works! Wow, you don't have to type 10 characters! (Good luck grepping for it later, though.) But when it makes a wrong guess it seems impossible to fix. The other thing that sucks about this is that you have to reload your app to see if Angular will actually be able to find the thing you're injecting. This whole thing is supposed to save time, and it just doesn't. It sucks.
- andybak 12y ago
  > The problem of minifying is easy enough to avoid Yes - use a minifier that doesn't break Angular code. Asking me to insert repetitive verbiage isn't an acceptable solution.
  - serve_yay 12y ago
    Sure, whatever, I just don't think it's the real issue with DI in Angular.
    - jaunkst 12y ago
      I am torn about how minification affects metaprogramming. I don't believe that reducing the delivery footprint should ever effect how the code is interpreted.
      - btown 12y ago
        On the other hand, if you think of access to argument names as part of the Javascript language, then a "minifier" that threw out that information would by definition not be a Javascript minifier - it would be a minifier of a subset of the language.
leeber 12y ago
Here's why I like angular... It only took me a couple days of fooling around with it before I built something useful with it. The steep learning curve is only if you want to know the how-and-why behind every feature of the framework (which I still am not even close to). Learning 100% of the framework is simply not necessary for certain apps. It's easy in my opinion, it's quick, and it gets the job done. If I run into any problems, there about a bazillion stack overflow post addressing my issue already.
- darkmagnus 12y ago
  you sound practical...gasp!!! ;)
  - serve_yay 12y ago
    Think so? To me it sounds like the sort of person who leaves messes to get cleaned up by others. No need to learn the tools you're using, just shove shit out the door and let someone else worry about it!
- pluma 12y ago
  Here's why I dislike angular: I was in the same place as you, then I hit something outside the intended use cases and now it's all a huge pain.
- mcv 12y ago
  This is absolutely true. When you start out, and have gotten the hang of the main concepts, it's easy, beautiful and a joy to work with. But eventually you will run into more complex use cases, and the beautiful abstractions of Angular will fall apart. And the problems I run into often only have unanswered questions on Stackoverflow.
likeclockwork 12y ago
There is so much in this article that is disingenuous. For example point #4 complains that Angular redefines Constructor to mean something else. The controller constructor IS a constructor, it constructs an instance of a controller and can request and decorate(or construct) a new scope by injecting $scope. But the debate aside... the quoted revision is over a year old! (It also hasn't reflected the behaviour of the controller constructor for even longer than that, but that's a separate matter.)
hugotox 12y ago
haters gonna hate
nyir 12y ago
The article didn't mention my favourite (ha) pet peeve with Angular, error handling, which makes me wonder about if everyone else doesn't have that problem: even after working with the framework for a couple of months now, I still run, about every other week, into the issue that if something doesn't work, there is exactly zero indication of that. Most prominently misspelled names and parameters of directives. You're lucky if you get an error in the Javascript console, if you happen to have that open all the time. To me that's infuriating. I get that Javascript isn't Haskell (and I don't even want to go that far into that direction), but the combination of extreme leniency and the remarkable absence of checks is really bad.
- baudehlo 12y ago
  Yeah I find it very odd that ng-click="some_function()" doesn't throw up any kind of error if that function isn't defined on the scope (even when you click). Very very frustrating (though maybe I'm missing some setting?).
- serve_yay 12y ago
  That is a huge reason why I like to do as little "programming" as possible in templates. When something goes wrong, you either don't hear about it or if you do hear about it, you don't get a stack trace and so forth. Or, you can't find out where in the template the problem is, and instead get a stack trace full of internals of your templating library/framework.
- wmil 12y ago
  I can see why they did that. Null/undefined checks in templates are messy and ugly, and there are a lot of cases where objects on the scope won't be ready when the scoped element is first rendered. Templates shouldn't be throwing exceptions for something like customer.name when customer is null. Angular's rendering tries to do something sane by default in a very common case. If it really bothers you, you can easily write your own click-log-error directive that writes to the console if the function isn't defined. Actually thanks to Angular's DI system you can replace the base ng-click with one that does throw an error.
  - 12y ago
bsaul 12y ago
i've written a fairly large angular app, and the ng-if case struck me as totally incomprehensible (why the hell would ng-if have its own scope ?). Then i realized i've never had to use ng-if. That's not to minimize the trouble you get when you first have to learn about scope inheritance, but I think ng-if may be the only completely non-intuitive directive of the framework. (As opposed to something like let's say ng-repeat, where you sort of get the intuition that some care will be needed).
- wmil 12y ago
  I don't think that's even a scope issue... ng-model will auto-create scope variables if they don't exist. That's a handy shortcut. But if you have two inputs that can auto-create variable you're asking for trouble, and you should probably initialize it on the scope constructor. Or at the very least, use an ng-init so that you know where it will be created.
iamleppert 12y ago
Angular is awful. I took one look at the docs way back when we were evaluating at BigCo and walked away.
pgsuckz 12y ago
TL;DR: AngularJS is a horrible framework because it can be abused by newbies and is too "complicated" plus some other non-issues.
- smt88 12y ago
  "Too complicated" is a huge issue in the real world. It makes code hard to maintain, hard to pass off to others, and hard to reason about. That's the main issue with Angular: it's hard to reason about the code, and it frequently violates the principle of least astonishment.
dscrd 12y ago
> Whatever the reason is for Angulars popularity, it isn’t that it’s a great framework. Something similar to this seems to be true for every piece of programming technology that is popular. How did it come to this? Other professions don't go in masses towards the worst solutions, do they?
- wmil 12y ago
  "There are only two kinds of languages: the ones people complain about and the ones nobody uses." -Bjarne Stroustrup Every piece of tech involves design tradeoffs. Most software benefits from network effects -- there are advantages to using what everyone else is using. Because of that people inevitably end up using software with design decisions they disagree with. It's worse in programming because their are fewer hard design limits. Everything comes down to preference.
- vec 12y ago
  The things that beginners want are often diametrically opposed to the things experts want, and since everyone is by definition a beginner before they are an expert then they will tend to gravitate toward solutions that are beginner friendly (and therefore expert hostile).
- TheOtherHobbes 12y ago
  Not unless you count politics, law, finance, and economics.
jmstout 12y ago
I first tried to view this article on my mobile device and saw this: https://dl.dropboxusercontent.com/u/117695213/static/larseidnes.jpg https://dl.dropboxusercontent.com/u/117695213/static/larseid... To me, this is already revealing. A critique of a web framework and this is the first impression I get? Not off to a good start. There’s a reason people find it hard to trust a fat nutritionist. I see parallels here. Lately there has been a lot of negative feedback about AngularJS and I have been interested in the critiques of its shortcomings. For this reason, I gave him the benefit of the doubt, pulled up the article on my computer, and dug in. His initial complaint about prototypically inherited scope properties (Bad Idea #1) being confusing and "literally impossible" to predict was perplexing to me. He states that he understands a child scope will inherit from its parent scope, yet doesn't explicitly instantiate any object on the parent controller in his example of the so-called problem ( http://jsfiddle.net/1op3L9yo/ http://jsfiddle.net/1op3L9yo/ ). A child of a parent with no properties inherits nothing from its parent -- this seems obvious. If properties are actually defined on the parent the child will inherit them. Is this not the expected behavior? The "fix" for his "impossible" scenario, is to make sure you explicitly define the property on the parent. In his specific example, that would look like this: $scope.obj = { prop: '' }; ( http://jsfiddle.net/355fuxk5/ http://jsfiddle.net/355fuxk5/ ) He complains: "Whether or not a new scope is introduced by a directive is up to its implementer. And if a new scope is introduced, it is up to its implementer to decide if it inherits from its parent scope or not." How is this a bad idea? I like choices in life, don't you? He talks about dynamic scoping being a terrible thing. I think the alternative, dictating One True Way of doing things, removes flexibility. This would be far worse than the current status quo of leaving it up to the developer. He advocates for removing this choice altogether, but is there NEVER a good use case for this "dynamic scoping"? He also complains about the digest loop -- how two-way bindings constantly check for changes and impact performance as your number of bindings grow. There is truth to this, but it is easy to write your own directives that only update UI elements when a change occurs. This can easily be achieved in a variety of different ways. (The most universally familiar of which being a simple callback paradigm.) Building a quality application with angular requires you to think, but I would argue that designing a performant application with ANY framework demands the same thing. You might initially think you get some things for free, but everything has its costs. If you want things to happen automagically, without needing to be explicit about the needs of your specific use case, that'll cost you. Is this not a near universal truth in programming? People fault the framework when, instead, they should be faulting themselves: their own laziness or lack of clarity. He talks about having a page listing where their UI already had 2000 bindings and how clicking a "load more" button added another 1000 bindings, killing performance. I can't understand why you would possibly have that many bindings... for ANYTHING, unless you're Doing It Wrong. Why would you need any two-way bindings for explicitly appended information? When the user clicks "load more", we know something needs to change. If performance is a concern, why would you ever allow that listing to be automatically updated by checking for changes on every digest cycle? Instead, you can either explicitly update the element when the action is called (no two-way bindings), or use a SINGLE binding for the entire list. 1000 bindings? What could possibly be the justification for that? Bindings can be drastically reduced and performance dramatically improved if you work to optimize your code and move from prototyping with built in ng-* components, to crafting components explicitly for your needs. I truly believe the standard ng-* components are meant more for prototyping and to serve as an example for how you can accomplish similar things as your write your own application specific code. Not being clear about this is perhaps one of angular's biggest failings. Does it really surprise any programmer or developer that in order to achieve high performance in your application, you must architect explicitly for your use case? To put it another way, in order to make a great application, you need to understand what is happening under the hood. If you're using components that you don't fully understand, that end up running a bunch of unnecessary operations, is that the framework's fault, or your own? Is it really the role of the framework to do your development for you? You can either have things happen automagically, or have things be performant, but not both. This is reasonable and beyond logical, I think. He critiques the language used in the documentation to explain controllers and hangs his hat on what he feels is the misuse of the word "constructor". His contention is that this is incorrect because the controller functions are being applied to an existing scope, not being instantiated in the traditional sense. Yet, and he even admits this, he is critiquing documentation that is over a year old. The current docs do a better job of clarifying what's actually happening. How is this a fair critique of a framework? Cherry picking year old documentation... this just seems silly, and as someone else said, disingenuous. Nothing is perfect, especially out of the gate, especially in open source -- I think we all know that. His further complaints in this section employ the same strategy -- he takes segments from the documentation out of context and explains why they don't make sense. He even says that their use of the term "syntactic sugar" to describe the many options for creating components (services, factories, providers) is incorrect because, in his mind, "syntactic sugar" would imply a direct syntax modification to JavaScript or implementation of a custom language parser. Really? Let's see what Wikipedia has to say on the subject: "In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express. It makes the language "sweeter" for human use: things can be expressed more clearly, more concisely, or in an alternative style that some may prefer." (http://en.wikipedia.org/wiki/Syntactic_sugar http://en.wikipedia.org/wiki/Syntactic_sugar) Soooo, for example, angular's service and factory being abstractions over the provider implementation? When you don't need the full power of a provider using these higher level functions makes it more concise, easier to use, and "sweeter"... sounds like syntactic sugar to me, unless we're just being pedantic for the sake of it. He says, "Angular seems to strive to make things as complicated as possible." I would argue that this simply isn't true, is shortsighted, and borderline insulting to the intelligence and efforts of angular's core team. I believe AngularJS is opinionated but it strives to make things as flexible as possible and as a result some inherent complexity exists. In my (almost) 2 years of working with the framework, this is what I’ve found: AngularJS is extremely flexible. Its built in components are great for quick prototyping and its underlying structure provides an excellent FRAMEWORK for creating more purpose built, application specific, code. In my experience, angular is there when you want it to be and quickly gets out of your way when you don't need it. This is a robust framework. It is built for rapid prototyping and creating complex, performant applications (when properly executed). It is not baby's first framework. How many times have we heard the old adage that, with most things in life, you get out what you put in. This is doubly true for angular (and development as a whole, I would speculate). If you're willing to put in the work, AngularJS can be a phenomenal tool in your arsenal. It can also be great for getting a prototype together, but one must understand, that a prototype is just that. Using ng-* components everywhere and expecting everything to work out optimally is just not going to happen. Did you REALLY think it would? To pull a quote from his last paragraph: "... many people like to recommend projects they haven’t used in any depth, because the idea of knowing what the next big thing is feels good. The result is that people choose frameworks largely based on advice from people who don’t know what they’re talking about." The irony here is palpable. Change "recommend" to "criticize" and "knowing" to "condemning" and I almost needn't say more (he says, 8000 words later).
nogridbag 12y ago
When I was evaluating Angular, the near deal breaker for me was that the router could only swap a single view area - which is useless for anything more than a trivial "Hello World" example. To build a real app, I would have to divide it into multiple small Angular apps. Is this still the case with core Angular? I realize there's the third party AngularUI UI Router project. I'm assuming everyone who uses Angular for any real project uses that.
- kuni-toko-tachi 12y ago
  Glad you mentioned this. Not every SPA has a UX that lends itself to nested controllers. The routers and $scope handcuff you. And sibling views in ui-router don't solve the issue either.
mck- 12y ago
Bad Idea #1 : can be prevented easily with `controllerAs` syntax — this is pretty widely accepted to be best-practice, so the approach that he points out should never be used to begin with Bad Idea #2: can be avoided using gulp. If you are minifying, you should be using gulp anyway, so it’s just a matter of adding a plugin to take care of that Bad Idea #3: this is true, and you have to take care of it for large-scale applications to prevent performance breakdowns. Since angular 1.3 there are one-time bindings as well. Bad Idea #4: This sounds like nitpicking from a JS purist Bad Idea #5: I agree that this stuff is unnecessarily complicated so yeah… there are many ways that you can break Angular :p learning curve is definitely steep.. and there are plenty of edge-cases that will bite you. Despite all that, it’s pretty powerful at what it does, once you get around it…
btown 12y ago
A lot of people complain about Angular's digest cycle and hold up React as the way forward. My understanding, and I could be wrong, is that both frameworks do work for every "binding" to the data in every update cycle - for React, you need to create short-lived objects for a component and its children AND evaluate every dependency on external objects, whereas for Angular it's a few function wrappers and iterations on top of evaluating every dependency on external objects. Seems like modern JS JITs should optimize both of these cases so it's just the evaluations. And both frameworks have facilities for limiting the scope at which the update cycle needs to run. Am I wrong in saying, then, that React isn't inherently more performant?
- lobster_johnson 12y ago
  As I understand Angular, objects are mutable, and Angular must perform deep dirty checks on every object to be perfectly consistent. As pointed out by the author of the blog post, this needs to be repeated until there are no more changes detected. That's the whole point of Angular's digest loop. React's data model is much simpler, at least at a high level. State changes are explicit, and data is immutable. This means that whenever you give a component new props, it can simply do a deep comparison of the data with the previous version and mark the component as dirty if it's changed. (Setting a new state always triggers a re-render, no matter if the data is different or not.) Since data changes only happen explicitly, and flow naturally through component nesting, it doesn't need process a lot of data to figure out what needs to be updated. The list of dirty components is then processed to produce the virtual DOM, which is then diffed against the real DOM. Doing anything with the real DOM is expensive, whereas the virtual DOM is extremely fast. So is building the virtual DOM; while it's true that a component's render() method needs to build its own tree every time it's called, re-rendering is extremely fast, even if you actually change state near the root of the virtual DOM (which causes a bigger cascade of dirty checks). Current JS engines are capable of creating tens of thousands of objects in just a few milliseconds. (There are a few of optimization tricks you can use to avoid renders, too. In particular, there is PureRenderMixin, which declares that your component is "pure", meaning that given the same props and state, it will always render the same tree, allowing React to do shallower checks to determine if a render is needed.)
lobster_johnson 12y ago
Coincidentally, the scoping issue is almost exactly the same issue that plagued Zope, a Python-based app server, back in the day. In Zope, any property could be inherited not just from the parent object, but from the current context; you could invoke the object path "a.b" and b would inherit from b, but if you invoked the object path "a.c.b", b would inherit from c instead. They called this design pattern "acquisition", and seemed rather proud of it until they realized it was the kind of magic that was ultimately too magical for its own good. The Zope guys tried very hard to eradicate it, and in the process ended up alienating all the developers with the new, non-backwards-compatible version. Funnily enough, there is another Angular parallel to Zope: Just like Zope 3, AngularJS 2.0 is also not backwards-compatible. Angular's parameter-based dependency injection is coincidentally the same reason Martini [1] is slower than most other Golang web frameworks. Clever, sure, but ultimately a design flaw. These problems demonstrate how important it is to introduce a good design from the very beginning. You can fix bad code, but bad design is much harder to change. [1] https://github.com/go-martini/martini#service-injection https://github.com/go-martini/martini#service-injection
- chumpalump 12y ago
  You nailed it, Sir. This "zopeness" is exactly what kept me from adopting AngularJs.
mcv 12y ago
I loved Angular. And I still love many parts of it. I like the declarative style, the automatic data binding, and all that other stuff that's painful in JQuery, but fairly painless in Angular. Well, painless at first. Because eventually you run into the limitations. The data binding doesn't scale, a lot of things that are easy to declare (particularly scope variables for directives) are a lot more complex than they initially seem. The article hasn't even scratched the surface on problems with scope in Angular. And then there's the fact that my templates keep turning everything into strings. Too often, when binding stuff from an outside controller to the isolate scope of a directive, I keep having explicitly to turn all the strings back into numbers. Still, Angular does a lot of very neat stuff. There are just too many common use cases that the neat stuff doesn't really cover very well.

226 points by lars 12y ago

Our team chose to use angular admittedly because of its popularity (it's also why we chose bootstrap over foundation, though that probably had smaller repercussions). Most of the rest of the team then ran off to work on other stuff, so I ended up with most of the angular work. It's been at least 8 months now, and I've gotta say the article is pretty spot on. But I don't really mind anymore for two reasons: I know most of the gotchas now (probably after some loss/whitening of hair), and I haven't used any of the other major frameworks (like ember) to really be able to make an informed comparison. I don't know if there's a real takeaway here. Maybe "evaluate major contenders even if one is super popular" or "be more vocal when someone tries to blindly railroad in a candidate"?

serve_yay 12y ago
That happened to me at my last job too. There was no real, actual discussion about what we would use, the party line was "Angular looks like the future of web development" (this claim came from people who spend all their time in C#, not front-end devs).

EugeneOZ 12y ago

that's why 2.0 is complete rewrite - exactly to eliminate all these bad parts.

DonHopkins 12y ago
And to make up for it, they threw in some even worse parts. Like breaking the syntax of HTML with their templates, making it impossible to edit, validate, transform, generate or consume templates with any of the thousands of existing HTML and XML processing tools. That, in my opinion, was one of the most terrible ideas I've ever heard come out of the Angular community. And even worse, they refuse to acknowledge that it's a bad idea. That's a very bad sign indeed.
- EugeneOZ 12y ago
  They moved away from that idea: https://github.com/angular/angular/issues/133 https://github.com/angular/angular/issues/133
lukifer 12y ago
Can you specify some of the forthcoming improvements? I want to like Angular, but every time I've actually used it has been a practical and conceptual headache. (Also, the idea that they're creating a new compile-to-JS language seems strange and unnecessary.)
- ddoolin 12y ago
  A decent overview: http://www.infoq.com/news/2014/10/angular-2-atscript http://www.infoq.com/news/2014/10/angular-2-atscript The kicker is elimination of these concepts: Controllers, Directive Definition Object, $scope, angular.module, and jqLite
  - michaelchisari 12y ago
    The addition of a whole new scripting language seems... overly complicated.
    - paulhodge 12y ago
      It's TypeScript with the addition of a few key features that are helpful for Angular's design. Technically, Angular 1.0 also had its own scripting language too. It's kind of inevitable, since Javascript itself is one of the obstacles to making a better web framework.
      - emilis_info 12y ago
        I think it is more Dart... At least the AtScript specification mentions Dart more often than any other language.
    - kuni-toko-tachi 12y ago
      It's utterly insane. Just as in AngularJS 1.3 they have invented there own expression language which floats around in HTML attributes, thereby eliminating the use of Javascript itself and all it's functional goodness. And worst, the user has to incur the cost of downloading this needless code for the expression language to bootstrap the framework.
andybak 12y ago
Does it eliminate 2-way data binding? It's the realisation that this is a fundamentally bad idea that was the real kicker for me. The more you try to write clearly structured, maintainable Angular, the more it begins to resemble React.
- doczoidberg 12y ago
  Angular 1.3 already has one way binding: http://blog.thoughtram.io/angularjs/2014/10/14/exploring-angular-1.3-one-time-bindings.html http://blog.thoughtram.io/angularjs/2014/10/14/exploring-ang...
- EugeneOZ 12y ago
  default binding planned to be one-way.
smacktoward 12y ago
Because "let's rewrite it all from scratch!" always ends well.

xfalcox 12y ago

I can't get the script who counts the bindings to run. Any help? Uncaught TypeError: Cannot read property '$$nextSibling' of undefined

lars 12y ago
Maybe you're not using ng-app? In that case, document.querySelectorAll("[ng-app]") wont return any elements, and it wont find the root scope. Replacing "[ng-app]" with a selector that finds your root element should work I think.
- xfalcox 12y ago
  I'm using the deferred bootstrap indeed. Changed to body and now the script works, thanks! By the way, very nice article, and after working with some real time angular apps, the thing that haunt me the most is the number os binds. People just want more information, and it can hard to explain that we have a limit.
grumblestumble 12y ago
I use https://gist.githubusercontent.com/DTFagus/3966db108a578f2eb00d/raw/b1cfa662f8b777dbe07fec51d49d3fc5d3d9cb87/analyse_watchers.js https://gist.githubusercontent.com/DTFagus/3966db108a578f2eb...

hcho 12y ago

The dependency injection thing is really a non issue. Just use something like ng-min before you minify and you are set. Just for the price of another entry in your grunt.js file.

DrJokepu 12y ago
He talked about ng-min and why he thinks it's a bad idea.
- grumblestumble 12y ago
  And his reasoning around that was inanity disguised with high concept. He already advocates for a build process to minify code, ng-annotate simply expands the condensed DI syntax to the array notation.
  - saidajigumi 12y ago
    > And his reasoning around that was inanity disguised with high concept. To elaborate: invoking the argument "you reduce to the Halting Problem, suxxor!" without some concrete examples of how the practical problem (i.e. ng-min implementation) encounters difficulties is disingenuous. It's not uncommon to be able to cover some very useful space of a real-world problem, skirting "inside" a problem which is theoretically limited by the Halting Problem or similar. Occasionally you hit a limitation in your algorithm and add a special case, further claiming practical territory from The NP-Complete Beast. In this case, the strict di enforcement that baconner mentioned in this thread provides an escape hatch: if you're using ng-min while having di enforcement enabled, you'll at least get warned if something goes amiss. If so, add your manual DI annotations, maybe file an ng-min bug, and move along.
baconner 12y ago
There's also a new strict di enforcement option that'll make angular error if you don't have the min friendly di syntax in use. That's the best way imo and probably what angular should've always done.
12y ago

grannyg00se 12y ago

The scoping should be made more explicitly against a particular controller. The issue is resolved simply by using controller as syntax which is recommended in many blogs. Point taken about the pit of dispair though. http://jsfiddle.net/sndyxfdk/1/ http://jsfiddle.net/sndyxfdk/1/

saosebastiao 12y ago

I'm pretty new to front end development, and a few months ago I started learning Javascript by experimenting with a few front end frameworks. When I got to Angular, I dropped it the moment I saw string-based expressions. How is that even remotely acceptable? I can't even imagine the bugs I would be embedding everywhere.

hawkice 12y ago
So, on one hand, yes. As a clojurian, I feel as if I should add an additional level of condemnation (the whole syntax of my favorite language is good old-fashion data structures, as is almost every construct within the language). That being said, it's frontend stuff. The turnaround times are so small that those kinds of bugs are pretty hard to ignore, and very easy to find. Note: I have used Angular, but don't use it anymore, for other reasons.
- rohamg 12y ago
  What are your reasons?
  - hawkice 12y ago
    Their model for dom composition is substantially more complex than I would prefer. Angular, at it's core, is something like a re-imagining of the dom + js-event-loop that is hackable and modifiable. Good goal, but the complexity doesn't buy you much over e.g. reagent or meteor, which are _much_ simpler.
general_failure 12y ago
And your suggested alternative is?
- DonHopkins 12y ago
  You ask that as if not suggesting an alternative to Angular invalidates suggesting avoiding Angular like the plague. There are MANY viable alternatives. No one solution fits all, but some solutions, like Angular, fundamentally suck at everything, because they're terribly designed, and their developers refuse to acknowledge or correct that fact. In order to answer your off-topic question, which is outside the scope of this article, you'll have to explain in detail all about what your actual requirements and experience and expectations are, and for that you should expect to pay a reasonable hourly rate for an experienced developer to listen to you and give you advice. If that's what you really want, then good luck finding someone to help you with your problems choosing a decent web framework, but at least you now know that Angular simply doesn't qualify. But if you're just trying to imply that it's not right to criticize Angular without evangelizing an alternative, you're wrong.

wnevets 12y ago

This article the bad parts: all of it.

RussianCow 12y ago
Could you be more specific about what you don't like about it?
- wnevets 12y ago
  Extremely derivative and already talked to death here on HN. There is virtually nothing original in this article.
  - mistermumble 12y ago
    This is the first time I have read some of these criticisms of Angular on HN. Can you point to threads where there was discussion of these issues? Would like to get more info on these. Thanks.
    - tim333 12y ago
      There's some stuff here https://news.ycombinator.com/item?id=8507632 https://news.ycombinator.com/item?id=8507632 and here https://news.ycombinator.com/item?id=8527230 https://news.ycombinator.com/item?id=8527230
  - DonHopkins 12y ago
    Please give us links to all the articles criticizing Angular that you think make this article redundant?
    - wnevets 12y ago
      lmgtfy https://hn.algolia.com/#!/story/forever/0/angularjs https://hn.algolia.com/#!/story/forever/0/angularjs
  - talmand 12y ago

nawitus 12y ago

Just today I lost half an hour figuring out why my ng-show worked for all other strings except for "f" and "F". AngularJS definitely has it's own traps..

Guillaume86 12y ago
What is the trick? I usually use "!!variable" to ensure boolean conversion so I guess I would have been fine?
- nawitus 12y ago
  Yeah, "!!variable" works, and in my case I used ".length > 0". Boolean(variable) works too. It's just unfortunate when you're assuming that the expression or typecasting works like in JavaScript, and then AngularJS had to invent these unnecessary rules that make no sense. JavaScript's type coercion is tricky enough, you don't need to make it worse.
EugeneOZ 12y ago
Any tool has.
- nyir 12y ago
  But it would be good if the obvious way to do something didn't have certain magic conditions in which reasonable expectations aren't met (e.g. a variable is evaluated to its value, regardless of its name, or rather don't just change the language semantics in some places; yes I know it's fixed, still a good example), thereby minimizing those pitfalls.

kuni-toko-tachi 12y ago

Glad the truth is coming out! This will save a lot of developer time and will make SPA's even better.

psp 12y ago

I think digest loop is one of the best parts of AngularJS. I wonder how it ended on this hate list. I dont think I will agree with much of the rest either.

sanderjd 12y ago
Out of curiosity - what do you like about the digest loop? I have never thought of it as anything other than a necessary evil in implementation to achieve some high level goals.

serve_yay 12y ago

I've built a couple things with it, and I wouldn't use it again. But it's very popular!

msoad 12y ago

I understand most of it, but digest loop is a great idea! It's much better than manual `model.on('change', view.render)` of backbone for example. Developer might forget to do this manual rendering for certain actions which is bad

kuni-toko-tachi 12y ago
Even if you like the digest loop, why do you need the rest of the framework? Why not just use a lightweight alternative that provides that functionality? The digest loop is highly flawed, as the article describes - it is not performant, and requires disabling for many common scenarios. Worse, and I don't see this mentioned, is that the digest loop is not tied to any notion of lifecycle - you can accidentally keep retriggering it until you bomb out after 10 loops.
orthecreedence 12y ago
I view it as an icky hack. I much prefer the `model.on(...)` explicit wrapping of model data/eventing in an object. It's a lot more performant and easier to look at and say "that is a model" vs "this is a javascript object, but I don't know if it's being listened to or not." Forgetting to set up your eventing fabric is not a great reason to choose a framework. If you forget to hook up the wires, the view doesn't render properly. This is easily debuggable.

deleted 12y ago

[deleted]

serve_yay 12y ago

Actually, I think an opportunity was missed in the section about dependency injection. The problem of minifying is easy enough to avoid - you just don't use that form. (I do agree that the tutorials shouldn't be teaching the dangerous form, and the dangerous form shouldn't even be a thing.) No, what I hate about Angular's DI is that it tries to make inferences about the name you give it, instead of the name being an unambiguous identifier. It does this for "convenience" but it just ends up causing problems and making incorrect guesses. I'm talking about how, for example, if you have a class called WobbleController, you don't inject 'WobbleController', you inject 'Wobble' and Angular just "figures out" the 'Controller' part. Pretty sweet when it works! Wow, you don't have to type 10 characters! (Good luck grepping for it later, though.) But when it makes a wrong guess it seems impossible to fix. The other thing that sucks about this is that you have to reload your app to see if Angular will actually be able to find the thing you're injecting. This whole thing is supposed to save time, and it just doesn't. It sucks.

andybak 12y ago
> The problem of minifying is easy enough to avoid Yes - use a minifier that doesn't break Angular code. Asking me to insert repetitive verbiage isn't an acceptable solution.
- serve_yay 12y ago
  Sure, whatever, I just don't think it's the real issue with DI in Angular.
  - jaunkst 12y ago
    I am torn about how minification affects metaprogramming. I don't believe that reducing the delivery footprint should ever effect how the code is interpreted.
    - btown 12y ago
      On the other hand, if you think of access to argument names as part of the Javascript language, then a "minifier" that threw out that information would by definition not be a Javascript minifier - it would be a minifier of a subset of the language.

leeber 12y ago

Here's why I like angular... It only took me a couple days of fooling around with it before I built something useful with it. The steep learning curve is only if you want to know the how-and-why behind every feature of the framework (which I still am not even close to). Learning 100% of the framework is simply not necessary for certain apps. It's easy in my opinion, it's quick, and it gets the job done. If I run into any problems, there about a bazillion stack overflow post addressing my issue already.

darkmagnus 12y ago
you sound practical...gasp!!! ;)
- serve_yay 12y ago
  Think so? To me it sounds like the sort of person who leaves messes to get cleaned up by others. No need to learn the tools you're using, just shove shit out the door and let someone else worry about it!
pluma 12y ago
Here's why I dislike angular: I was in the same place as you, then I hit something outside the intended use cases and now it's all a huge pain.
mcv 12y ago
This is absolutely true. When you start out, and have gotten the hang of the main concepts, it's easy, beautiful and a joy to work with. But eventually you will run into more complex use cases, and the beautiful abstractions of Angular will fall apart. And the problems I run into often only have unanswered questions on Stackoverflow.

likeclockwork 12y ago

There is so much in this article that is disingenuous. For example point #4 complains that Angular redefines Constructor to mean something else. The controller constructor IS a constructor, it constructs an instance of a controller and can request and decorate(or construct) a new scope by injecting $scope. But the debate aside... the quoted revision is over a year old! (It also hasn't reflected the behaviour of the controller constructor for even longer than that, but that's a separate matter.)

hugotox 12y ago

haters gonna hate

nyir 12y ago

The article didn't mention my favourite (ha) pet peeve with Angular, error handling, which makes me wonder about if everyone else doesn't have that problem: even after working with the framework for a couple of months now, I still run, about every other week, into the issue that if something doesn't work, there is exactly zero indication of that. Most prominently misspelled names and parameters of directives. You're lucky if you get an error in the Javascript console, if you happen to have that open all the time. To me that's infuriating. I get that Javascript isn't Haskell (and I don't even want to go that far into that direction), but the combination of extreme leniency and the remarkable absence of checks is really bad.

baudehlo 12y ago
Yeah I find it very odd that ng-click="some_function()" doesn't throw up any kind of error if that function isn't defined on the scope (even when you click). Very very frustrating (though maybe I'm missing some setting?).
serve_yay 12y ago
That is a huge reason why I like to do as little "programming" as possible in templates. When something goes wrong, you either don't hear about it or if you do hear about it, you don't get a stack trace and so forth. Or, you can't find out where in the template the problem is, and instead get a stack trace full of internals of your templating library/framework.
wmil 12y ago
I can see why they did that. Null/undefined checks in templates are messy and ugly, and there are a lot of cases where objects on the scope won't be ready when the scoped element is first rendered. Templates shouldn't be throwing exceptions for something like customer.name when customer is null. Angular's rendering tries to do something sane by default in a very common case. If it really bothers you, you can easily write your own click-log-error directive that writes to the console if the function isn't defined. Actually thanks to Angular's DI system you can replace the base ng-click with one that does throw an error.
- 12y ago

bsaul 12y ago

i've written a fairly large angular app, and the ng-if case struck me as totally incomprehensible (why the hell would ng-if have its own scope ?). Then i realized i've never had to use ng-if. That's not to minimize the trouble you get when you first have to learn about scope inheritance, but I think ng-if may be the only completely non-intuitive directive of the framework. (As opposed to something like let's say ng-repeat, where you sort of get the intuition that some care will be needed).

wmil 12y ago
I don't think that's even a scope issue... ng-model will auto-create scope variables if they don't exist. That's a handy shortcut. But if you have two inputs that can auto-create variable you're asking for trouble, and you should probably initialize it on the scope constructor. Or at the very least, use an ng-init so that you know where it will be created.

iamleppert 12y ago

Angular is awful. I took one look at the docs way back when we were evaluating at BigCo and walked away.

pgsuckz 12y ago

TL;DR: AngularJS is a horrible framework because it can be abused by newbies and is too "complicated" plus some other non-issues.

smt88 12y ago
"Too complicated" is a huge issue in the real world. It makes code hard to maintain, hard to pass off to others, and hard to reason about. That's the main issue with Angular: it's hard to reason about the code, and it frequently violates the principle of least astonishment.

dscrd 12y ago

> Whatever the reason is for Angulars popularity, it isn’t that it’s a great framework. Something similar to this seems to be true for every piece of programming technology that is popular. How did it come to this? Other professions don't go in masses towards the worst solutions, do they?

wmil 12y ago
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." -Bjarne Stroustrup Every piece of tech involves design tradeoffs. Most software benefits from network effects -- there are advantages to using what everyone else is using. Because of that people inevitably end up using software with design decisions they disagree with. It's worse in programming because their are fewer hard design limits. Everything comes down to preference.
vec 12y ago
The things that beginners want are often diametrically opposed to the things experts want, and since everyone is by definition a beginner before they are an expert then they will tend to gravitate toward solutions that are beginner friendly (and therefore expert hostile).
TheOtherHobbes 12y ago
Not unless you count politics, law, finance, and economics.

jmstout 12y ago

I first tried to view this article on my mobile device and saw this: https://dl.dropboxusercontent.com/u/117695213/static/larseidnes.jpg https://dl.dropboxusercontent.com/u/117695213/static/larseid... To me, this is already revealing. A critique of a web framework and this is the first impression I get? Not off to a good start. There’s a reason people find it hard to trust a fat nutritionist. I see parallels here. Lately there has been a lot of negative feedback about AngularJS and I have been interested in the critiques of its shortcomings. For this reason, I gave him the benefit of the doubt, pulled up the article on my computer, and dug in. His initial complaint about prototypically inherited scope properties (Bad Idea #1) being confusing and "literally impossible" to predict was perplexing to me. He states that he understands a child scope will inherit from its parent scope, yet doesn't explicitly instantiate any object on the parent controller in his example of the so-called problem ( http://jsfiddle.net/1op3L9yo/ http://jsfiddle.net/1op3L9yo/ ). A child of a parent with no properties inherits nothing from its parent -- this seems obvious. If properties are actually defined on the parent the child will inherit them. Is this not the expected behavior? The "fix" for his "impossible" scenario, is to make sure you explicitly define the property on the parent. In his specific example, that would look like this: $scope.obj = { prop: '' }; ( http://jsfiddle.net/355fuxk5/ http://jsfiddle.net/355fuxk5/ ) He complains: "Whether or not a new scope is introduced by a directive is up to its implementer. And if a new scope is introduced, it is up to its implementer to decide if it inherits from its parent scope or not." How is this a bad idea? I like choices in life, don't you? He talks about dynamic scoping being a terrible thing. I think the alternative, dictating One True Way of doing things, removes flexibility. This would be far worse than the current status quo of leaving it up to the developer. He advocates for removing this choice altogether, but is there NEVER a good use case for this "dynamic scoping"? He also complains about the digest loop -- how two-way bindings constantly check for changes and impact performance as your number of bindings grow. There is truth to this, but it is easy to write your own directives that only update UI elements when a change occurs. This can easily be achieved in a variety of different ways. (The most universally familiar of which being a simple callback paradigm.) Building a quality application with angular requires you to think, but I would argue that designing a performant application with ANY framework demands the same thing. You might initially think you get some things for free, but everything has its costs. If you want things to happen automagically, without needing to be explicit about the needs of your specific use case, that'll cost you. Is this not a near universal truth in programming? People fault the framework when, instead, they should be faulting themselves: their own laziness or lack of clarity. He talks about having a page listing where their UI already had 2000 bindings and how clicking a "load more" button added another 1000 bindings, killing performance. I can't understand why you would possibly have that many bindings... for ANYTHING, unless you're Doing It Wrong. Why would you need any two-way bindings for explicitly appended information? When the user clicks "load more", we know something needs to change. If performance is a concern, why would you ever allow that listing to be automatically updated by checking for changes on every digest cycle? Instead, you can either explicitly update the element when the action is called (no two-way bindings), or use a SINGLE binding for the entire list. 1000 bindings? What could possibly be the justification for that? Bindings can be drastically reduced and performance dramatically improved if you work to optimize your code and move from prototyping with built in ng-* components, to crafting components explicitly for your needs. I truly believe the standard ng-* components are meant more for prototyping and to serve as an example for how you can accomplish similar things as your write your own application specific code. Not being clear about this is perhaps one of angular's biggest failings. Does it really surprise any programmer or developer that in order to achieve high performance in your application, you must architect explicitly for your use case? To put it another way, in order to make a great application, you need to understand what is happening under the hood. If you're using components that you don't fully understand, that end up running a bunch of unnecessary operations, is that the framework's fault, or your own? Is it really the role of the framework to do your development for you? You can either have things happen automagically, or have things be performant, but not both. This is reasonable and beyond logical, I think. He critiques the language used in the documentation to explain controllers and hangs his hat on what he feels is the misuse of the word "constructor". His contention is that this is incorrect because the controller functions are being applied to an existing scope, not being instantiated in the traditional sense. Yet, and he even admits this, he is critiquing documentation that is over a year old. The current docs do a better job of clarifying what's actually happening. How is this a fair critique of a framework? Cherry picking year old documentation... this just seems silly, and as someone else said, disingenuous. Nothing is perfect, especially out of the gate, especially in open source -- I think we all know that. His further complaints in this section employ the same strategy -- he takes segments from the documentation out of context and explains why they don't make sense. He even says that their use of the term "syntactic sugar" to describe the many options for creating components (services, factories, providers) is incorrect because, in his mind, "syntactic sugar" would imply a direct syntax modification to JavaScript or implementation of a custom language parser. Really? Let's see what Wikipedia has to say on the subject: "In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express. It makes the language "sweeter" for human use: things can be expressed more clearly, more concisely, or in an alternative style that some may prefer." (http://en.wikipedia.org/wiki/Syntactic_sugar http://en.wikipedia.org/wiki/Syntactic_sugar) Soooo, for example, angular's service and factory being abstractions over the provider implementation? When you don't need the full power of a provider using these higher level functions makes it more concise, easier to use, and "sweeter"... sounds like syntactic sugar to me, unless we're just being pedantic for the sake of it. He says, "Angular seems to strive to make things as complicated as possible." I would argue that this simply isn't true, is shortsighted, and borderline insulting to the intelligence and efforts of angular's core team. I believe AngularJS is opinionated but it strives to make things as flexible as possible and as a result some inherent complexity exists. In my (almost) 2 years of working with the framework, this is what I’ve found: AngularJS is extremely flexible. Its built in components are great for quick prototyping and its underlying structure provides an excellent FRAMEWORK for creating more purpose built, application specific, code. In my experience, angular is there when you want it to be and quickly gets out of your way when you don't need it. This is a robust framework. It is built for rapid prototyping and creating complex, performant applications (when properly executed). It is not baby's first framework. How many times have we heard the old adage that, with most things in life, you get out what you put in. This is doubly true for angular (and development as a whole, I would speculate). If you're willing to put in the work, AngularJS can be a phenomenal tool in your arsenal. It can also be great for getting a prototype together, but one must understand, that a prototype is just that. Using ng-* components everywhere and expecting everything to work out optimally is just not going to happen. Did you REALLY think it would? To pull a quote from his last paragraph: "... many people like to recommend projects they haven’t used in any depth, because the idea of knowing what the next big thing is feels good. The result is that people choose frameworks largely based on advice from people who don’t know what they’re talking about." The irony here is palpable. Change "recommend" to "criticize" and "knowing" to "condemning" and I almost needn't say more (he says, 8000 words later).

nogridbag 12y ago

When I was evaluating Angular, the near deal breaker for me was that the router could only swap a single view area - which is useless for anything more than a trivial "Hello World" example. To build a real app, I would have to divide it into multiple small Angular apps. Is this still the case with core Angular? I realize there's the third party AngularUI UI Router project. I'm assuming everyone who uses Angular for any real project uses that.

kuni-toko-tachi 12y ago
Glad you mentioned this. Not every SPA has a UX that lends itself to nested controllers. The routers and $scope handcuff you. And sibling views in ui-router don't solve the issue either.

mck- 12y ago

Bad Idea #1 : can be prevented easily with `controllerAs` syntax — this is pretty widely accepted to be best-practice, so the approach that he points out should never be used to begin with Bad Idea #2: can be avoided using gulp. If you are minifying, you should be using gulp anyway, so it’s just a matter of adding a plugin to take care of that Bad Idea #3: this is true, and you have to take care of it for large-scale applications to prevent performance breakdowns. Since angular 1.3 there are one-time bindings as well. Bad Idea #4: This sounds like nitpicking from a JS purist Bad Idea #5: I agree that this stuff is unnecessarily complicated so yeah… there are many ways that you can break Angular :p learning curve is definitely steep.. and there are plenty of edge-cases that will bite you. Despite all that, it’s pretty powerful at what it does, once you get around it…

btown 12y ago

A lot of people complain about Angular's digest cycle and hold up React as the way forward. My understanding, and I could be wrong, is that both frameworks do work for every "binding" to the data in every update cycle - for React, you need to create short-lived objects for a component and its children AND evaluate every dependency on external objects, whereas for Angular it's a few function wrappers and iterations on top of evaluating every dependency on external objects. Seems like modern JS JITs should optimize both of these cases so it's just the evaluations. And both frameworks have facilities for limiting the scope at which the update cycle needs to run. Am I wrong in saying, then, that React isn't inherently more performant?

lobster_johnson 12y ago
As I understand Angular, objects are mutable, and Angular must perform deep dirty checks on every object to be perfectly consistent. As pointed out by the author of the blog post, this needs to be repeated until there are no more changes detected. That's the whole point of Angular's digest loop. React's data model is much simpler, at least at a high level. State changes are explicit, and data is immutable. This means that whenever you give a component new props, it can simply do a deep comparison of the data with the previous version and mark the component as dirty if it's changed. (Setting a new state always triggers a re-render, no matter if the data is different or not.) Since data changes only happen explicitly, and flow naturally through component nesting, it doesn't need process a lot of data to figure out what needs to be updated. The list of dirty components is then processed to produce the virtual DOM, which is then diffed against the real DOM. Doing anything with the real DOM is expensive, whereas the virtual DOM is extremely fast. So is building the virtual DOM; while it's true that a component's render() method needs to build its own tree every time it's called, re-rendering is extremely fast, even if you actually change state near the root of the virtual DOM (which causes a bigger cascade of dirty checks). Current JS engines are capable of creating tens of thousands of objects in just a few milliseconds. (There are a few of optimization tricks you can use to avoid renders, too. In particular, there is PureRenderMixin, which declares that your component is "pure", meaning that given the same props and state, it will always render the same tree, allowing React to do shallower checks to determine if a render is needed.)

lobster_johnson 12y ago

Coincidentally, the scoping issue is almost exactly the same issue that plagued Zope, a Python-based app server, back in the day. In Zope, any property could be inherited not just from the parent object, but from the current context; you could invoke the object path "a.b" and b would inherit from b, but if you invoked the object path "a.c.b", b would inherit from c instead. They called this design pattern "acquisition", and seemed rather proud of it until they realized it was the kind of magic that was ultimately too magical for its own good. The Zope guys tried very hard to eradicate it, and in the process ended up alienating all the developers with the new, non-backwards-compatible version. Funnily enough, there is another Angular parallel to Zope: Just like Zope 3, AngularJS 2.0 is also not backwards-compatible. Angular's parameter-based dependency injection is coincidentally the same reason Martini [1] is slower than most other Golang web frameworks. Clever, sure, but ultimately a design flaw. These problems demonstrate how important it is to introduce a good design from the very beginning. You can fix bad code, but bad design is much harder to change. [1] https://github.com/go-martini/martini#service-injection https://github.com/go-martini/martini#service-injection

chumpalump 12y ago
You nailed it, Sir. This "zopeness" is exactly what kept me from adopting AngularJs.

mcv 12y ago

I loved Angular. And I still love many parts of it. I like the declarative style, the automatic data binding, and all that other stuff that's painful in JQuery, but fairly painless in Angular. Well, painless at first. Because eventually you run into the limitations. The data binding doesn't scale, a lot of things that are easy to declare (particularly scope variables for directives) are a lot more complex than they initially seem. The article hasn't even scratched the surface on problems with scope in Angular. And then there's the fact that my templates keep turning everything into strings. Too often, when binding stuff from an outside controller to the isolate scope of a directive, I keep having explicitly to turn all the strings back into numbers. Still, Angular does a lot of very neat stuff. There are just too many common use cases that the neat stuff doesn't really cover very well.