What happens if Google halts support for Angular 1.x?

Development
1

I know I’ve made my personal opinions on AngularJS known, but I wanted to raise a valid question we need to ask as a community:

Currently, we use Angular 1.x and we should be (at least considering) migrating that code to Angular 2.x. What are our plans if Google decides to say that they will no longer support Angular 1.x?

That migration strategy makes me uneasy moreso than the framework itself.

2

I guess the same thing everyone does when version X of a piece of software goes out of date. Upgrade? :slight_smile:

3

Yes, but only recently did they even make the path clear.

4

Does this outline for us a path forward?

3 Likes
5

Sure, it may not be easy, but it’s not impossible. I’m not defending Angular, and it’s something that we should definitely think about, but it could happen to any framework.

1 Like
6

We should also be migrating out code to ES6 entirely and maybe standardize on the airbnb style guide

7

@r0bby you remind me of when i heavily invested in GWT and then Google abandoned it. :smile:

2 Likes
8

@darius, I do apologize for constantly bashing Angular – it’s bad – I know. But I’m trying to make this as constructive as I can :slight_smile:

9

It’s not bad if you provide arguments :slight_smile:

I recently saw a video from Matt Raible (web frameworks guru) comparing Angular, Ember and React, very interesting. I really want to learn some but not sure which one :frowning:

1 Like
10

To Robby’s point, this is why personally tend to be hesitant to jump onto new JS technologies, most of them get abandoned soon or later and I see the same happening for angular. I like Jquery because it has been around for a while.

2 Likes
11

But jQuery is a library, not a framework. A framework forces you to do things in a certain way.

2 Likes
12

I just meant to mention JQuery as an example of a library that has lasted and not as an alternative to angular

1 Like
13

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:

  1. 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.
  1. Doubling down on REST and HTML(5).
  2. 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.)

5 Likes
14

Well said @darius :heart:

15

I think another important risk-mitigation step will be ensuring that whatever is written is done so in a component-oriented as opposed to controller-oriented design. It might be worth investigating/incorporating things like https://github.com/ngUpgraders/ng-forward. Even if not going that far toward Angular 2, practices like this: http://teropa.info/blog/2015/10/18/refactoring-angular-apps-to-components.html (which gave me a real a-ha moment when I first read it) would make a smoother transition into any future technology. This, along with a ‘Smart Component / Dumb Component’ architecture feels very close to React, for instance.

2 Likes
16

:point_up: – I feel strongly about this.

17

Really like that article for any Angular 1.x dev. Thanks for the link! :thumbsup:

https://twitter.com/ekrub/status/730796125712588800

2 Likes
18

I am so glad @burke, our Chief Architect agrees that we need to be doing components!!

19

I’ve tasted scope soup. Yuck! :stew: :head_bandage:

1 Like
20

So happy to see :burke: is onboard – I want this community to thrive and I don’t want our code to become outdated!