I recently wrote about my experience with Angular in a different forum. Sharing it here: I worked on Angular last year building an app with a few complex views

I recently wrote about my experience with Angular in a different forum. Sharing it here: I worked on Angular last year building an app with a few complex views. The initial days were full of glory. Data-binding was new to me, which produced much goodwill towards the framework. Things started falling apart as I had to inevitably understand the framework in a little more depth. They practically wrote a programming language in the bid to create declarative templates which knows about the Javascript objects they bind to. There is a hand-rolled expression parser (https://github.com/angular/angular.js/blob/v1.2.x/src/ng/parse.js https://github.com/angular/angular.js/blob/v1.2.x/src/ng/par...), new scoping rules to learn, and words like transclusion and isolate scope, and stuff like $compile vs $link. There is a small cottage industry of blogs explaining how Angular directives work (https://docs.angularjs.org/guide/directive https://docs.angularjs.org/guide/directive). The unfortunate thing is that all of Angular is built on directives (ng-repeat, ng-model etc.); so till one understands it in depth, we remain ignorant consumers of the API with only a fuzzy idea of the magic beneath, which there is a lot of. The worst however was when we started running into performance problems trying to render large tables. Angular runs a $digest cycle whenever anything interesting happens (mouse move, window scroll, ..). $digest runs a dirty check over all the data bound to $scope and updates views as necessary. Which means after about 8k-10k bindings, everything starts to crawl to a halt. There is a definite cap on the number of bindings that you can use with Angular. The ways around it are to do one-time binding (the data won't be updated if it changes after the initial render), infinite scrolling and simply not rendering too much data. The problem is compounded by the fact that bindings are everywhere - even string interpolation like `{{startDate}} - {{endDate}}` produce two bindings. Bindings are Angular's fundamental abstraction, and having to worry about its use due to performance issues seems quite limiting. Amidst all this, React feels like a breath of fresh air. I've written a post about what makes it attractive to me here: http://www.jasimabasheer.com/posts/on-react.html http://www.jasimabasheer.com/posts/on-react.html. Compared to Ember, neither Angular nor React dictate as rigorous an organization of files and namespaces (routes, controllers, views), and have little mandatory conventions to follow. But React is as much a framework as Angular is. The event loop is controlled by the framework in the case of both, and they dictate a certain way of writing templates and building view objects. They can however be constrained to parts of the app, and so can play well with both SPA and non-SPA apps. The data models are plain Javascript objects in both (it is not in Ember), which is really nice. Google recently released a new version of their developer console (https://console.developers.google.com https://console.developers.google.com) which is built on Angular. So the company is definitely putting their weight behind the framework. However, Angular 2 is not at all backwards compatible. That was quite unexpected. If I had known this going in, I would have never used it for the project. But it felt like such a good idea at the time...