Thanks, @r0bby, for raising this issue in a constructive way. It’s a valid question, and the situation is quite complicated.
Today, significant groups in the OpenMRS community are committed to Angular 1.x (e.g. Bahmni, PIH, and AMPATH) because it was basically the “best” javascript framework available ~3 years ago, when decisions where being made.
If we were starting from scratch today, we probably wouldn’t choose Angular 1.x, but we’re not in a green field situation. But it’s still a quite good technology, and it’s not limiting us today, so there is no burning need to move away from it preemptively.
Note that as a community we don’t have the resources to migrate our entire codebase to some other javascript framework. At the same time no web framework that was best of breed 5 years ago is still best of breed today, and the same pattern will hold true 5 years from now. So we do need to keep our tech stack evolving.
There a couple of things we are doing today that help us mitigate risks:
- The reference application is built out of independent parts, and it’s not a single monolith.
- Today Rafal is leading a sprint to build concept management screens as an OWA, that uses Angular 1.x.
- Suppose that a year from now we build a new set of patient summary screens in React or Ember…we won’t have to rewrite the concept management screens to do this.
- I’d further note that usage of AngularJS in the reference application is actually quite limited. E.g. the patient summary and visit dashboard screens don’t use it.
- Doubling down on REST and HTML(5).
- Pascal is starting to look at a framework-independent javascript library. I.e. this thread.
So, to your specific question of
What happens if Google halts support for Angular 1.x
…my answer is that we’ll deal with the specifics of this when (not if) it actually happens. But for now I would focus our efforts on the risk mitigation efforts above, rather than worrying about the exact upgrade path to Angular 2.x, which is still only in beta. (Thousands of people will be facing this in the coming years, including groups that are better-resourced and more dependent on Angular than we are. We don’t have to be the trailblazers on this particular issue.)