9 ms·

Criticisms of Angular

146 points by andreapaiola 11y ago

stupidcar 11y ago
When the author doesn't understand the difference between a module system and a dependency injection system, it's hard to take the rest of what he says seriously.
- troels 11y ago
  They kind of solve the same problem, but in different ways. I, for one, think it's debatable if the 800 lb gorilla that is dependency injection has any merit in javascript.
  - emsy 11y ago
    DI is not an "800 lb gorilla". If anything, certain implementations of DI frameworks are (I'm looking at you, Spring).
    - troels 11y ago
      I disagree. They were a solution to the inflexibility of rigid languages like Java, but seems entirely alien in the context of Javascript. A DI framework adds a load of indirection.
      - brodo 11y ago
        DI is a design principle, not a class for frameworks. DI just means to "inject" the dependancies of an object through constructor arguments, setters or by simply setting instance (aka member) variables. In other words, DI means that you don't use global variables (aka singletons). DI does not provide any more flexibility itself, but most DI frameworks encourage the usage of interfaces instead of concrete classes (which is a good thing) when it comes to defining dependancies. Sadly however, the fancy pants therm for using interfaces is "dependency inversion", because when using interfaces, the compile time and runtime dependancies of a class point in opposite directions. As you can imagine, this lead to a lot of confusion.
      - radicalbyte 11y ago
        It has nothing to do with the "rigidity" of Java, and everything to do with the complexity of the problems solved in Java land. The value comes as you scale the number of developers, the lifetime of the software and the complexity of the product. This holds just as much for Java as it does for Ruby or Javascript.
  - trumbitta2 11y ago
    I like Angular's DI. It makes it easy – to me, but YMMV - to organize my thoughts and my code.
    - troels 11y ago
      Fair enough. It's probably a matter of taste to some extend. I generally don't like too much structure unless there are clear benefits and DI doesn't seem to hold up on that scale. The problem it's solving has traditionally been solved with a dozen global variables. And while the purists may scuff at this, I find that in practise it's never an issue in otherwise well structured code.
      - JustSomeNobody 11y ago
        Too many people reach for DI first where some quiet time with a pencil and paper could produce a much better design that doesn't need a DI framework.
  - aikah 11y ago
    > They kind of solve the same problem no they don't. That's a fundamental mistake to say that. DI is about inversion of control , modules don't do that.
    - troels 11y ago
      IoC is the way that DI solves the problem. But the problem is dependency management - and there are other ways around that.
      - stupidcar 11y ago
        The difference is that modules systems specify statically resolved dependencies between code files. DI and IoC specify dynamically resolved dependencies between instances of objects. They are both useful, but they both solve different problems.
  - mercurial 11y ago
    Dependency injection has merit in any language. Throw DI out of the window, testability goes with it. Now, on the matter of IOC containers, you can easily roll your own or use a sane one (eg, Guava in Java).
- l1ambda 11y ago
  The author's point was that with Angular, the Angular module system you must use (you can't opt out), and you are most likely nowadays going to be using commonJS or AMD anyway, so you end up with two module systems. At the time (in 2009) it probably made sense to come up with an Angular module system, but now that most people use require/webpack/browserify, it has become a hinderance. The reason being you can't just require() a module in a unit test, you have to bootstrap the entire Angular system and all angular modules, which is a huge pain for unit testing and causes all sorts of side effects. The other thing the author didn't mention is you can't debug your HTML templates. With Mithril, you can set a regular javascript breakpoint in your views. Directives and code-in-HTML essentially reimplement a half-assed version of JavaScript. (The same criticism applies to JSTL which throws out a perfectly good language, Java, and forces you to use XML and tag libraries.) HTML logic creates complexity because it invents a new programming language in the HTML. The code-as-HTML is the root problem that causes all the scope issues, all the explosion and complexity of directives, filters, and the inability to set breakpoints in views. With Mithril you don't have this whole directive/filters nonsense, you just write functions. I've written more about this subject at: https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d659c24bae https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d6...
Antwan 11y ago
"With the next article we’re going to introduce you to React JS, [...] that have won us over entirely." How can you take the article seriously with that kind of conclusion.
- apeacox 11y ago
  why?
  - fridek 11y ago
    Because React solves only the directive part of Angular? I'm not saying it's great BTW, but comparing React to Angular is silly. That's like saying you chose lodash.js over Angular.
    - kcorbitt 11y ago
      This was probably a valid observation two years ago, when the React story on state management was "bring your own solution." But these days, although it's technically a separate project, Flux is the de-facto state management solution that a React-first webapp will use. There are lots of competing implementations (I use redux) but my point is that you'd be hard-pressed to find an app written in Angular that couldn't also be written using React+Flux. Of course the architecture is going to look different, but you can certainly get to the same place.
      - fridek 11y ago
        Sure you can. And as I said, I'm not a big angular lover. In fact we used Backbone for REST in it, because of shortcomings of the $resource at the time. And flux is great and React-first, but it's not technically a part of React. And it is also great, having a choice is usually a good thing. Still I'm skeptical when people are happy just because they moved from angular to react. Or from any X to Y really. Usually the gain comes more just from rewriting things with better understanding of the project and from more established team. No one does A/B studies on it, right?
    - 11y ago
stuaxo 11y ago
This is all true, but it is still one of the best options for making websites, onwards and upwards !
- yogsototh 11y ago
  We use reagent with success. We still have some legacy code in Angular. Each time we need to change something in that old code, it reminds us how Angular has done a lot of things wrong. We often qualify Angular as the J2EE of the front.
- andreamazz 11y ago
  We're pretty happy with React+alt. The development is streamlined and easy to understand.
nioufe 11y ago
While the author makes some fair point about angular's weirdness. He fails to understand that many design choices where made because javascript and js libraries were not as advanced as today. For example the module system is made so because at the time, amd, browserify and ES6 modules were not ready. And the main point of angular 2 is not to remake angular because it was weird, it is to adapt it to new technologies.
protonfish 11y ago
He missed so much. How about non-standard invalid HTML? Breaking all searchability and accessibility? Encouraging voodoo coding?
- Loque 11y ago
  This was the deal breaker for me when first looking at Angular - loose coupling, progressive enhancement, accessibility and keeping code in its appropriate layers seemed to get thrown out for an attitude that everyone has JS running... it felt like a return to the days of Flash. I could ramble for a long time about it, anecdotally; I have peers who use (and seem to enjoy using) Angular (all .net devs), and others who point out its flaws (front-end architects). I find it a very interesting discussion point.
  - ohnomrbill 11y ago
    While I'm sure this gets abused, I think many of the people who use and enjoy Angular limit it to developing web apps. When I use Angular for something, it's a true web app, and I need to be able to execute client side code. When I have static content, I would just use HTML + CSS. If you're using Angular, the use case might justify the attitude that everyone has JS running. The same people who hold this attitude when making an Angular app might build perfectly serviceable sites to deliver static content without JS.
- kls 11y ago
  The fact that I can declare a scope variable in a directive and it is magically available in a controller is also another one, only once one starts to dig do they find out about the less than obvious scope controls to not allow what amounts to global variables. Further down that path, variables can be declared in the template, in the controller or in a directive. There is no traceability of where state starts. Honestly I am the type that blames myself first and think I must be missing something, but there are just such junior mistakes in how Angular was implemented, that it does encourage voodoo.
- maaaats 11y ago
  You can use data-attributes and write perfectly valid HTML.
fridek 11y ago
"I’m not joking: we were perfectly able to get by in one of the Angular projects developed internally — consisting of around 200 Javascript files and a total of around 10,000 lines of code — using only factories." Funny, I could agree this is true for providers or services. Factories however can't be used for singletons, so I'd rather not know how they implemented shared state and utils.
- scotty79 11y ago
  Factory is just a function. It can easily instantiate and return singleton. You just call it instead of using `new` on it at the place of use. It's probably not very nice from philosophical standpoint but it can have its merits.
