(TBH Angular1 was pretty great at the time, but after React I look back at those monstrous template files, ng-everything, plugins and workarounds, and only the bad memories surface).

Sure I should have checked it out but the documentation didn't exactly highlight it (at the time anyway), and with the services, controllers, testability, etc it just looked like they'd thought it all through.

Frankly after finding React there's no way I'm giving NG2 even a look in.

At the time it was compared to jQuery spaghetti code and Backbone with a little less jQuery spaghetti code.

It brought front-end web frameworks to the masses.

Granted I think they should've started Angular 2.0 a year earlier, but it was great at the time. Sadly is has aged very poorly.

In the last 4 months I've built a large angular1.5 app in ES5 using the new component facade and d3.js, and it's been pretty smooth.

Two of the main problems I had with angular - the template syntax and the way the digest cycle worked, both contributed to its scaling factor.

The template syntax meant you would always wonder what a parameter meant when passed to a directive. Essentially, all parameters passed to a directive were strings, but angular would parse some strings to mean "the property of a parent scope", and some more convoluted variations of that(check out https://docs.angularjs.org/api/ng/service/$compile#-scope-). Furthermore, using the recommended ng-controller directive created great spaghetti code, with template blobs where the current scope is almost impossible to track. Applying multiple directives to the same element sometimes required special parameter parsing, which further made the situation confusing. This confusion meant the more stuff you had, the more time you had to spend carefully memorizing it all so you knew what was going on.

The digest cycle fundamentally limits angular's scale. It was designed with some scale in mind at first - a digest cycle triggered at a specific scope would only run watchers under that scope, thus limiting the effect. I assume they hit the problem that there was no way to define explicitly "global" watchers, or to tell another scope to update itself. This issue apparently crept into the development of angular and local digests were pretty much abandoned in favor of using scope.$apply(), which triggers a digest cycle at the topmost scope. Local digests were not really talked about in the documentation, which was littered with examples of scope.$apply(), all of angular's provided directives used scope.$apply() and pretty much no one wrote any code limiting the amount of watchers triggered in an update. React specifically addressed this point with shouldComponentUpdate and the ecosystem built around it, which is one of its biggest performance benefits.

Further criticism would be the terminology confusion. Angular talked about directives, modules, controllers, filters, services, factories, providers, etc.

In essence, providers/factories/services were all just singletons instantiated in different ways(providers being the progenitor and factories/services being variations).

Filters were poorly named, as they were actually mapping functions or value formatters. Thus came the infamous "filter filter", which filtered elements in a collection, as opposed to say the "currency filter", which added currency markers to numbers. They were also incredibly inefficient, running on every digest cycle, even after the attempted fixes with "stateless filters"(http://www.bennadel.com/blog/2766-stateless-filters-don-t-ap...)

Controllers were essentially stunted directives, provided via the ng-controller directive. They were paraded as the way to start "simple" development, but led to a lot of bikeshedding about where to use controllers and where directives, the confusion around directives requiring controllers and the limitations around that, how to appropriately bind directive parameters to a controller's "scope"(not an actual scope but the controller function object itself), the bindToController function resolving that problem(introduced in 1.4?), etc, etc.

Modules were also a weird concept without much practical use. They do not provide a separate namespace(all your angular elements go into the same one), they don't leverage angular tooling to import your code(you have to import your code manually e.g. add script tags). Mostly they provided the config() and run() functions which would let you schedule code to be executed on-load.

I could go on and on about the confusion that angular's terminology caused, the microsyntax in its expressions and how interpolation worked, the scoping inheritance issues around directives and the subsequent overuse of isolate scope to avoid them, transclusion and how it affected scope inheritance(which led to articles like this one - http://angular-tips.com/blog/2014/03/transclusion-and-scopes...), the massive problems with there being no real directive lifecycle hooks you could use...it usually took a monumental effort to avoid all the traps and pitfalls of angular on any larger project.

That doesn't make angular necessarily a terrible framework, because it did enable some productivity when being fairly rigourous when using it. That rigour was developed by the community as it struggled to understand all the concepts thrown at you, but it certainly didn't come easy, and I'm not sure it became really widespread. This severely crippled "developer scale" for me, and the performance issues of watchers/filters worked against "performance scale".

Sadly I'm stuck having to deal with it, and I can honestly say I hate it and it makes me want to cry. Might have to do with the way it was used, though. I find myself having to write a directive each time I have to populate a fucking select2.

I tried React but I hit a wall of needing synchronisation, routing, notifications, can you do that now?

The way I dealt (until proper type definitions are written) was:

declare module "react-loader" { var noTypeInfoYet: any; export = noTypeInfoYet; }