[kylecordes]

Getting from 1 to 2 was quite an experience. Much discussed here and elsewhere.

Thereafter though, they have been just relentlessly polishing, improving, smoothing rough edges, making bundle smaller, making compilation and execution faster, etc. It is really a model of exactly what you would want, in terms of a joint respect for backward compatibility with forward progress.

I don't understand the "haters" in some peer comments. There are certainly interesting things to consider in terms of feature and approach differences between Angular and its competitors. You could certainly find bits where a simpler approach taken by one of the competitors is a quicker learning curve and smaller size.

But at the same time Angular has a substantial feature footprint, it has significant swaths of functionality that the competitors don't address. We've been using (leveraging like crazy!) the Angular forms system. Many enterprise and non-enterprise applications have lots and lots of forms. Not forms in the trivial sense of, some controls on the screen. Complex interconnected behavior. Angular brings a lot to the table here.

[Bahamut]

Agreed - I have had a pretty pleasant experience with Angular in general, although it wasn't without its issues. Tests ran clearly slower than in AngularJS for example - the overhead in compiling TypeScript and setting it up is greater. Dynamically creating components was a painful experience for getting things done just right - I created a very flexible drag and drop module with it, I had to create some machinery on my own for performance reasons, namely for managing binding to document instead of repeated elements to avoid perf problems (there's an open issue I had filed in the past on that problem, I think it is still present). File size was larger than I liked as well, the initial load could be better IMO.

On the flip side, I have found I missed some things about Angular that I don't have with libraries like Ember and React - Angular has the superior testing story for ability to control granularity of testing without sacrificing architecture. Complicated pure functions can be tested with ease in Angular due to its injector, but painful in other scenarios because one cannot easily mock out dependencies so easily or requiring some fairly poorly documented/written about tricks. Managing state in Angular isn't really a difficult issue, and yet it becomes exacerbated in other ecosystems due to their delegation of tools to the community and each of the tools not providing good examples/documentation on blessed ways to wire them together, leaving a lot of dev shops with lesser solutions.

At this point, I see the major libraries/frameworks as having a set of more minor tradeoffs for devs to weigh - Angular, React, or whatever will get you where you want to be given the time/resources. With whatever is chosen for the view layer, you will be making time tradeoffs of where you'll spend more time when using Angular, or React, and you will create restrictions as a result. That said, it is perfectly possible to accomplish probably almost everyone's needs with Angular in a timely manner, and probably would be faster to initial market to get a moderately complex app than something like React IMO due to not needing to build certain types of boilerplate/refactoring as much due to lack of foresight about needing a particular system in place in the app.

Note: I have almost 5 years of experience with Angular, and currently have almost a half year of experience leading a very complex React project.

[kartickv]

So if I have no preference of my own, you'd suggest Angular over React? I want to get the product out soon and focus on generating business value rather than the framework itself.

[Bahamut]

All depends on your team - my current project is in React since it leveraged the team’s strengths/preferences in an optimal fashion. That calculus is different for different teams. I will say that it feels like using React demands more from the developers using it because it’s easier to create suboptimal abstractions, and we’re fortunate that we have developer talent that is much better than you get at most companies.