neals 11y ago
I work as a JS contractor on large custom e-commerce configurators. In the last few months I've learned that Angular is not built for large custom e-commerce configurators. Just my 2c /
narrator 11y ago
They announced recently that there will be an easy Angular 1 to Angular 2 migration path.[1] I think Google is getting blowback from the "worse is better" crowd that have supported the meteroic rise of c, php and mongodb. Specifically, the "worse is better" belief that: "There is a point where less functionality ('worse') is a preferable option ('better') in terms of practicality and usability." [2] reminds me of his criticism of "excessive" features in Angular, even though those features are there for a reason. Usually, what happens with "worse is better" is that when people start missing key features, a bunch of bolt on pre and post processor tools show up to add features (e.g linters, "strict mode",Mongo migration tools) that weren't needed in the more complete solution. 1.http://news.softpedia.com/news/google-releases-guide-on-how-to-migrate-from-angularjs-1-x-to-2-x-490106.shtml http://news.softpedia.com/news/google-releases-guide-on-how-... 2.https://en.m.wikipedia.org/wiki/Worse_is_better https://en.m.wikipedia.org/wiki/Worse_is_better [fixed]
- deleted 11y ago
  [deleted]
shubhamjain 11y ago
I haven't tried Angular yet but have built applications in React. In my opinion, frameworks like Angular suffer from a fundamental problem, that, it is almost impossible to gauge the problems of a new design unless you have a built a medium - large scale application with it which is very hard when you are just experimenting. There might be few heuristics, few rule of thumbs one can follow but still it will be hard to see if the ease - effort ratio will make the framework worthwhile. You can make things too "magical" and also too "worthless". I guess that's why everyone complains that it is easier to build a Todo application in Angular but the troubles grow as you grow bigger. The reason why React is successful might be they did get a chance to experiment the architecture on their own things before releasing it to the public.
- hellofunk 11y ago
  I've never understood any comparison between React and Angular. To me it seems like trying to compare a slick car to a fancy car garage. They try to solve quite different problems, right?
  - jeremiep 11y ago
    I've used both and I could completely replace Angular with React and some scaffolding code. I used Angular on medium to large web apps in the past and while its easy to get started you always get tons of problems at scale. Staying at scale without problems requires so much discipline its not even worth mentioning. The two-way bindings are just the wrong way to go in order to keep things simple as you scale. It becomes nearly impossible to reason about the performance of your app or what is going to trigger if you change a model. This is way, way too complex to build an application. With React most of this complexity goes away. I'm also using React from ClojureScript through the Om library so these might be contributing to said simplicity!
  - lojack 11y ago
    > They try to solve quite different problems, right? Sort of. The problem React is solving is a subset of the problem Angular is solving. It's a bit more like comparing an older model sports car to a modern engine.
Kiro 11y ago
OT: why are they using "BazaarJS" in the titles of both this and the post they're linking to but "BazarJS" everywhere else in the articles?
- apeacox 11y ago
  "BazarJS" is a series of articles about JS frameworks, pre-processors, etc... they already published the same in italian language some months ago. now they're re-publishing (with eventual updates) the same in english.
nateabele 11y ago
So, they trot out the same tired arguments against Angular that people have been making since the beginning, and this makes the front page where people engage in serious discussion about it? Did I miss some subtle novelty about this post, or is Angular ennui just that popular on HN?
- fein 11y ago
  Not to mention his example is just straight wrong about $scope and ng-if. His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds scope inside an ng-if. I agree that angular 1.1.5 had it's warts, if that's what this is supposed to be about. The current release version of angular is 1.4, about to be 1.5. Edit: After fully reading through this blog post; it's almost all wrong. Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model. Dependency Injection: Are you kidding me? He's not even using the array notation for proper DI with minification. Pointless Complexity: This is an actual valid argument, and the only one on the blog. Google has some pretty bad documents for angular, especially when describing directives that isolate scope. Server Side Rendering: Uh, the whole idea behind stuff like angular is decoupled frontends from your server. Build a REST API and point angular at it; no need to ship layout code with services. Angular 2: There's an upgrade path that should allow the two to exist in tandem. There's no reason to not keep writing angular 1.x code right now. It's not like Angular 2 being released means all your previous code is worthless.
  - jksmith 11y ago
    +1 on just saying no to server side rendering. This should be idiomatic.
    - strickjb9 11y ago
      There are tradeoffs to both. Server-side will always have a seat at the table. Ex - populating a simple key-value select statement will always perform better using server-side.
maaaats 11y ago
Funny that the last complaint is that Angular2 will break a lot of stuff, when it will actually fix most of the issues he's mentioning above. One can never win.
rbalicki 11y ago
Valid criticisms of Angular include that it gives you enough rope to hang yourself, that the documentation/tutorials teach you to code Angular in a bad way (abuse the $scope object, etc.) in the interest of making it "easy" and that the terminology and symbols used can be simplified. However, once you learn to avoid Angular's pitfalls, it's a very powerful tool for creating large apps that do not collapse under their own weight. To illustrate, how often do experienced Angular devs make $scope inheritance errors? If you are, you're not using controllerAs syntax and are coding sloppily. No framework can save you from sloppy coding.
- bphogan 11y ago
  Yours is the third post I see that amounts to "you're doing it wrong." But if the docs are bad, and there are pitfalls that experienced Angular devs know to avoid, how can we distill that down into common knowledge that beginners can avoid? Can you recommend a book or resource that does that?
  - rbalicki 11y ago
    Off the top of my head, I can recommend: * ng-newsletter * bennadal.com (fairly advanced, and sometimes unorthodox) * I found the egghead.io videos very helpful when I was starting * John Papa's angular style guide If I recall correctly, most of the other resources I've relied on were strewn about the web, and not at any one particular website.
- spmurrayzzz 11y ago
  One of the trends I've seen in my own hiring is that many Angular devs lack a solid understanding of fundamental JavaScript (closures, prototypes, functional programming, DOM API, async patterns, et al). This may be a function of how much the framework is able to abstract away from the user. This dearth can lead to lots of code smells, bugs, antipatterns, and other grenades that can present significant problems at scale no matter what framework you choose to go with. So if it's true that many Angular apps have problems at scale — one hypothesis would be that it may be a reflection of the selection bias of those who choose to use the framework. Which is not to say that advanced JS people aren't using the framework (they clearly are) but anecdotally, upwards of 90% of the Angular-based devs I've interviewed or interacted with personally lack an understanding of many of the aforementioned JS fundamentals.
robotnoises 11y ago
I need to get my butt in gear and finish-up my blog on criticisms of criticisms of Angular.
IgorPartola 11y ago
Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event listener for every onclick, onchange, and onkeypress. I want the values in my models and the values in the DOM to be in sync. I like using nearly straight up HTML as my template. I do this in Django, so why not in Angular? I like that I don't need to render things server-side because then the server is just running a REST-ful API. That way I can write different clients for the API and don't have to change the server (mobile app, desktop UI, etc.) I like the clean separation between presentation (HTML templates), UI logic (controllers), and communication (services). I feel like Angular's biggest problem is the documentation. It starts out talking about things like dependency injection and why that's good, instead of simply displaying how to use the framework. It's got a steep learning curve and it just seems that people get scared of the documentation and run away before they really give it a try.
- jfoster 11y ago
  I think Angular is so widely used because so many people do like it. It has quirks and shortcomings (per the article), but those are only relevant because it is generally liked and used by so many. I agree on the documentation being unusual. I found the Angular Style Guide to be a huge help: https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide
  - wallawe 11y ago
    Totally agree. That style guide has changed the way I write Angular apps completely, and it feels so much cleaner.
