|
In my opinion, yes. Angular's model is based on "two-way data binding", which was also the paradigm used by Backbone and other popular JS frameworks of a ~decade ago. This means that any user interaction with your app directly causes some JavaScript value to change, potentially triggering side-effects. But you can also cause the same value to change in your business logic code, in response to some other event or change. Components maintain a lot of data internally, so your job as a developer is largely about making sure that these components stay in sync with each other, and with whatever non-component-oriented data you have. This gets messy very quickly. Where is your data? What things can cause your data to change? What happens if you want to change a data schema, or introduce new fields, new components? Angular tries to solve this problem with a fairly complex architecture[1] which promises that all of this can be OK if you follow the rules. The problem is that this architecture is so complex that most people can't follow it well: there are modules, components, views, directives, services, dependency injection containers, service metadata, bindings, a router, and events. That's ten concepts, and you can't build very much in Angular without knowing what those concepts are and how they relate to each other (and if you can build it without knowing these things, then you didn't need Angular). React is much simpler: there is state, and there are views. State can be global or component-local, and I would suggest ignoring component-local state unless you can't avoid it. Views render whatever state is passed to them. State can be updated by events. This is the same basic loop that is recognisable in desktop apps, games, in fact most interactive software. There's no "two-way binding" because views render based on state, but can't modify it directly. This is a lot easier to understand and to debug. React might be less "batteries included" than Angular, but Angular requires such an enormous battery pack because it is trying to solve problems in an insanely complicated way. [1] https://angular.io/guide/architecture |