Funny. If I had to point to one major failing of Angular, I'd say it's the structural directive syntax, which leads to ngIf and ngFor being much less ergonomic than the vuejs equivalents. The whole concept of a structural directive, with * being syntax suger around <ng-template> is confusing. I find this to be a big deal, because structural directives are very common / a fundamental building block of the framework. In general, I think structural directives incorrectly push too much logic into the view template (logic which would be better handled in javascript).
Conversely, I find dependency injection to be the single best feature of Angular. But this is why multiple frameworks exist: so some people can choose Vuejs or React, and others can choose Angular.
Yes I totally agree. I was writing the part about UI and logic seperation with a grain of salt because we still *ngIf and *ngFor in the template.
But yeah at the end of the day if your project doesn't have any extra special requirments, any framework will do. And it becomes a matter of which framework your engineers are comfortable with.
Agreed. It's just unusual for frontend developers. As Hatem said, backend background helps in understanding this amazing tool. It's pretty complex but is able to improve your app's modular achitecture drastically.
For instance I've used it to create a web analytics reporter. Its logic had to be different depending on from what URL user opened it. So I created an abstract class and injected it to components and services. When the app started, a factory function detected which implementation to use. That's it. Very clear architecture.
I mainly work on the back end. I understand DI has become a defacto standard in statically typed languages. However, I suffered from DI framework deeply after intensively writing and reviewing Spring or Guice based applications for many years. I saw how productivity gets impacted by overusing DI in many organizations. I'm not against DI pattern, but against the DI framework that brings complexity, magics, ceremonies, and bad practices. I even come out with an alternative solution regarding decoupling, customization, and testing. I call it Injectable Factory. You can take a look if you're interested.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
it's true. Dependency injection just introduces unnecessary complexity. It's killing angular.
By the way, I would also suggest you take a look at VueJS. It's nicely designed focused on developler simplicity.
Funny. If I had to point to one major failing of Angular, I'd say it's the structural directive syntax, which leads to
ngIfandngForbeing much less ergonomic than the vuejs equivalents. The whole concept of a structural directive, with*being syntax suger around<ng-template>is confusing. I find this to be a big deal, because structural directives are very common / a fundamental building block of the framework. In general, I think structural directives incorrectly push too much logic into the view template (logic which would be better handled in javascript).Conversely, I find dependency injection to be the single best feature of Angular. But this is why multiple frameworks exist: so some people can choose Vuejs or React, and others can choose Angular.
Yes I totally agree. I was writing the part about UI and logic seperation with a grain of salt because we still *ngIf and *ngFor in the template.
But yeah at the end of the day if your project doesn't have any extra special requirments, any framework will do. And it becomes a matter of which framework your engineers are comfortable with.
Dependency injection is a good thing. With it you can decouple the creation of a dependency from its usage. It comes very handy at unit testing also.
Agreed. It's just unusual for frontend developers. As Hatem said, backend background helps in understanding this amazing tool. It's pretty complex but is able to improve your app's modular achitecture drastically.
For instance I've used it to create a web analytics reporter. Its logic had to be different depending on from what URL user opened it. So I created an abstract class and injected it to components and services. When the app started, a factory function detected which implementation to use. That's it. Very clear architecture.
I mainly work on the back end. I understand DI has become a defacto standard in statically typed languages. However, I suffered from DI framework deeply after intensively writing and reviewing Spring or Guice based applications for many years. I saw how productivity gets impacted by overusing DI in many organizations. I'm not against DI pattern, but against the DI framework that brings complexity, magics, ceremonies, and bad practices. I even come out with an alternative solution regarding decoupling, customization, and testing. I call it Injectable Factory. You can take a look if you're interested.