Hacker News Reader

Comment by megaman22 | Hacker News Reader

What is the backwards compatibility and support model for Angular? I just don't have time to chase after things that move this quickly, not and fulfill all my other responsibilities. I'm supporting a mature application that has a front-end started less than eighteen months ago with AngularJS. Maintenance and support on third-party components we use is already starting to dry up. Rewriting things every six months is not reasonable for our team, much as we really ought to stay up to date.

I suppose we'll muddle along until things really break down, but this pace of change is not sustainable, particularly when so much of it just seems like churn for churn's sake.

View on HN

I'm not sure what you mean by "churn for churn's sake"?

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.

Angular 6 and all future main releases will be supported for 18 months.

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.

> Angular 6 and all future main releases will be supported for 18 months.

Does that mean that every 18 months you'd have to rewrite your app in the newer angular version? And if not, what does it mean?

"rewrite your app in the newest version" is more commonly known as upgrading... 18 months support seems fairly reasonable depending on how breaking new releases are.

Yes, due to the highly volatile JS landscape I was just trying to figure out what it means. So thanks

Don't know why I got downvoted but ok I guess.

They provide automatic upgrades that work on ASTs so lot's of upgrade refactoring is done automatically

Lts is a bad word in the js universe.

And they will tell you upgrade is painless, but it's still work. And then if you have many dependancies (and the npm culture is to make every single function a package...), one of them will be painful, another one will stop working, etc.

And now in this devops world, the same devs will do server maintenance. The next 10 years are going to be so fun to watch.

We recently began migrating a 4 year old and constantly growing angularjs 1.4 app to react. With angular2react and ngreact we don't face a lot of hard decisions, because we may use angular comps in react and vice versa. We have bootstrapped a angular 4/5 app at the same time, but react just feels right.

Vue feels much more like the natural successor to angular 1 than angular 6 or react are. The least ceremony to getting sh## done framework. React is just a view layer. You are going to have to pull in libraries for routing and state management (at least)

I spent 3 months evaluating all 3 with a poc app and vue was the clear winner for me

> You are going to have to pull in libraries for ... state management

There is nothing wrong with using setState()... You don't have to pull in Redux, which itself is like 100 LOC minus the sanity checks & comments.

well actually my company has a mixed Angular+AngularJS application. AngularJS really sucks compared to Angular. Angular is a extremely polished framework. However the size is a problem..

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.

Angular 2 came out in 2016. Why use angular 1 in 2017?

Legacy project? Migrating from AngularJS to Angular >= 2.x is not that easy if you build a framework arond AngularJS.

E.g. in my company we use AngularJS because of that.

You probably are not aware how many (rather big) projects out there are still on angular 1 with no upgrade plan at all. Last time I turned down a job offer because of a similar scenario.

Hi, xab9. Out of interest, why did you turn down a job because they are working with a framework version from 2016?

This was A1, which came out in 2010. I've spent two years using it, I know its strengths and weaknesses, there are just better offers out there.

It was 2016 when we started this front-end rewrite, away from a mess of jQuery and Razor view spaghetti. Angular 2 was brand new, without much support for third-party components we used, and AngularJS looked like the mature option. Probably should have bet the other horse, but c'est la vie.

We're in the middle of upgrading from Angular 1 to Angular 5 (probably now 6) - it's not that hard and I'd recommend doing it.

4 major version bumps in 2 years!!

What is "this pace of change"? Which parts are changing too quickly for you?

> 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?

Reply on news.ycombinator.com