4 ms·

I've worked on Angular projects of varying sizes -some as large as 30KLOC (products where every page has enough interaction to justify an Angular controller)- a

I've worked on Angular projects of varying sizes -some as large as 30KLOC (products where every page has enough interaction to justify an Angular controller)- and I can never find myself agreeing with these articles. Have I just drunk too much kool-aid? Or is it possible that with the right team, the right architecture, Angular can actually be a really great framework to use? The common theme for every large Angular project I've worked on is that the teams have leaned towards a more functional design where state is rarely used. This has always seemed to encourage smaller, decoupled modules which don't suffer from many of the problems that the author mentions. But hey, it's probably the kool-aid.

gadr90 12y ago
YES! Thank you! I think I'll die if I have to read another developer arrogantly defining what should and should not be, and how he, in all his glory, hereafter defines this framework to "NOT BE WORTHY". I can't stand how some articles simply s&*t on years of software architecture principles and the work of very talented engineers and simply dismisses them like it's nothing. If you disagree with a framework's perspective, AT LEAST be respectful. BTW, I also have used Angular for 2 years and, given the pros and cons and existing alternatives, I will choose it again for my next big project. The structure is simply too solid. This is invaluable when you have a large team that must work together.
- jasim 12y ago
  I am always conflicted about writing about Angular on a negative light because the team has put some great work into it while raising the bar in how rich apps could be built on the web. Being a back-end developer for a long time, it let me build some great interfaces on the front-end really quickly, and I'm very thankful for that. But we should also learn from where Angular succeeded and where it failed. Making XML declarative is fraught with difficulties. Things like ng-repeat are but a thin declarative veneer over the fundamentally imperative nature of constructing views. The biggest difference between most existing templating frameworks and React is in this world view: is the view constructed imperatively, or is it declared? The other question of contention is how much implicit magic should the framework supply vs how much explicitness the user should bring into the code. Angular's design decision is to make bindings work magically, while React identifies explicitness as a virtue. Having used both, I'm liking the imperative+explict camp.
  - gadr90 12y ago
    Finally, a respectful and well founded analysis. Thank you for improving the quality of the debate. My 2 cents: I actually prefer the declarative approach. My attempts at imperative view generation resulted in far more shooting-on-the-foot. Naturally, this is the very specific conclusions of me and my team, not the entire human race. I always think you should try both! Also, I'm a huge fan of Polymer, which is also very much declarative. Going to use Angular instead of Polymer simply because of better project structure and browser support.
- cmdkeen 12y ago
  The Angular 2 presentation given recently at ng-europe made it clear that many of the fundamental parts of 1.x are not built on solid architectural principles, which is why they are killing most of them off. I'd be interested to know how many of your large team were not experienced web developers before starting with Angular given that is one of the big criticisms in the article.
  - gadr90 12y ago
    My team has mixed people but most of them are reasonably experienced. What we find most useful about Angular is that it offers a "right way" to go about things, which removes the necessity for endless discussions about "which architecture is best". When you have a large amount of apps that need to be built and maintained concurrently, having a similiar structure across all projects is very helpful.
vitalybe 12y ago
I am on the same boat. I chose to use AngularJS in our team a year ago for quite a large web-app. It isn't perfect, but it is leagues ahead of whatever other choices I was and still aware of. Regarding the brought up problems, they indeed exist. I think the true fault of Angular is that it gives the impression easy and friendly, while it is really, nothing of the sort: "Come" it says, "Use my nice bindings. You don't need to worry, just bind all your data and will magically appear, no need to read the docs". Gladly you comply and all your data appears there. Magic. "I see you have a lot of objects", says Angular, "go ahead and use ng-repeat to show them all... They will all manifest by themselves, no need to write anything." So you do that too, and it works. Then a week later, when faced with real data in production, you have huge delays and the browser freezes for customers. "What have you done, Angular?" you shout angrily. "Now, now", it replies, "I thought you understood what you're doing, perhaps you should, after all, read all the docs, and maybe some blogs and videos about AngularJS performance tips, and of course, it is always suggested to read the source." P.S I haven't played too much with React yet and I should definitely do so.
huuu 12y ago
I think the keyword here is "state". A lot of bad code is written because people think they need to access (global) state all the time. Maybe you drunk too much good practice-aid ;)
- bsaul 12y ago
  Exactly. It seems to me that you can very well code the way react tells you to ( flux) in angular. Now it means you may not use two way data binding but the result will be probably much more undertstandable,