- lhorie 11y ago
  > it just seems that people get scared of the documentation and run away before they really give it a try Anedoctally, as the author of another JS framework (http://mithril.js.org http://mithril.js.org), I see a lot of people migrating away from Angular due to complexity, bloat and performance issues. I, myself, spent a good two years wrestling w/ Angular problems full time before jumping ship. Our apps were quite complex and we were fully invested in trying to make Angular work, and definitely not just making a half-assed effort to like it. So it's definitely not just newbies.
aikah 11y ago
Say what you will I like Angular 1. And there is a ton of resources and books all over the web to help.There is a solution to everything and it's pretty RAD However, I'm very skeptical about Angular 2. For several reasons. First (I tested it) right now, it is way too complex and unnecessary verbose. They wanted to support future techs like web components, observables (reactive functional programming) which are great, but it's not that easy to use. Some people will not like the Rx approach which forces one to rethink the way one codes. There is serious mental gymnastic involved here when one has to think in terms of cold and hot streams, especially when one is used to ng1. Of course, people who love Typescript will enjoy it,and it's true it's easier to figure out what is what with explicit types, but people who are sticking with ES5 for various reasons will hate all the boilerplate needed to get started. And they went crazy with dependency injection,this time, this is a divisive issue among programmers and while ng1 DI was light weight, ng2 DI is going full Java which Java/C# folks will like, but i'm not so sure about the rest. The biggest question is, how is ng2 relevant compared to React + Flux/Relay? since it tries to do the same thing but with more complexity? with that weird template syntax ([attr-read-from]="variable" , (event)="handler" ,[(read-write)]="variable", *template-directive="expression" ... )? React has JSX which is a serious advantage. ng2 will be ready in a year at best but businesses can be tempted to just move to React in the meantime and then stick with that. .
- Bahamut 11y ago
  I think if a business needs to, I would recommend they move to React now - Angular 2 is shaping up to be quite impressive, and taking pretty much all of the lessons that Facebook has brought with React (& possibilities brought about by the generally clean architecture such as server-side rendering, native mobile app support, etc.), and refining it ruthlessly, but you can only use what is available if you are consuming a third party library. Once Angular 2 is ready though, I would only consider using it in a new project unless the company is already deeply invested in React (or other tech) & doesn't have the time to migrate. Angular 2 is still rough today, and that is why it is still in alpha - the Angular team is still trying to figure out what do they need to expose in the framework for consumers to build flexible components. In addition, the testing situation still needs to be refined some. The UI Bootstrap team is in the beginning of migration to Angular 2, and we already came across some pain points that Google is working with us to try to ease as much as possible. As far as ng2 vs. React - ng2 uses pure HTML templates still. ng2 manages to use this and still optimize dramatically over React due to how change detection works in Angular. The template syntax is not complicated once you get used to it - it is much easier than remembering all of the edge cases that JSX has had to write around (i.e. className) due to issues of conflict with JS itself, and certainly much easier than remembering all of the little caveats and edge aspects of ng1. Web component support for Shadow DOM is opt-in, and it does use the template tag for custom components. Observables have some overhead, but the great thing is that it is optional for many things, and easy to use when something is exposed as an observable. The Angular 2 DI is much better than the Angular 1 version - it is much more powerful and doesn't require a hacky implementation due to its use of decorators.
SFjulie1 11y ago
You have the calvinist way of coding: learning, coding, and working harder to improve. Believing that experience will help you build a greater skill. You put your faith in yourself and hard work. You aim for simple elegant code that talks less and does better. You believe more in efficient design than in code: you are a programmer, not a coder. You have the catholic way of coding: believing in a framework like a church and venerating a bloated edifice with multiple weaknesses to support your most complex code. Most of the angular coder I have met are just lazy coders believing in magic and tradition not wishing to see coding has a hard earned skilled acquired by craftsmanship. Coding is not a "tradition", it is a "Beruf". I am a protestant programmer, and I believe I will achieve better code with more hard work and learning than by venerating any bloated layers in between that will come in my profound gained understanding of programming. [The one relying on his hard work] is like a man building a house, who dug down deep and laid the foundation on rock. When a flood came, the torrent struck that house but could not shake it, because it was well built. (Luke 6:48) PS: I do angular. I fix my colleagues' works and it always make me want to puke to dig in this insanity everytime.
wmil 11y ago
I always feel like scope inheritance problems are overstated. It's weird, but it's weird in the exact way that JS prototypical inheritance is weird. So it's important to learn. Anyways the fix is simple, always initialize your variables before you use them. Either in the controller or using an ng-init.
SonicSoul 11y ago
This is a rehash of the same problems that have been circulating for years [0]. There is literately not a single original thing here. Most of these issues are gotchas that can easily be avoided once the developer is aware of them (such as scope inheritance / dynamic scope which is due to Javascript Prototypal Inheritance [1]). What's ironic is that angular 2 is fully rewritten in part to fix all of these issues, but none of that is mentioned, and the only focus is on how much Angular 2 sucks because it's not compatible with 1. There is also no mention of clear migration path and ability to run angular 1 and 2 side by side [2] I've put 4 Angular sites in production and never faced issues due to any of these problems. I've had issues with caching, end to end testing of ajax calls, sharing functionality with non angular parts of the site. The very fact that the OP listed these issues tells me that he's not actually used Angular in production. Angular 1.x has limitations for sure but it works quite well in most scenarios. [0] http://larseidnes.com/2014/11/05/angularjs-the-bad-parts/ http://larseidnes.com/2014/11/05/angularjs-the-bad-parts/ [1] http://jimhoskins.com/2012/12/14/nested-scopes-in-angularjs.html http://jimhoskins.com/2012/12/14/nested-scopes-in-angularjs.... [2] http://angularjs.blogspot.com/2015/08/angular-1-and-angular-2-coexistence.html http://angularjs.blogspot.com/2015/08/angular-1-and-angular-... EDIT: shortened. EDIT2: added conclusion
- snorrah 11y ago
  Where is this focus about Angular 2 sucking? The author is in fact happy about Angular 2 being a re-write. Read the section under Problem 6, where he calls the proposed complete re-write of Angular courageous and laudable. Now he says this is a problem for Angular 1.x because there's no carry-over of knowledge into 2.x, but that's in no-one saying Angular 2 sucks like you are suggesting.
  - SonicSoul 11y ago
    you're right, that was not the best way to put it. I just saw this which seemed like focusing on negative w/out noting that all his complaints will be addressed. Not convinced yet? Well, what if we were to tell you that the next major version of Angular will take a scorched earth approach to the existing structure that means it will have zero retro-compatibility with what exists today?
a-guest 11y ago
Angular may not be perfect, and there are lots of other tools out there, but Angular definitely remains an option to get the job done. And when articles like this pop up, I wonder if we all unconsciously fall into the trap of the "Fallacy of the Perfect Framework" described by Shawn Wildermuth in a recent post. As if moving from one framework to a different one, we will all of the sudden have no more problems and everything will be "perfect". http://wildermuth.com/2015/09/01/Angular_v_React_v_Aurelia_v_et_al http://wildermuth.com/2015/09/01/Angular_v_React_v_Aurelia_v...
weatherlight 11y ago
I love Angular but I often find when I look on StackOverflow for a better way to do something that the most upvoted "solution" is often the WRONG way(Abusing watchers, Abusing $scope, etc) to do something and often contradicts what's in the Angular docs. I can't help but think to myself, "No wonder people hate angular. There's so much bad documentation(Official and Unofficial) and hacky solutions out there. No wonder people are having a bad time."
ldpg 11y ago
The #6 complaint on "server-side rendering" calls the rest of the article into question. This illustrates a fundamental "missing the point" of either Angular or React. Client-side templating is one of the essential ideas.
omouse 11y ago
Angular's dependency injection system is much much better than dealing with CommonJS/AMD in my opinion. I would be okay with ES6 modules too but apparently those aren't getting much love yet. The scoping in AngularJS can be a bit of a pain but I mean, if you know it's dynamically scoped and you know that the directive (ng-if) is introducing a new scope then it isn't the end of the world. Emacs has dynamic binding and it's been working on pretty well so far and contributes to extensibility. I wonder how the author would convert Angular to use lexical scoping instead of dynamic scoping; would it even be possible without forcing all directives to have a lot of boiler plate?
tkinom 11y ago
Is Angular really that popular? From google trend, Jquery is still 3-5 times more popular then Angular, React. What do you guys think? https://www.google.com/trends/explore#q=jquery%2C%20angularjs%2C%20angular%2C%20react%2C%20reactjs&cmpt=q&tz=Etc%2FGMT%2B7 https://www.google.com/trends/explore#q=jquery%2C%20angularj...
- CitizenKane 11y ago
  In terms of Single Page Application frameworks, Angular is very popular. Comparing it to jQuery doesn't really make sense as jQuery is a utility library and doesn't support all of the features that Angular has.
- vkjv 11y ago
  That's hardly a fair comparison. jQuery is a library and Angular is a framework. IIRC, Angular depends on (at least a subset) of jQuery, so it could only approach usage and never exceed.
vikingcaffiene 11y ago
> Problem #1: Scope inheritance and dynamic scoping Easily solved by using the controllerAs syntax > Problem #2: Dirty checking One time binding to the rescue here. Been available for a good while now. Dirty checking does suck though but is usually not a deal breaker. > Problem #3: Dependency injection The authors main problem here seems to be with problems minifying the code. All one needs to do is to pass in an annotations array which is an established best practice. So instead of controller('ControllerName', function($scope, $someService){}) one should use controller('ControllerName', ['$scope', '$someService', function($scope, $someService){}]) there are other more readable ways to do this such as $inject but I digress. > Problem #4: Pointless complexity This is debatable and more a matter of opinion. I disagree and think the glut of the authors woes come from not taking the time to understand the framework properly. The learning curve is steep yes but I've used a TON of javascript frameworks and Angular consistently comes out the winner long term in maintainability and stability. > Problem #5: Server-side rendering Isomorphic javascript to the rescue here. React does it better in this case but its available if you need it. Angular is a single page web app. If you knew that going in and have a problem with it now... well lets just say that its important to understand the trade offs that come with any technology one chooses to include in their stack. > Problem #6: Angular 2 Yes this was a concern, and then the angular team listened to the outcry from the community and now have been developing a migration path for users of the 1x code. They have also dedicated an entire team to continue development on the 1x codebase for as long as it remains popular thats why there are two angular websites. While I admit that angular isn't perfect (literally nothing is) nearly all of the authors criticisms are due to lack of following best practices. You can find a pretty good summation here: https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide
pwfisher 11y ago
Our company had two Angular codebases, the public site and our internal site. Experience in one taught you nothing about the other because there was no "Angular way" to structure your code. Having "enough rope to hang yourself" while our devs were just learning Angular led to an unholy mess. Development slowed to a painful crawl. We hate Angular. We're an Ember shop now. We love Ember! Angular gives you enough rope to hang yourself. Ember lets you stand on the shoulders of giants.
- SonicSoul 11y ago
  Interestingly I've heard similar sentiments from Ember developers, mainly that it is much more 'opinionated' than Angular. In my experience with Angular there is a pretty clear logic on how to structure code. I suppose that logic is not enforced so there is nothing to stop developers from just cramming all code into index.thml. Being a dev manager I've adopted feature structure [0] and it has worked quite well across all our apps. Furthermore there is pretty clear distinction on what kind of logic should be included in controller vs service vs factory vs module. This has made writing unit tests a breeze in my experience. I'd be curious to hear what Ember constructs exist that helped you so much. [0] http://www.johnpapa.net/angular-growth-structure/ http://www.johnpapa.net/angular-growth-structure/
  - trophygeek 11y ago
    I'm a bit behind on this thread and I am an Angular guy myself, but I think Ember is moving this direction. http://www.programwitherik.com/ember-pods/ http://www.programwitherik.com/ember-pods/
spleenteo 11y ago
for the record: in the second paragraph we can find this sentence: > we’ve been working with Angular for almost nine months now (the original article in italian is dated February 2015) it means this post is just a translation of something experienced a year ago (Angular 1.1) A half of the comments reply to solutions arrived on 1.4, with hindsight. This delay is definitely not clear, but casts new light on the content.
choward 11y ago
This article is about 2 years late. These are solved problems in angular 2 by default and have solutions in angular 1. = Problem #1: Scope inheritance and dynamic scoping Use directive controllers = Problem #2: Dirty checking Use immutability = Problem #3: Dependency injection I'm not really sure what the author is saying here. It sounds like he's confused and thinks DI and modules solve the same problem. The one statement he has bolded is completely false: > Angular forces you to use a third, custom designed alternative mechanism: one that is inferior to the already existing mechanisms available. You can use a module system if you want. Nothing is stopping you. = Problem #4: Pointless complexity > providers, values, factories, services, constants [...] All five concepts could easily be assigned a single identity. True, so just use providers if that makes you happy. Angular 2 also simplifies things. = Problem #5: Server-side rendering He stated a solution for angular 1. Personally, I don't really care about server side rendering so I won't elaborate. Angular 2 will have angular-universal = Problem #6: Angular 2 > Not convinced yet? Well, what if we were to tell you that the next major version of Angular will take a scorched earth approach to the existing structure that means it will have zero retro-compatibility with what exists today? > it would be simply foolish to use Angular 1.x for new applications. LOL, fear mongering. The angular team has already stated there will be a migration path to angular 2. They also announced they will continue to support angular 1 as long as people are using it. It's funny that he complains about angular 2 when it addresses his problems with angular 1.
- p3llinor3 11y ago
  Oh! So just have a bunch of arcane design patterns instead of using the tools packaged with the framework! Sounds great...
- juristr 11y ago
  ah...finally, someone that gets it and says it aloud...if I would have found this comment before, I wouldn't have put mine further below. Thx!
gizi 11y ago
Angular is the answer to another question than the question that I usually face. So, the usability guy and the graphical designers have produced HTML/CSS page designs that work well and look good. The purpose of the javascript that I will be adding, is to make sure the user interface functions. Faced with these requirements, I have never been in a situation in which I felt that something like Angular would be able to contribute anything useful. If you drag Angular into the fray, it will be the most important kid in the room that you will need to constantly babysit. Forget about what you want to achieve. Think of Angular first. Everything else is unimportant ...
brightball 11y ago
Things like this reaffirm my old guy decision to do as little in the browser as humanly possible. EDIT: Warranted a downvote. Wow.
iridium127 11y ago
It's not worth obfuscating the web for what Angular brings to the table.
juristr 11y ago
Nowadays: want lots of traffic on your blog -> rant about Angular. The problem is just that you're nearly a year too late. - yep angular has flaws (which framework doesn't?) - ya, it does dirty checking and yes, that might have perf implications if used the wrong way. But hey, 6 years ago when Angular was created it was a revolutionizing idea, and still holds today. Also, at that time no Objecte.observe existed, nor did SPAs really (well..GWT was kinda the solution at that time). But, did u check what they're doing in Angular 2? Heard about RxJS and stuff? - DI: strange syntax techniques to work around minifiers? You don't really use those, do u? heard about ngAnnotate? - Oh...AMD, UMD etc...do not dependency injection. And yes, agree, DI together in combination with AMD/UMD/... creates confusion with newbie frontend developers - Then: Angular 2 is already live on GitHub, for a while; has even it's own webpage online - and for god's sake..Angular 2 is compatible with Angular 1...read their blog posts, their Tweets, weekly meetup notes and design docs (all openely available on GDocs) - oh..and there are even some rumors server-side rendering will be possible in ng 2 I like ur blog, but if you go and rant, please check the latest status, inform yourself, then rant. Nothing against critics, they foster discussion, but only if made properly.

