I'd agree that angular 2 was a letdown. Seems like most people are like me and like typescript, the cli, and a better router, but those could have been incrementally added instead of starting from scratch.

It still boggles my mind thinking about the massive amount of effort google's large team spent on ng2, library authors spend porting ng-bootstrap, plus every app that will be rewritten, plus the interim confusion of having 2 versions of libraries, documentation pages, etc. For improvements in some areas, more complexity in others. And I think to the point of the article, it feels far behind react in a lot of advanced development features as it is still trying to get a solid footing. Just saving a file and waiting a few seconds for a full page reload is much worse than the gulp then webpack browserupdate system I setup for ng1 apps, and the cli is not _that_ much better than a custom gulp task I setup to generate new components and services in ng1.

My theory is the primary motivation for ng2 came from the angular team not wanting to maintain a js and dart version of the library, so they wanted to move it to a single codebase that could compile from nativescript/typescript to both, and it was an easy sell to all the people who identify in the angular tribe.

Some specific things I don't like in ng2:

- Too many ways to do forms. Template driven vs reactive, with some things like mdAutocomplete I could only get working w/ reactive. You can do [ngModel] + name attribute, [ngModel]="name", [(ngModel)], formControl, formControlName. Little things like adding `Validators.required` isn't picked up by the view, so you have to specify required there too to get the little (*) asterisk in the view for mdInput

- Testing got much harder to do, with mocking every dependency. Just when ng1 made frontend unit testing pretty painless to do, it feels like a step back.

- The DI system in general feels like waaay too much complexity for the much smaller benefits it brings now that `import`s are available. I was reading the docs to try to figure out an equivalent to a factory function and I realized even if I could figure it out, another developer or myself in 6 months would not understand it. Mocking imports for testing would be good enough, I think.

- Unless you plan to be an "ng2 developer", dipping into the 100+ ;) rxJS observable methods is a good way to confuse your teammates or future self. Have fun remembering what mergeMapTo vs switchMap vs forkJoin do. Observables are cool, but imo another case of too much complexity and too many ways to do things for the benefits. I haven't seen good guidelines of at which point in your app do you transition from observables (returned from http request) to plain objects - should you pass observables down through components for things that can change, or rely on the component seeing its input property changed? Should I implement a snapshot property on my objects that can change, similar to how they do routes? It is silly to me an http request response is modeled as an unending sequence of events, instead of a promise. The only benefits I see like being able to specify `retry(3)` could be implemented as an option in your api service that wraps http, and would probably be more consistent that way.

- A lot of small things are gone, like a capitalize pipe, ngFor iterating over objects. A little slower when getting started on an app when you have to add them yourself. They got rid of things like http interceptors and route resolves, and are adding them back in now after people complain. Even stuff like adding a query param to a url required a bad java-like api and multiple lines of code. They improved that since, but why start w/ a step back from ng1?

- Speak of route resolves, they have gone from a simple 1 liner in the route definition to being a 10 line standalone service, which you have to import and add to your providers array.

- Hasn't been an issue for a while, but having your global ng-cli ...