5 ms·

Is there still a clear path from angularjs 1.x onto angular 9.0? Anyone done it recently? Supporting a large 1.x codebase right now, and would love to start in

Is there still a clear path from angularjs 1.x onto angular 9.0? Anyone done it recently? Supporting a large 1.x codebase right now, and would love to start incrementally moving to angular.

rawoke083600 7y ago
No there is no way to go from a donkey-cart to the Star ship USS Enterprise in a incremental way while still travelling forward. I've also had to do it. Just start from scratch. I'm a lot more productive with A6+ than I was with AJS
- vikingcaffiene 7y ago
  In addition to being completely accurate, this is one of the funniest things I've read on this site in a long time. Thanks for the laugh.
doitLP 7y ago
They are wholly incompatible. The choice of the Angular name for this new framework was just marketing, beyond some similar design choices. Probably there are better ways now but here’s how I did it: * Determine exactly how moving to a new framework will benefit your users. If it doesn’t, why are you doing it? It is going to be a lot of hard work and your users will not care you’re on a new framework. * evaluate if Angular really is the right choice to upgrade to * if it is, do not mix the code in one repo. Use two repos. * Migrate route by route, starting with lowest impact pages first. When user clicks on the route served by the new angular page it will point to the new app * to support this, you’ll need to build out foundational modules critical for the switching to happen, e.g. auth, common header, footer, menus etc * how the switch happens between routes is up to how your app is served. You will need to configure the domain to stay the same between serving the different apps. * update your deployment and testing strategies to account for two apps going out instead of one. * we took a bell curve approach, lowest impact routes first, then peaked with critical routes, then back to less and less important pages. This allowed a gradual ramp up to work out the kinks but at some point you will need to get your most important stuff moved over so you’re not building two systems. * get buy-in from stakeholders that this migration is going to add value for users. Get them excited so you are working together to get it all moved over. * allocate x% of Dev time to the transition. * agree on a date for each route and for the full transition so work can be prioritized. I’m sure there’s loads of blogs with more specifics. Just wanted to share my experience at a high level.
_bxg1 7y ago
I think they had an official migration utility to help with going from 1.x to 2.0, since it was basically a total rewrite. I think the major versions after that have been more incremental, though eight at once might still be rough.
filoeleven 7y ago
AFAICT the upgrade path is still the same (0) and...it looked pretty painful when I first looked at moving from 1.x to 2. I maintain a sizable 1.x codebase and am deciding what to move to, since 1.x is dead next year. I just don’t see a good reason to go to 2+. It’s a different framework. All of the UI libraries we built upon (ng-grid, angular-ui) are either gone or different enough that we will have to redo all of our code no matter what. If I have to switch frameworks anyway, I want to go with something simpler (no custom module nonsense, no annotations, no hierarchical dependency injectors, hell, no classes!) with a healthy ecosystem. React with hooks, bootstrapped with CRA, is the clear winner for me. It’s just so much more straightforward to reason about, and way faster to build things with too. I made a toy app in Angular a year ago to check it out, and had a hell of a time even getting the simple data model working right. With React, day two had me already wiring up a dashboard with charted details that responded to a calendar widget I had customized to show QoS at a glance. I was looking at Vue too before I read up on react hooks, but once I saw functional components everywhere I was...erm...hooked. Sorry. Now if only I can convince them to let me use ClojureScript... (0) https://angular.io/guide/upgrade#using-a-module-loader https://angular.io/guide/upgrade#using-a-module-loader
- ErikAugust 7y ago
  AngularJS is dead next year, but really that doesn't stop you from using it indefinitely. Of course it can be fun to rewrite everything.
  - filoeleven 7y ago
    Google declaring end of support is enough to make us have to move. Banks are kinda picky about security updates. We’ve had a bunch of long-standing state management bugs and performance issues too ($watches, $watches everywhere, nor any prop’s in sync) that we built a lot of cruft around trying to fix, mostly due to two-way binding and our weird use case. Some were unfixable due to the framework and others due to bad early decisions. But This Time!! It will definitely be fun to rewrite. The app is so much like a web-based dumb terminal that a view-layer library like React was probably always a better fit for us, had we known about it when we started the project. Plus the JS ecosystem is a lot nicer now: arg destructuring and VS Code’s intellisense thanks to es6 imports are both big productivity wins. Also, not having to maintain a gulpfile is its own blessing.
myoon 7y ago
The path provided is being able to load Angular 9 components into AngularJS components relatively seamlessly. This is helpful, but it's almost certainly a big leap to get your codebase compiling under angular-cli. If you manage it though, you can, in theory, do a bottom-up replacement of all your AngularJS components. Another thing to think about though is how you're currently doing state management. Angular 9 is all about RxJS, and if you're currently managing state without it, your migration will be that much harder.