146 points by andreapaiola 11y ago

When the author doesn't understand the difference between a module system and a dependency injection system, it's hard to take the rest of what he says seriously.

troels 11y ago
They kind of solve the same problem, but in different ways. I, for one, think it's debatable if the 800 lb gorilla that is dependency injection has any merit in javascript.
- emsy 11y ago
  DI is not an "800 lb gorilla". If anything, certain implementations of DI frameworks are (I'm looking at you, Spring).
  - troels 11y ago
    I disagree. They were a solution to the inflexibility of rigid languages like Java, but seems entirely alien in the context of Javascript. A DI framework adds a load of indirection.
    - brodo 11y ago
      DI is a design principle, not a class for frameworks. DI just means to "inject" the dependancies of an object through constructor arguments, setters or by simply setting instance (aka member) variables. In other words, DI means that you don't use global variables (aka singletons). DI does not provide any more flexibility itself, but most DI frameworks encourage the usage of interfaces instead of concrete classes (which is a good thing) when it comes to defining dependancies. Sadly however, the fancy pants therm for using interfaces is "dependency inversion", because when using interfaces, the compile time and runtime dependancies of a class point in opposite directions. As you can imagine, this lead to a lot of confusion.
    - radicalbyte 11y ago
      It has nothing to do with the "rigidity" of Java, and everything to do with the complexity of the problems solved in Java land. The value comes as you scale the number of developers, the lifetime of the software and the complexity of the product. This holds just as much for Java as it does for Ruby or Javascript.
- trumbitta2 11y ago
  I like Angular's DI. It makes it easy – to me, but YMMV - to organize my thoughts and my code.
  - troels 11y ago
    Fair enough. It's probably a matter of taste to some extend. I generally don't like too much structure unless there are clear benefits and DI doesn't seem to hold up on that scale. The problem it's solving has traditionally been solved with a dozen global variables. And while the purists may scuff at this, I find that in practise it's never an issue in otherwise well structured code.
    - JustSomeNobody 11y ago
      Too many people reach for DI first where some quiet time with a pencil and paper could produce a much better design that doesn't need a DI framework.
- aikah 11y ago
  > They kind of solve the same problem no they don't. That's a fundamental mistake to say that. DI is about inversion of control , modules don't do that.
  - troels 11y ago
    IoC is the way that DI solves the problem. But the problem is dependency management - and there are other ways around that.
    - stupidcar 11y ago
      The difference is that modules systems specify statically resolved dependencies between code files. DI and IoC specify dynamically resolved dependencies between instances of objects. They are both useful, but they both solve different problems.
- mercurial 11y ago
  Dependency injection has merit in any language. Throw DI out of the window, testability goes with it. Now, on the matter of IOC containers, you can easily roll your own or use a sane one (eg, Guava in Java).
l1ambda 11y ago
The author's point was that with Angular, the Angular module system you must use (you can't opt out), and you are most likely nowadays going to be using commonJS or AMD anyway, so you end up with two module systems. At the time (in 2009) it probably made sense to come up with an Angular module system, but now that most people use require/webpack/browserify, it has become a hinderance. The reason being you can't just require() a module in a unit test, you have to bootstrap the entire Angular system and all angular modules, which is a huge pain for unit testing and causes all sorts of side effects. The other thing the author didn't mention is you can't debug your HTML templates. With Mithril, you can set a regular javascript breakpoint in your views. Directives and code-in-HTML essentially reimplement a half-assed version of JavaScript. (The same criticism applies to JSTL which throws out a perfectly good language, Java, and forces you to use XML and tag libraries.) HTML logic creates complexity because it invents a new programming language in the HTML. The code-as-HTML is the root problem that causes all the scope issues, all the explosion and complexity of directives, filters, and the inability to set breakpoints in views. With Mithril you don't have this whole directive/filters nonsense, you just write functions. I've written more about this subject at: https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d659c24bae https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d6...