gadr90 12y ago

YES! Thank you! I think I'll die if I have to read another developer arrogantly defining what should and should not be, and how he, in all his glory, hereafter defines this framework to "NOT BE WORTHY". I can't stand how some articles simply s&*t on years of software architecture principles and the work of very talented engineers and simply dismisses them like it's nothing. If you disagree with a framework's perspective, AT LEAST be respectful. BTW, I also have used Angular for 2 years and, given the pros and cons and existing alternatives, I will choose it again for my next big project. The structure is simply too solid. This is invaluable when you have a large team that must work together.

jasim 12y ago
I am always conflicted about writing about Angular on a negative light because the team has put some great work into it while raising the bar in how rich apps could be built on the web. Being a back-end developer for a long time, it let me build some great interfaces on the front-end really quickly, and I'm very thankful for that. But we should also learn from where Angular succeeded and where it failed. Making XML declarative is fraught with difficulties. Things like ng-repeat are but a thin declarative veneer over the fundamentally imperative nature of constructing views. The biggest difference between most existing templating frameworks and React is in this world view: is the view constructed imperatively, or is it declared? The other question of contention is how much implicit magic should the framework supply vs how much explicitness the user should bring into the code. Angular's design decision is to make bindings work magically, while React identifies explicitness as a virtue. Having used both, I'm liking the imperative+explict camp.
- gadr90 12y ago
  Finally, a respectful and well founded analysis. Thank you for improving the quality of the debate. My 2 cents: I actually prefer the declarative approach. My attempts at imperative view generation resulted in far more shooting-on-the-foot. Naturally, this is the very specific conclusions of me and my team, not the entire human race. I always think you should try both! Also, I'm a huge fan of Polymer, which is also very much declarative. Going to use Angular instead of Polymer simply because of better project structure and browser support.
cmdkeen 12y ago
The Angular 2 presentation given recently at ng-europe made it clear that many of the fundamental parts of 1.x are not built on solid architectural principles, which is why they are killing most of them off. I'd be interested to know how many of your large team were not experienced web developers before starting with Angular given that is one of the big criticisms in the article.
- gadr90 12y ago
  My team has mixed people but most of them are reasonably experienced. What we find most useful about Angular is that it offers a "right way" to go about things, which removes the necessity for endless discussions about "which architecture is best". When you have a large amount of apps that need to be built and maintained concurrently, having a similiar structure across all projects is very helpful.

vitalybe 12y ago

I am on the same boat. I chose to use AngularJS in our team a year ago for quite a large web-app. It isn't perfect, but it is leagues ahead of whatever other choices I was and still aware of. Regarding the brought up problems, they indeed exist. I think the true fault of Angular is that it gives the impression easy and friendly, while it is really, nothing of the sort: "Come" it says, "Use my nice bindings. You don't need to worry, just bind all your data and will magically appear, no need to read the docs". Gladly you comply and all your data appears there. Magic. "I see you have a lot of objects", says Angular, "go ahead and use ng-repeat to show them all... They will all manifest by themselves, no need to write anything." So you do that too, and it works. Then a week later, when faced with real data in production, you have huge delays and the browser freezes for customers. "What have you done, Angular?" you shout angrily. "Now, now", it replies, "I thought you understood what you're doing, perhaps you should, after all, read all the docs, and maybe some blogs and videos about AngularJS performance tips, and of course, it is always suggested to read the source." P.S I haven't played too much with React yet and I should definitely do so.

huuu 12y ago

I think the keyword here is "state". A lot of bad code is written because people think they need to access (global) state all the time. Maybe you drunk too much good practice-aid ;)

bsaul 12y ago
Exactly. It seems to me that you can very well code the way react tells you to ( flux) in angular. Now it means you may not use two way data binding but the result will be probably much more undertstandable,