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...
Having ported some Angular SPAs from 1.x to 2++ I have to say: Looked more painful at the onset, was actually quite easy in the end.
Having used React for some years now, I have to say: I wouldn't compare the two. React's atomic ecosystem is perfect if your stack of tools you embed doesn't grow too large.
However as soon as you want the feature set Angular provides out of the box IMHO you're screwed.
Objects and messages good, classes and inheritance mostly bad.
Except maybe for modelling/simulating concrete classes of objects (ie, as in Simula, the language).
Proper multiple dispatch (a la common lisp CLOS) seems rare - I'm guessing java/c++ seemed like a sane trade-off for some type safety - but they probably should've stuck to self/smalltalk (for Java) or looked to standard ml/common lisp (c++).
I still don't understand why Javascript got classes, rather than some paint on the prototype system.
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.
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.
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
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.
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.
Supporting a large 1.x codebase right now, and would love to start incrementally moving to angular.