Antwan 11y ago

"With the next article we’re going to introduce you to React JS, [...] that have won us over entirely." How can you take the article seriously with that kind of conclusion.

apeacox 11y ago
why?
- fridek 11y ago
  Because React solves only the directive part of Angular? I'm not saying it's great BTW, but comparing React to Angular is silly. That's like saying you chose lodash.js over Angular.
  - kcorbitt 11y ago
    This was probably a valid observation two years ago, when the React story on state management was "bring your own solution." But these days, although it's technically a separate project, Flux is the de-facto state management solution that a React-first webapp will use. There are lots of competing implementations (I use redux) but my point is that you'd be hard-pressed to find an app written in Angular that couldn't also be written using React+Flux. Of course the architecture is going to look different, but you can certainly get to the same place.
    - fridek 11y ago
      Sure you can. And as I said, I'm not a big angular lover. In fact we used Backbone for REST in it, because of shortcomings of the $resource at the time. And flux is great and React-first, but it's not technically a part of React. And it is also great, having a choice is usually a good thing. Still I'm skeptical when people are happy just because they moved from angular to react. Or from any X to Y really. Usually the gain comes more just from rewriting things with better understanding of the project and from more established team. No one does A/B studies on it, right?
  - 11y ago

stuaxo 11y ago

This is all true, but it is still one of the best options for making websites, onwards and upwards !

yogsototh 11y ago
We use reagent with success. We still have some legacy code in Angular. Each time we need to change something in that old code, it reminds us how Angular has done a lot of things wrong. We often qualify Angular as the J2EE of the front.
andreamazz 11y ago
We're pretty happy with React+alt. The development is streamlined and easy to understand.

nioufe 11y ago

While the author makes some fair point about angular's weirdness. He fails to understand that many design choices where made because javascript and js libraries were not as advanced as today. For example the module system is made so because at the time, amd, browserify and ES6 modules were not ready. And the main point of angular 2 is not to remake angular because it was weird, it is to adapt it to new technologies.

protonfish 11y ago

He missed so much. How about non-standard invalid HTML? Breaking all searchability and accessibility? Encouraging voodoo coding?

Loque 11y ago
This was the deal breaker for me when first looking at Angular - loose coupling, progressive enhancement, accessibility and keeping code in its appropriate layers seemed to get thrown out for an attitude that everyone has JS running... it felt like a return to the days of Flash. I could ramble for a long time about it, anecdotally; I have peers who use (and seem to enjoy using) Angular (all .net devs), and others who point out its flaws (front-end architects). I find it a very interesting discussion point.
- ohnomrbill 11y ago
  While I'm sure this gets abused, I think many of the people who use and enjoy Angular limit it to developing web apps. When I use Angular for something, it's a true web app, and I need to be able to execute client side code. When I have static content, I would just use HTML + CSS. If you're using Angular, the use case might justify the attitude that everyone has JS running. The same people who hold this attitude when making an Angular app might build perfectly serviceable sites to deliver static content without JS.
kls 11y ago
The fact that I can declare a scope variable in a directive and it is magically available in a controller is also another one, only once one starts to dig do they find out about the less than obvious scope controls to not allow what amounts to global variables. Further down that path, variables can be declared in the template, in the controller or in a directive. There is no traceability of where state starts. Honestly I am the type that blames myself first and think I must be missing something, but there are just such junior mistakes in how Angular was implemented, that it does encourage voodoo.
maaaats 11y ago
You can use data-attributes and write perfectly valid HTML.

fridek 11y ago

"I’m not joking: we were perfectly able to get by in one of the Angular projects developed internally — consisting of around 200 Javascript files and a total of around 10,000 lines of code — using only factories." Funny, I could agree this is true for providers or services. Factories however can't be used for singletons, so I'd rather not know how they implemented shared state and utils.

scotty79 11y ago
Factory is just a function. It can easily instantiate and return singleton. You just call it instead of using `new` on it at the place of use. It's probably not very nice from philosophical standpoint but it can have its merits.

