Version 6 of Angular Now Available (blog.angular.io)

No one using React uses them. Google can't break free of old Java habits.

This article had more on it https://blog.ninja-squad.com/2018/05/04/what-is-new-angular-...

As for backwards compatibility, as was described in the presentation on the new renderer they are working on, 600 apps at Google are built on Angular, so there is a great deal of internal pressure to make sure backwards compatibility is a constant consideration.

Along those lines, one of the big tooling features in this release is the upgrade command in the CLI, which can allow packages to self update themselves across your codebase (i.e. if there's a breaking API change, they can rewrite that API call accordingly automatically during package upgrades). This is new, so it's yet to be determined how common and painless the usage will be.

The AngularJS to Angular upgrade step is a big one. But, the latter is unquestionably a better framework once you're using it. It only needs to be done once, and it can be done gradually, if you're willing to ship both frameworks for a while. The upgrade modules they provide for running AngularJS code in Angular (and vice-versa) were a bit dodgy at first, but they are excellent now.

Once you're on Angular, there's no need for any 6-month rewrites. We upgraded about a year and a half ago, and we've kept up to date without facing any problems with backwards incompatible changes or upgrade pain. The Angular team has done a lot of work on improving the framework's internals, but the actual conceptual model and interfaces have remained stable.

Plus, if you use Angular CLI, you're also isolated from churn in the build tool world. You don't have to worry about juggling compatible versions of Webpack and its myriad loaders and plugins. It's all hidden away. Having wasted far too many hours of my life hacking on Grunt, then Gulp, then Webpack configs, that's reason enough to use Angular for me.

Currently upgrading from 5 to 6 was simple. We didn't need to upgrade 'angular' code. (we just used https://update.angular.io/) basically took me two hours (replacing all rxjs code) (code base is 35k lines of typescript and 14k lohtml)

The biggest pain between 5 and 6 is basically rxjs not angular per se and for that there is rxjs-compat. However the only problem with angular would've been if people would've used the old Http Client, however we started with 4 and directly used 'HttpClient' which also is way better since you can easily have interceptors around it.

> Rewriting things every six months is not reasonable for our team

I'm not sure why you think you'd need to rewrite things. Where are you getting your information?

That said, there are some interesting implied ambitions for Angular. The AngularDart project, the Bezel project, the AngularCompiler more generally as a point of special focus...

The core of the React render model is beautiful. It's far quicker to start writing and using a new component in React than in Angular, and the functional nature of React components feels good and highly productive. At first.

But the problem is, around that beautiful core, the React community has built a mass of libraries, meta-frameworks, techniques and practices that are decidedly less beautiful. After a while, I really found myself missing features from Angular, and struggling to replicate them by wiring together a hodge-podge React++ framework. Instead of being productive, I was wasting an inordinate amount of time trying to discover what the current micro-framework de-jour was for handling a particular problem in React.

For example, Angular supports view encapsulation. So you can write CSS targeting a component, and the framework will ensure that the style rules you write apply only to the HTML rendered by that components, without leaking to other parts of the app. This really is a godsend for properly isolating components in a reusable way. With React, there's a myriad of libraries for doing CSS, but most seem to be abandoned, and none seem to offer as straightforward or as easy style encapsulation as what Angular provides out of the box.

It was a similar story with forms. Which are a rich, reactive API in Angular, but seem to be an afterthought in React. And with dependency injection, both of singleton services and components elsewhere in the hierarchy.

I expect if you go all in on Redux, you can eventually build up a reasonable facsimile of what Angular provides. But from a standing start I think Angular is a much more productive framework, just because it's actually trying to be a framework, whereas React seems to be stuck somewhere between being a UI library and a framework, leaving the community to somewhat badly fill in the gaps.

This is an interesting comment to me because, by essentially building your own framework, that onus is now completely on you. If you want to implement code splitting or tree shaking or whatever, you have to figure that out for yourself. That's time taken away from building product features. Whereas other frameworks can offer this out of the box because smart people in the open source community have figured that all out for you.

In addition, no one coming into your organisation has any continuity of knowledge, so they have to learn all the proprietary ways your app is set up, which is more time lost.

Actually with angular-hybrid you do not need to use a AngularJS entryComponent. The only thing that needs to be AngularJS is the bootstrap component.

Also AngularJS components can be Upgraded easily and Angular2+ Components can be downgraded easily, too. The only problems are old school Directives which can be wrapped in a component for interop or just rewritten.

You can even remove angular-hybrid when you just "upgrade" all your AngularJS code that is used in routes. (you still need to have a AngularJS rootElement and than inject a downgraded ui-view).

i.e. you can't have `bootstrap: [UIView]` however using `<root-element></root-element>` in your index.html while root element is like that:

`.component('rootElement', {template: '<ui-view></ui-view>'})`

It sucks to create AngularJS wrapper components in Angular since you need to create two, i.e. from AngularJS component:

    ng1module.component('demo', {template: 'hase'});

    @Directive({selector: 'demo-shim'})
    export class DemoShimDirective extends UpgradeComponent {
    @Input() text: string;
    // upgrade constructor with super call
    }

    @Component({selector: 'demo', template: '<demo-shim [text]="text"></demo-shim>'})
    export class DemoComponent {}

In my experience centralisation and fixation on specific technology leads to stagnation quickly. IMO you should allow teams to choose their own tools. How else will you improve?