Angular 2 Final Released

Angular's module syntax, while it makes sense, it's just easiest way to get version control merge conflicts. Even easier than import statements... since these can be put into oneliners.

We have been using Angular 2 seriously in the past month at my company.

There is a lot of roughness around currently when it came to upgrades during the RCs - Angular 2 was far from full-fledged even during the earlier ones, and has come a long way in the course of their development. Testing has a massive gap in documentation/articles on how to do it right. There are also some pains such as some (IMO somewhat poor) opinionation in the Angular router, especially when combining with server-side routing - had some battles integrating the Angular 2 app with the full server-side app for work, in large part due to hapi's major deficiencies when it comes to delegating routing to a frontend only application. Setting up can be daunting, although I got a large boost from using https://github.com/preboot/angular2-webpack, a great starter pack largely maintained by a member of the Angular docs team. Not all of the benefits are easy to tap into currently, such as the fairly recent AoT compilation, which lacks any plugin support for any build system such as Webpack currently. I intended to write one & open source it, but I was assured by a member of the Angular team that it was on the docket to complete. Documentation also needs a lot of work to be more developer friendly, I have found senior developers making easy mistakes with Angular 2 because they are not familiar with how to structure everything while having to produce on difficult story work. Testing is also a sore point, especially with the need for the karma shim to be produced for each app.

That said, Angular 2 is a phenomenal upgrade over Angular 1 in the ease of structuring apps. It also avoids incorrectly munging everything into components, avoids imperative logic to construct DOM/components, and imposes opinionation & more modern tooling such as the availability of observables to more correctly manage app state & app flow. It is fast, and much easier to tap into optimizations than Angular 1, where one had to be able to work close to the source code in order to understand everything one can and cannot do. It also offers the flexibility to do everything one can do with React, including server-side rendering (with the ability to do so on platforms such as PHP, Java, Node, and .Net in the pipeline), web workers, service workers, and multiplatform apps via React Native or NativeScript.

Can't wait for Angular 3!

You don't choose between those two routers, they are not replacements for each other.

At the risk of stating the obvious, the Angular router handles routing for the Angular frontend, the Go router handles routing for the Go backend (the initial page load, the AJAX calls made from Angular to get data...).

There seems to be a lot of advocacy for tossing everything into the component tree in the React ecosystem - recently I got linked to a snide remark by Ryan Florence on Twitter implicitly arguing for putting everything in the component tree, including constructs that should have a better separation such as routing (which the tweet appeared to be a reference to).

Some services don't belong in JSX though - this is why you have the idea of stores in Flux/Redux/etc. Some data doesn't make sense to couple to the component hierarchy - doing so makes it very easy to create dependencies on the component tree, which decreases modularity, as well as has perf ramifications by increasing the DOM elements that get rendered unnecessarily by React. Some examples are data models, routing, and interactions with non-element DOM api (window.location, XHR, etc.). This also has a side-effect of increasing difficulty of testing what generally should be vanilla constructs not tied to various frameworks/libraries unnecessarily.