Angular 2 Rendering Architecture
docs.google.com
docs.google.com
I'm so glad I did not follow though with an Angular project about 2 years ago. It would have failed miserably and been difficult if not impossible to manage at this point.
Change is great, it makes awesome things happen. New frameworks are here to give you a choice, you don't have to use all of them. Angular2 will come with a lot of new features and Google said that they will keep working on Angular1 until most of the users switched, what's bad about that?
I launched a major internal admin a year ago with Angular and it's largely on autopilot because Angular is so darn easy to work with when it comes to building new features, especially in the view layer.
For example, if you change the data model behind an ng-repeat right now, Angular deletes the old element from the DOM and writes a new one. Angular 2, and React, will figure out that just the internal information of the element changed and it will just change that bit.
That said, it's only "basically React" in the sense that they both use a Virtual Dom. The implementation is unlikely to be as similar and the syntax is very different.
Your analogy is flawed in the same way that calling Linux "basically BSD" (or vice versa) is wrong simply because they both use a Unix-like kernel.
The previous architecture was excellent for its time. The initial release of Angular 1.x was 6 years ago. The praise was well-deserved because dirty checking was fast and efficient.
React came about 4 years later and used an architecture that no one else had ever used. It was faster and more efficient. Now frameworks are converging to the new faster and more efficient way.
It seems like you consider it a personal affront that Angular is changing with the times. You seem to forget that exchanging is what makes these frameworks great (CSSAnimationGroup is, in fact, a replica of ng-animate).
It's the same thing everywhere, so it is with React, Angular, Apple, Samsung, Microsoft, Google, ... People iterate (and meanwhile, they copy, improve and/or innovate stuff). The difference lies in how you are marketing it ;)
My probably mistaken impression is that Facebook did this with React, decided that even with this virtual DOM, Web apps just weren't worth doing except as a backup to "real" native apps, and abandoned it.
Then Google decided that Angular was the way to do Web apps, discovered they were doing it wrong and that Facebook's virtual DOM was the way to go, and abandoned Angular 1's approach for an approach tried and abandoned by Facebook.
Then Google moved on to Polymer and its HTML components approach, which might be fundamental to Angular 2 or might be a new approach that they intend to use with something other than Angular.
Again, I'm obviously confused about what's going on in this big players' next-gen client-side web app space. Could anyone clarify?
Angular is playing catch-up by adopting a similar rendering model. This will be to everyone's benefit.
Google is also pushing Polymer, but that's not really related to the other two.
What youre referring to is that the early FB IOS app essentially wrapped a webview in order to display its stream, but the webview performance at the time was atrocious and they quickly abandoned it for natively build components. More recently(2013), post Instagram acquisition, Facebook developed a virtual dom framework named react and its currently used in several places of their web app.
Similarly with Angular which was introduced ~5 years ago, they decided that for the new rewrite it makes sense to use a virtual-dom like technology at the render level. The change is evolutionary.
FWIW Polymer is an effort by a completely different team and at this point is independent of Angular.
Google did not "decide Angular was the way to do web apps". In fact relative few public-facing apps are built with Angular compared to other proprietary frameworks. Likewise, Google has not "moved on to Polymer", though most of those of us working on Chrome think Web Components are the way to go.