Is there still a clear path from angularjs 1.x onto angular 9.0? Anyone done it recently? Supporting a large 1.x codebase right now, and would love to start incrementally moving to angular.

rawoke083600 7y ago

No there is no way to go from a donkey-cart to the Star ship USS Enterprise in a incremental way while still travelling forward. I've also had to do it. Just start from scratch. I'm a lot more productive with A6+ than I was with AJS

vikingcaffiene 7y ago
In addition to being completely accurate, this is one of the funniest things I've read on this site in a long time. Thanks for the laugh.

doitLP 7y ago

They are wholly incompatible. The choice of the Angular name for this new framework was just marketing, beyond some similar design choices. Probably there are better ways now but here’s how I did it: * Determine exactly how moving to a new framework will benefit your users. If it doesn’t, why are you doing it? It is going to be a lot of hard work and your users will not care you’re on a new framework. * evaluate if Angular really is the right choice to upgrade to * if it is, do not mix the code in one repo. Use two repos. * Migrate route by route, starting with lowest impact pages first. When user clicks on the route served by the new angular page it will point to the new app * to support this, you’ll need to build out foundational modules critical for the switching to happen, e.g. auth, common header, footer, menus etc * how the switch happens between routes is up to how your app is served. You will need to configure the domain to stay the same between serving the different apps. * update your deployment and testing strategies to account for two apps going out instead of one. * we took a bell curve approach, lowest impact routes first, then peaked with critical routes, then back to less and less important pages. This allowed a gradual ramp up to work out the kinks but at some point you will need to get your most important stuff moved over so you’re not building two systems. * get buy-in from stakeholders that this migration is going to add value for users. Get them excited so you are working together to get it all moved over. * allocate x% of Dev time to the transition. * agree on a date for each route and for the full transition so work can be prioritized. I’m sure there’s loads of blogs with more specifics. Just wanted to share my experience at a high level.

_bxg1 7y ago

I think they had an official migration utility to help with going from 1.x to 2.0, since it was basically a total rewrite. I think the major versions after that have been more incremental, though eight at once might still be rough.

filoeleven 7y ago

AFAICT the upgrade path is still the same (0) and...it looked pretty painful when I first looked at moving from 1.x to 2. I maintain a sizable 1.x codebase and am deciding what to move to, since 1.x is dead next year. I just don’t see a good reason to go to 2+. It’s a different framework. All of the UI libraries we built upon (ng-grid, angular-ui) are either gone or different enough that we will have to redo all of our code no matter what. If I have to switch frameworks anyway, I want to go with something simpler (no custom module nonsense, no annotations, no hierarchical dependency injectors, hell, no classes!) with a healthy ecosystem. React with hooks, bootstrapped with CRA, is the clear winner for me. It’s just so much more straightforward to reason about, and way faster to build things with too. I made a toy app in Angular a year ago to check it out, and had a hell of a time even getting the simple data model working right. With React, day two had me already wiring up a dashboard with charted details that responded to a calendar widget I had customized to show QoS at a glance. I was looking at Vue too before I read up on react hooks, but once I saw functional components everywhere I was...erm...hooked. Sorry. Now if only I can convince them to let me use ClojureScript... (0) https://angular.io/guide/upgrade#using-a-module-loader https://angular.io/guide/upgrade#using-a-module-loader

ErikAugust 7y ago
AngularJS is dead next year, but really that doesn't stop you from using it indefinitely. Of course it can be fun to rewrite everything.
- filoeleven 7y ago
  Google declaring end of support is enough to make us have to move. Banks are kinda picky about security updates. We’ve had a bunch of long-standing state management bugs and performance issues too ($watches, $watches everywhere, nor any prop’s in sync) that we built a lot of cruft around trying to fix, mostly due to two-way binding and our weird use case. Some were unfixable due to the framework and others due to bad early decisions. But This Time!! It will definitely be fun to rewrite. The app is so much like a web-based dumb terminal that a view-layer library like React was probably always a better fit for us, had we known about it when we started the project. Plus the JS ecosystem is a lot nicer now: arg destructuring and VS Code’s intellisense thanks to es6 imports are both big productivity wins. Also, not having to maintain a gulpfile is its own blessing.

myoon 7y ago

The path provided is being able to load Angular 9 components into AngularJS components relatively seamlessly. This is helpful, but it's almost certainly a big leap to get your codebase compiling under angular-cli. If you manage it though, you can, in theory, do a bottom-up replacement of all your AngularJS components. Another thing to think about though is how you're currently doing state management. Angular 9 is all about RxJS, and if you're currently managing state without it, your migration will be that much harder.