neals 11y ago

I work as a JS contractor on large custom e-commerce configurators. In the last few months I've learned that Angular is not built for large custom e-commerce configurators. Just my 2c /

narrator 11y ago

They announced recently that there will be an easy Angular 1 to Angular 2 migration path.[1] I think Google is getting blowback from the "worse is better" crowd that have supported the meteroic rise of c, php and mongodb. Specifically, the "worse is better" belief that: "There is a point where less functionality ('worse') is a preferable option ('better') in terms of practicality and usability." [2] reminds me of his criticism of "excessive" features in Angular, even though those features are there for a reason. Usually, what happens with "worse is better" is that when people start missing key features, a bunch of bolt on pre and post processor tools show up to add features (e.g linters, "strict mode",Mongo migration tools) that weren't needed in the more complete solution. 1.http://news.softpedia.com/news/google-releases-guide-on-how-to-migrate-from-angularjs-1-x-to-2-x-490106.shtml http://news.softpedia.com/news/google-releases-guide-on-how-... 2.https://en.m.wikipedia.org/wiki/Worse_is_better https://en.m.wikipedia.org/wiki/Worse_is_better [fixed]

deleted 11y ago
[deleted]

shubhamjain 11y ago

I haven't tried Angular yet but have built applications in React. In my opinion, frameworks like Angular suffer from a fundamental problem, that, it is almost impossible to gauge the problems of a new design unless you have a built a medium - large scale application with it which is very hard when you are just experimenting. There might be few heuristics, few rule of thumbs one can follow but still it will be hard to see if the ease - effort ratio will make the framework worthwhile. You can make things too "magical" and also too "worthless". I guess that's why everyone complains that it is easier to build a Todo application in Angular but the troubles grow as you grow bigger. The reason why React is successful might be they did get a chance to experiment the architecture on their own things before releasing it to the public.

hellofunk 11y ago
I've never understood any comparison between React and Angular. To me it seems like trying to compare a slick car to a fancy car garage. They try to solve quite different problems, right?
- jeremiep 11y ago
  I've used both and I could completely replace Angular with React and some scaffolding code. I used Angular on medium to large web apps in the past and while its easy to get started you always get tons of problems at scale. Staying at scale without problems requires so much discipline its not even worth mentioning. The two-way bindings are just the wrong way to go in order to keep things simple as you scale. It becomes nearly impossible to reason about the performance of your app or what is going to trigger if you change a model. This is way, way too complex to build an application. With React most of this complexity goes away. I'm also using React from ClojureScript through the Om library so these might be contributing to said simplicity!
- lojack 11y ago
  > They try to solve quite different problems, right? Sort of. The problem React is solving is a subset of the problem Angular is solving. It's a bit more like comparing an older model sports car to a modern engine.

Kiro 11y ago

OT: why are they using "BazaarJS" in the titles of both this and the post they're linking to but "BazarJS" everywhere else in the articles?

apeacox 11y ago
"BazarJS" is a series of articles about JS frameworks, pre-processors, etc... they already published the same in italian language some months ago. now they're re-publishing (with eventual updates) the same in english.

nateabele 11y ago

So, they trot out the same tired arguments against Angular that people have been making since the beginning, and this makes the front page where people engage in serious discussion about it? Did I miss some subtle novelty about this post, or is Angular ennui just that popular on HN?

fein 11y ago
Not to mention his example is just straight wrong about $scope and ng-if. His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds scope inside an ng-if. I agree that angular 1.1.5 had it's warts, if that's what this is supposed to be about. The current release version of angular is 1.4, about to be 1.5. Edit: After fully reading through this blog post; it's almost all wrong. Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model. Dependency Injection: Are you kidding me? He's not even using the array notation for proper DI with minification. Pointless Complexity: This is an actual valid argument, and the only one on the blog. Google has some pretty bad documents for angular, especially when describing directives that isolate scope. Server Side Rendering: Uh, the whole idea behind stuff like angular is decoupled frontends from your server. Build a REST API and point angular at it; no need to ship layout code with services. Angular 2: There's an upgrade path that should allow the two to exist in tandem. There's no reason to not keep writing angular 1.x code right now. It's not like Angular 2 being released means all your previous code is worthless.
- jksmith 11y ago
  +1 on just saying no to server side rendering. This should be idiomatic.
  - strickjb9 11y ago
    There are tradeoffs to both. Server-side will always have a seat at the table. Ex - populating a simple key-value select statement will always perform better using server-side.

maaaats 11y ago

Funny that the last complaint is that Angular2 will break a lot of stuff, when it will actually fix most of the issues he's mentioning above. One can never win.

rbalicki 11y ago

Valid criticisms of Angular include that it gives you enough rope to hang yourself, that the documentation/tutorials teach you to code Angular in a bad way (abuse the $scope object, etc.) in the interest of making it "easy" and that the terminology and symbols used can be simplified. However, once you learn to avoid Angular's pitfalls, it's a very powerful tool for creating large apps that do not collapse under their own weight. To illustrate, how often do experienced Angular devs make $scope inheritance errors? If you are, you're not using controllerAs syntax and are coding sloppily. No framework can save you from sloppy coding.

bphogan 11y ago
Yours is the third post I see that amounts to "you're doing it wrong." But if the docs are bad, and there are pitfalls that experienced Angular devs know to avoid, how can we distill that down into common knowledge that beginners can avoid? Can you recommend a book or resource that does that?
- rbalicki 11y ago
  Off the top of my head, I can recommend: * ng-newsletter * bennadal.com (fairly advanced, and sometimes unorthodox) * I found the egghead.io videos very helpful when I was starting * John Papa's angular style guide If I recall correctly, most of the other resources I've relied on were strewn about the web, and not at any one particular website.
spmurrayzzz 11y ago
One of the trends I've seen in my own hiring is that many Angular devs lack a solid understanding of fundamental JavaScript (closures, prototypes, functional programming, DOM API, async patterns, et al). This may be a function of how much the framework is able to abstract away from the user. This dearth can lead to lots of code smells, bugs, antipatterns, and other grenades that can present significant problems at scale no matter what framework you choose to go with. So if it's true that many Angular apps have problems at scale — one hypothesis would be that it may be a reflection of the selection bias of those who choose to use the framework. Which is not to say that advanced JS people aren't using the framework (they clearly are) but anecdotally, upwards of 90% of the Angular-based devs I've interviewed or interacted with personally lack an understanding of many of the aforementioned JS fundamentals.

robotnoises 11y ago

I need to get my butt in gear and finish-up my blog on criticisms of criticisms of Angular.

IgorPartola 11y ago

Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event listener for every onclick, onchange, and onkeypress. I want the values in my models and the values in the DOM to be in sync. I like using nearly straight up HTML as my template. I do this in Django, so why not in Angular? I like that I don't need to render things server-side because then the server is just running a REST-ful API. That way I can write different clients for the API and don't have to change the server (mobile app, desktop UI, etc.) I like the clean separation between presentation (HTML templates), UI logic (controllers), and communication (services). I feel like Angular's biggest problem is the documentation. It starts out talking about things like dependency injection and why that's good, instead of simply displaying how to use the framework. It's got a steep learning curve and it just seems that people get scared of the documentation and run away before they really give it a try.

jfoster 11y ago
I think Angular is so widely used because so many people do like it. It has quirks and shortcomings (per the article), but those are only relevant because it is generally liked and used by so many. I agree on the documentation being unusual. I found the Angular Style Guide to be a huge help: https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide
- wallawe 11y ago
  Totally agree. That style guide has changed the way I write Angular apps completely, and it feels so much cleaner.
