But this article is not Angular specific at all, it stays on a very high-level. Replace the word Angular with any other web framework and the article would still make perfect sense.
Not that the article does not have some value, just that it has very little to do with its title.
I disagree greatly. I've used Angular in a team project that spanned several months and went into production at a startup. After reading this article, I realize how much of my experience is reflected in it. I personally experienced each of the problems on his "bad parts" list, except for the name clashes issue (#3). For the last few months I've been telling people that Angular is powerful, but it has an extremely steep learning curve. I've been reluctant to tell people to try it because, why you can do a lot with it, you must baptize yourself in the framework before you can write anything half-decent. It's a little depressing to see someone with deeper experience come out and say it does not get better. But I know that as much as I want to like it, Angular imposes too much for me to actually recommend it.
So, this article is definitely not generic. Maybe, if you're reading at the bottom of the article, you can call it generic, because the advice for future projects is good. But otherwise, it's spot on. I can only hope that the Angular dev team sees this blog post and incorporates the recommendations into version 2.
Same opinion here. I think angular hit an inflection point on the js frameworks, proof is the rapid growth that angular had. Granted, there's some bad parts but I would say it's mostly leaky abstractions; I'm wondering how angular2 will be, but I surely don't understand why all the hate around angular.
It seems that the poster got bitten by some problems and blames it on angular. I recommend an exercise to current and future angular users: really try to understand HOW you would implement angular features such as two-way binding or modules or directives. If you do this you will understand that problems such as described by the poster in http://www.fse.guru/angular-bad-parts-part-3 are really due to his own misconception about what the framework should do and what it really does. I've been working with angular for two years and never had the problems that the poster reflects. I've had other problems but I would argue that for the most of it, I like the way angular is designed and like the compromises they took (mostly dirty checking to make two way binding work automagically).
None of the stuff that angular actually does is hard, and it is done by a lot of other frameworks. 90% of the effort spent learning angular is spent on its bizarre api.
that says it all: the most framework specific part of the article are the links in the end to other articles.
Its good to have feedback from the community, but I wish some of these posts would get down to the specifics, we would all benefit much more. Something like: "I tried to this (details) in Angular and it was difficult, tried to do it again with this other framework and it was much easier".
> that says it all: the most framework specific part of the article are the links in the end to other articles.
Having to click a link to reach the information you need, isn't a big deal IMHO. It's the content that should be discussed. Personally, I don't see anything wrong with posting links to prior (or other) blog posts.
NOTE: Haven't used AngularJS and only scraped the article. But Rails for example, doesn't have a namespace problem, because ruby modules provide a namespace and prevent name clashes easily.
That said, I'm not sure Rails and AngularJS are direct competitors as many apps use a combination of both frameworks or more generally Rails + JS-framework.
Rails and Angular are apples and oranges. Angular isn't a full-stack framework, it's a client-side framework that handles data source interfacing and view updating.
Rails doesn't have a namespace because Ruby has namespaces and Javascript doesn't - it'll be added in ES 6. Rather late, I think, but there you go. You can actually fake namespaces with Angular if you use a module framework like Require.js, but that involves adding more boilerplate to every module (like Angular 2.0 will actually require as well).
But this article is not Angular specific at all, it stays on a very high-level. Replace the word Angular with any other web framework and the article would still make perfect sense.
Not that the article does not have some value, just that it has very little to do with its title.