4 ms·

Angular markets itself as a tricycle but comes with a manual in which the first chapter after the introduction instructs you to swap out your wheels for jet eng

Angular markets itself as a tricycle but comes with a manual in which the first chapter after the introduction instructs you to swap out your wheels for jet engines. The learning curve and hidden complexity is absolutely insane and I would only recommend choosing Angular in extreme cases where you actually need to break the sound barrier. Source: I maintain a complex Angular SPA since AngularJS/2.

r0b05 4y ago
Can you elaborate on some of your challenges please? I find it quite straight forward to use once you overcome the somewhat steep learning curve.
- zkirill 4y ago
  Sure, the following challenges come to mind: * Must maintain a deep understanding of RxJS, which is its own beast. Angular team sometimes uses it in "creative" ways that change between versions in creative ways. * Must not go off reservation (or do) where the Angular code is committed but not covered by documentation (because reasons). Template variables (hack an ngIf into an ngVar) come to mind, as well as how not subclass an abstract component (e.g. abstract component can technically have its own template and interesting things happen when children also have their own templates). * Must understand how Angular i18n works by inspecting various Angular code repositories (and sometimes having to build the Angular project yourself, inadvertently discovering the "wonders" of Bazel). For example, the list of Angular supported locales is generated from CLDR dumps. CLDR likes to release new dumps and so the list of Angular supported locales changes (sometimes). You can think of interview Angular questions from hell such as what is the default build locale and what happens if you change it to "en-US-POSIX"? Or, my current favorite, how to ask Angular put dir="rtl" into the generated index.html for locales that are RTL? These are just off the top of my head. I didn't even go into various performance optimization techniques which may or may not be made redundant by the next version of Angular because of their own compiler optimizations. Also, having to make the decision of the E2E testing solution (or sticking with Protractor).
  - r0b05 4y ago
    While I do agree with you, I must admit that some of these reasons could be subjective. That being said, Angular has its share of issues. However, I find the overall developer experience to be good and I usually find the code to be well organized in projects.
snapdaddy 4y ago
Yeah, this description doesn't sit with me very well, either. I fully support the argument that Angular is not a good choice because React is more popular and has a larger pool of developers, but not that it is more complex. I too would like to hear about what complexities you are encountering and if they are incidental or necessary complexities.
- wokwokwok 4y ago
  ? This reads like too much cool aid. Angular is an entirely application stack, “choices made for you”. uses dependency injection out of the box, has a complex module system (eg. How you used to have import Material components one by one). It’s observables all the way down. How can you argue that’s not complex? It’s super complex. I mean, let’s just take an example, say, making a library… https://angular.io/guide/creating-libraries https://angular.io/guide/creating-libraries Now let’s look at https://kit.svelte.dev/docs/packaging https://kit.svelte.dev/docs/packaging Quite the difference. I’m a modest fan of angular because it produces good stuff… but not because it’s simple or easy to learn. You get good solid engineering outcomes with it.

r0b05 4y ago

Can you elaborate on some of your challenges please? I find it quite straight forward to use once you overcome the somewhat steep learning curve.

zkirill 4y ago
Sure, the following challenges come to mind: * Must maintain a deep understanding of RxJS, which is its own beast. Angular team sometimes uses it in "creative" ways that change between versions in creative ways. * Must not go off reservation (or do) where the Angular code is committed but not covered by documentation (because reasons). Template variables (hack an ngIf into an ngVar) come to mind, as well as how not subclass an abstract component (e.g. abstract component can technically have its own template and interesting things happen when children also have their own templates). * Must understand how Angular i18n works by inspecting various Angular code repositories (and sometimes having to build the Angular project yourself, inadvertently discovering the "wonders" of Bazel). For example, the list of Angular supported locales is generated from CLDR dumps. CLDR likes to release new dumps and so the list of Angular supported locales changes (sometimes). You can think of interview Angular questions from hell such as what is the default build locale and what happens if you change it to "en-US-POSIX"? Or, my current favorite, how to ask Angular put dir="rtl" into the generated index.html for locales that are RTL? These are just off the top of my head. I didn't even go into various performance optimization techniques which may or may not be made redundant by the next version of Angular because of their own compiler optimizations. Also, having to make the decision of the E2E testing solution (or sticking with Protractor).
- r0b05 4y ago
  While I do agree with you, I must admit that some of these reasons could be subjective. That being said, Angular has its share of issues. However, I find the overall developer experience to be good and I usually find the code to be well organized in projects.

snapdaddy 4y ago

Yeah, this description doesn't sit with me very well, either. I fully support the argument that Angular is not a good choice because React is more popular and has a larger pool of developers, but not that it is more complex. I too would like to hear about what complexities you are encountering and if they are incidental or necessary complexities.

wokwokwok 4y ago
? This reads like too much cool aid. Angular is an entirely application stack, “choices made for you”. uses dependency injection out of the box, has a complex module system (eg. How you used to have import Material components one by one). It’s observables all the way down. How can you argue that’s not complex? It’s super complex. I mean, let’s just take an example, say, making a library… https://angular.io/guide/creating-libraries https://angular.io/guide/creating-libraries Now let’s look at https://kit.svelte.dev/docs/packaging https://kit.svelte.dev/docs/packaging Quite the difference. I’m a modest fan of angular because it produces good stuff… but not because it’s simple or easy to learn. You get good solid engineering outcomes with it.