lhorie 11y ago
> it just seems that people get scared of the documentation and run away before they really give it a try Anedoctally, as the author of another JS framework (http://mithril.js.org http://mithril.js.org), I see a lot of people migrating away from Angular due to complexity, bloat and performance issues. I, myself, spent a good two years wrestling w/ Angular problems full time before jumping ship. Our apps were quite complex and we were fully invested in trying to make Angular work, and definitely not just making a half-assed effort to like it. So it's definitely not just newbies.

aikah 11y ago

Say what you will I like Angular 1. And there is a ton of resources and books all over the web to help.There is a solution to everything and it's pretty RAD However, I'm very skeptical about Angular 2. For several reasons. First (I tested it) right now, it is way too complex and unnecessary verbose. They wanted to support future techs like web components, observables (reactive functional programming) which are great, but it's not that easy to use. Some people will not like the Rx approach which forces one to rethink the way one codes. There is serious mental gymnastic involved here when one has to think in terms of cold and hot streams, especially when one is used to ng1. Of course, people who love Typescript will enjoy it,and it's true it's easier to figure out what is what with explicit types, but people who are sticking with ES5 for various reasons will hate all the boilerplate needed to get started. And they went crazy with dependency injection,this time, this is a divisive issue among programmers and while ng1 DI was light weight, ng2 DI is going full Java which Java/C# folks will like, but i'm not so sure about the rest. The biggest question is, how is ng2 relevant compared to React + Flux/Relay? since it tries to do the same thing but with more complexity? with that weird template syntax ([attr-read-from]="variable" , (event)="handler" ,[(read-write)]="variable", *template-directive="expression" ... )? React has JSX which is a serious advantage. ng2 will be ready in a year at best but businesses can be tempted to just move to React in the meantime and then stick with that. .

Bahamut 11y ago
I think if a business needs to, I would recommend they move to React now - Angular 2 is shaping up to be quite impressive, and taking pretty much all of the lessons that Facebook has brought with React (& possibilities brought about by the generally clean architecture such as server-side rendering, native mobile app support, etc.), and refining it ruthlessly, but you can only use what is available if you are consuming a third party library. Once Angular 2 is ready though, I would only consider using it in a new project unless the company is already deeply invested in React (or other tech) & doesn't have the time to migrate. Angular 2 is still rough today, and that is why it is still in alpha - the Angular team is still trying to figure out what do they need to expose in the framework for consumers to build flexible components. In addition, the testing situation still needs to be refined some. The UI Bootstrap team is in the beginning of migration to Angular 2, and we already came across some pain points that Google is working with us to try to ease as much as possible. As far as ng2 vs. React - ng2 uses pure HTML templates still. ng2 manages to use this and still optimize dramatically over React due to how change detection works in Angular. The template syntax is not complicated once you get used to it - it is much easier than remembering all of the edge cases that JSX has had to write around (i.e. className) due to issues of conflict with JS itself, and certainly much easier than remembering all of the little caveats and edge aspects of ng1. Web component support for Shadow DOM is opt-in, and it does use the template tag for custom components. Observables have some overhead, but the great thing is that it is optional for many things, and easy to use when something is exposed as an observable. The Angular 2 DI is much better than the Angular 1 version - it is much more powerful and doesn't require a hacky implementation due to its use of decorators.

SFjulie1 11y ago

You have the calvinist way of coding: learning, coding, and working harder to improve. Believing that experience will help you build a greater skill. You put your faith in yourself and hard work. You aim for simple elegant code that talks less and does better. You believe more in efficient design than in code: you are a programmer, not a coder. You have the catholic way of coding: believing in a framework like a church and venerating a bloated edifice with multiple weaknesses to support your most complex code. Most of the angular coder I have met are just lazy coders believing in magic and tradition not wishing to see coding has a hard earned skilled acquired by craftsmanship. Coding is not a "tradition", it is a "Beruf". I am a protestant programmer, and I believe I will achieve better code with more hard work and learning than by venerating any bloated layers in between that will come in my profound gained understanding of programming. [The one relying on his hard work] is like a man building a house, who dug down deep and laid the foundation on rock. When a flood came, the torrent struck that house but could not shake it, because it was well built. (Luke 6:48) PS: I do angular. I fix my colleagues' works and it always make me want to puke to dig in this insanity everytime.

wmil 11y ago

I always feel like scope inheritance problems are overstated. It's weird, but it's weird in the exact way that JS prototypical inheritance is weird. So it's important to learn. Anyways the fix is simple, always initialize your variables before you use them. Either in the controller or using an ng-init.

SonicSoul 11y ago

This is a rehash of the same problems that have been circulating for years [0]. There is literately not a single original thing here. Most of these issues are gotchas that can easily be avoided once the developer is aware of them (such as scope inheritance / dynamic scope which is due to Javascript Prototypal Inheritance [1]). What's ironic is that angular 2 is fully rewritten in part to fix all of these issues, but none of that is mentioned, and the only focus is on how much Angular 2 sucks because it's not compatible with 1. There is also no mention of clear migration path and ability to run angular 1 and 2 side by side [2] I've put 4 Angular sites in production and never faced issues due to any of these problems. I've had issues with caching, end to end testing of ajax calls, sharing functionality with non angular parts of the site. The very fact that the OP listed these issues tells me that he's not actually used Angular in production. Angular 1.x has limitations for sure but it works quite well in most scenarios. [0] http://larseidnes.com/2014/11/05/angularjs-the-bad-parts/ http://larseidnes.com/2014/11/05/angularjs-the-bad-parts/ [1] http://jimhoskins.com/2012/12/14/nested-scopes-in-angularjs.html http://jimhoskins.com/2012/12/14/nested-scopes-in-angularjs.... [2] http://angularjs.blogspot.com/2015/08/angular-1-and-angular-2-coexistence.html http://angularjs.blogspot.com/2015/08/angular-1-and-angular-... EDIT: shortened. EDIT2: added conclusion

snorrah 11y ago
Where is this focus about Angular 2 sucking? The author is in fact happy about Angular 2 being a re-write. Read the section under Problem 6, where he calls the proposed complete re-write of Angular courageous and laudable. Now he says this is a problem for Angular 1.x because there's no carry-over of knowledge into 2.x, but that's in no-one saying Angular 2 sucks like you are suggesting.
- SonicSoul 11y ago
  you're right, that was not the best way to put it. I just saw this which seemed like focusing on negative w/out noting that all his complaints will be addressed. Not convinced yet? Well, what if we were to tell you that the next major version of Angular will take a scorched earth approach to the existing structure that means it will have zero retro-compatibility with what exists today?

a-guest 11y ago

Angular may not be perfect, and there are lots of other tools out there, but Angular definitely remains an option to get the job done. And when articles like this pop up, I wonder if we all unconsciously fall into the trap of the "Fallacy of the Perfect Framework" described by Shawn Wildermuth in a recent post. As if moving from one framework to a different one, we will all of the sudden have no more problems and everything will be "perfect". http://wildermuth.com/2015/09/01/Angular_v_React_v_Aurelia_v_et_al http://wildermuth.com/2015/09/01/Angular_v_React_v_Aurelia_v...

weatherlight 11y ago

I love Angular but I often find when I look on StackOverflow for a better way to do something that the most upvoted "solution" is often the WRONG way(Abusing watchers, Abusing $scope, etc) to do something and often contradicts what's in the Angular docs. I can't help but think to myself, "No wonder people hate angular. There's so much bad documentation(Official and Unofficial) and hacky solutions out there. No wonder people are having a bad time."

ldpg 11y ago

The #6 complaint on "server-side rendering" calls the rest of the article into question. This illustrates a fundamental "missing the point" of either Angular or React. Client-side templating is one of the essential ideas.

omouse 11y ago

Angular's dependency injection system is much much better than dealing with CommonJS/AMD in my opinion. I would be okay with ES6 modules too but apparently those aren't getting much love yet. The scoping in AngularJS can be a bit of a pain but I mean, if you know it's dynamically scoped and you know that the directive (ng-if) is introducing a new scope then it isn't the end of the world. Emacs has dynamic binding and it's been working on pretty well so far and contributes to extensibility. I wonder how the author would convert Angular to use lexical scoping instead of dynamic scoping; would it even be possible without forcing all directives to have a lot of boiler plate?

tkinom 11y ago

Is Angular really that popular? From google trend, Jquery is still 3-5 times more popular then Angular, React. What do you guys think? https://www.google.com/trends/explore#q=jquery%2C%20angularjs%2C%20angular%2C%20react%2C%20reactjs&cmpt=q&tz=Etc%2FGMT%2B7 https://www.google.com/trends/explore#q=jquery%2C%20angularj...

CitizenKane 11y ago
In terms of Single Page Application frameworks, Angular is very popular. Comparing it to jQuery doesn't really make sense as jQuery is a utility library and doesn't support all of the features that Angular has.
vkjv 11y ago
That's hardly a fair comparison. jQuery is a library and Angular is a framework. IIRC, Angular depends on (at least a subset) of jQuery, so it could only approach usage and never exceed.

vikingcaffiene 11y ago

> Problem #1: Scope inheritance and dynamic scoping Easily solved by using the controllerAs syntax > Problem #2: Dirty checking One time binding to the rescue here. Been available for a good while now. Dirty checking does suck though but is usually not a deal breaker. > Problem #3: Dependency injection The authors main problem here seems to be with problems minifying the code. All one needs to do is to pass in an annotations array which is an established best practice. So instead of controller('ControllerName', function($scope, $someService){}) one should use controller('ControllerName', ['$scope', '$someService', function($scope, $someService){}]) there are other more readable ways to do this such as $inject but I digress. > Problem #4: Pointless complexity This is debatable and more a matter of opinion. I disagree and think the glut of the authors woes come from not taking the time to understand the framework properly. The learning curve is steep yes but I've used a TON of javascript frameworks and Angular consistently comes out the winner long term in maintainability and stability. > Problem #5: Server-side rendering Isomorphic javascript to the rescue here. React does it better in this case but its available if you need it. Angular is a single page web app. If you knew that going in and have a problem with it now... well lets just say that its important to understand the trade offs that come with any technology one chooses to include in their stack. > Problem #6: Angular 2 Yes this was a concern, and then the angular team listened to the outcry from the community and now have been developing a migration path for users of the 1x code. They have also dedicated an entire team to continue development on the 1x codebase for as long as it remains popular thats why there are two angular websites. While I admit that angular isn't perfect (literally nothing is) nearly all of the authors criticisms are due to lack of following best practices. You can find a pretty good summation here: https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide

pwfisher 11y ago

Our company had two Angular codebases, the public site and our internal site. Experience in one taught you nothing about the other because there was no "Angular way" to structure your code. Having "enough rope to hang yourself" while our devs were just learning Angular led to an unholy mess. Development slowed to a painful crawl. We hate Angular. We're an Ember shop now. We love Ember! Angular gives you enough rope to hang yourself. Ember lets you stand on the shoulders of giants.

SonicSoul 11y ago
Interestingly I've heard similar sentiments from Ember developers, mainly that it is much more 'opinionated' than Angular. In my experience with Angular there is a pretty clear logic on how to structure code. I suppose that logic is not enforced so there is nothing to stop developers from just cramming all code into index.thml. Being a dev manager I've adopted feature structure [0] and it has worked quite well across all our apps. Furthermore there is pretty clear distinction on what kind of logic should be included in controller vs service vs factory vs module. This has made writing unit tests a breeze in my experience. I'd be curious to hear what Ember constructs exist that helped you so much. [0] http://www.johnpapa.net/angular-growth-structure/ http://www.johnpapa.net/angular-growth-structure/
- trophygeek 11y ago
  I'm a bit behind on this thread and I am an Angular guy myself, but I think Ember is moving this direction. http://www.programwitherik.com/ember-pods/ http://www.programwitherik.com/ember-pods/

spleenteo 11y ago

for the record: in the second paragraph we can find this sentence: > we’ve been working with Angular for almost nine months now (the original article in italian is dated February 2015) it means this post is just a translation of something experienced a year ago (Angular 1.1) A half of the comments reply to solutions arrived on 1.4, with hindsight. This delay is definitely not clear, but casts new light on the content.

choward 11y ago

This article is about 2 years late. These are solved problems in angular 2 by default and have solutions in angular 1. = Problem #1: Scope inheritance and dynamic scoping Use directive controllers = Problem #2: Dirty checking Use immutability = Problem #3: Dependency injection I'm not really sure what the author is saying here. It sounds like he's confused and thinks DI and modules solve the same problem. The one statement he has bolded is completely false: > Angular forces you to use a third, custom designed alternative mechanism: one that is inferior to the already existing mechanisms available. You can use a module system if you want. Nothing is stopping you. = Problem #4: Pointless complexity > providers, values, factories, services, constants [...] All five concepts could easily be assigned a single identity. True, so just use providers if that makes you happy. Angular 2 also simplifies things. = Problem #5: Server-side rendering He stated a solution for angular 1. Personally, I don't really care about server side rendering so I won't elaborate. Angular 2 will have angular-universal = Problem #6: Angular 2 > Not convinced yet? Well, what if we were to tell you that the next major version of Angular will take a scorched earth approach to the existing structure that means it will have zero retro-compatibility with what exists today? > it would be simply foolish to use Angular 1.x for new applications. LOL, fear mongering. The angular team has already stated there will be a migration path to angular 2. They also announced they will continue to support angular 1 as long as people are using it. It's funny that he complains about angular 2 when it addresses his problems with angular 1.

p3llinor3 11y ago
Oh! So just have a bunch of arcane design patterns instead of using the tools packaged with the framework! Sounds great...
juristr 11y ago
ah...finally, someone that gets it and says it aloud...if I would have found this comment before, I wouldn't have put mine further below. Thx!

gizi 11y ago

Angular is the answer to another question than the question that I usually face. So, the usability guy and the graphical designers have produced HTML/CSS page designs that work well and look good. The purpose of the javascript that I will be adding, is to make sure the user interface functions. Faced with these requirements, I have never been in a situation in which I felt that something like Angular would be able to contribute anything useful. If you drag Angular into the fray, it will be the most important kid in the room that you will need to constantly babysit. Forget about what you want to achieve. Think of Angular first. Everything else is unimportant ...

brightball 11y ago

Things like this reaffirm my old guy decision to do as little in the browser as humanly possible. EDIT: Warranted a downvote. Wow.

iridium127 11y ago

It's not worth obfuscating the web for what Angular brings to the table.

juristr 11y ago

Nowadays: want lots of traffic on your blog -> rant about Angular. The problem is just that you're nearly a year too late. - yep angular has flaws (which framework doesn't?) - ya, it does dirty checking and yes, that might have perf implications if used the wrong way. But hey, 6 years ago when Angular was created it was a revolutionizing idea, and still holds today. Also, at that time no Objecte.observe existed, nor did SPAs really (well..GWT was kinda the solution at that time). But, did u check what they're doing in Angular 2? Heard about RxJS and stuff? - DI: strange syntax techniques to work around minifiers? You don't really use those, do u? heard about ngAnnotate? - Oh...AMD, UMD etc...do not dependency injection. And yes, agree, DI together in combination with AMD/UMD/... creates confusion with newbie frontend developers - Then: Angular 2 is already live on GitHub, for a while; has even it's own webpage online - and for god's sake..Angular 2 is compatible with Angular 1...read their blog posts, their Tweets, weekly meetup notes and design docs (all openely available on GDocs) - oh..and there are even some rumors server-side rendering will be possible in ng 2 I like ur blog, but if you go and rant, please check the latest status, inform yourself, then rant. Nothing against critics, they foster discussion, but only if made properly.