Upgrade AngularJS 1.5 to Angular 7.0

OFN uses AngularJS 1.5.
After version 2.0 AngularJS was renamed to Angular.
LTS for Angular version 4 ended on September, 2018
Angular is now on version 7.

This is obviously a major problem in terms of maintaining up to date frameworks and libraries in OFN.

I believe this has not been discussed in the community so far.
An alternative better seen by most current developers (but not obviously the easiest or the best) is to drop angular and pick a new framework like React to build the OFN frontend.

Not an easy decision, but we recently agreed we need to raise this topic for awareness…

An alternative better seen by most current developers (but not obviously the easiest or the best) is to drop angular and pick a new framework like React to build the OFN frontend.

yes, I’m afraid a rewrite in React is not the most affordable solution :sob: Wouldn’t the frontend benefit as well from being split into domains? I wonder if there’s a way to gradually migrate to an up-to-date framework, whichever.

angular code will be moved to domains as the domains start to emerge.
This is described here: https://github.com/openfoodfoundation/openfoodnetwork/wiki/Tech-Doc:-How-OFN-is-organized-in-Domains-using-Rails-Engines#technical-structure
and already done here: https://github.com/openfoodfoundation/openfoodnetwork/tree/master/engines/web/app/assets/javascripts/web

we can then migrate one domain at a time to a diff tech or version of angular.

1 Like

dependabot thought of start this automatically :slight_smile:

I have been thinking about this topic lately.
We need to define what framework we want to use in the future and how do we get there. We need a strategy.

Requirements

The main requirement here is really stability which is the hardest thing to get in the javascript frameworks world. The main points here are that we choose a framework that:

  • is not outdated already (like angularJS)
  • can be upgraded easily as we go
  • survives the test of time (is maintained in 2030 :heart_eyes:)
  • is not too much intrusive dictating how to do things (this is clearly a weak point of Angular compared to React and Vue that offer more freedom to the developer)

I am on the conservative side about this decision. I dont think we should go wild and choose a framework new, exciting and awesome that will be completely dead in 2 years time. I think we need to think most of all about the long term here. This means I think we should keep to one of the main frameworks in the market right now: angular, react and vuejs.

Market Analysis

I looked at google trends:

You can see other trends in " 2. Angular vs React vs Vue: Popularity in 2020" here. For example, of the 3 frameworks, vueJS is the most stared project on github.

VueJS

I see that Vue.js is still smaller than Angular in terms of adoption BUT I just realized that vueJS is a creation of an Angular expert, from wikipedia “what if I could just extract the part that I really liked about Angular and build something really lightweight.”
It’s the first time I am looking at vueJS code. It looks surprisingly similar to Angular, which is a strong point for it’s adoption in OFN as we have (and will have for a long time) quite a lot of AngularJS code in OFN: https://en.wikipedia.org/wiki/Vue.js#Components

Angular

If we decide to keep in the Angular path, we need to upgrade from AngularJS to Angular, I have been reading about this and it just sounds complicated to me (I have only worked with AngularJS in a few projects, I have no experience with Angular). I have the feeling that learning Angular or learning VueJS would be the same type of effort for a dev with experience in AngularJS (I am not sure about this).
The upgrade path from AngularJS to Angular looks complex (maybe it isn’t that hard after we get the hold of it!) and maybe it’s easier to start from scratch in a different framework like vueJS.

React

React is the most popular framework out there (at my previous company I witnessed a lot of .net backend developers becoming react developers and loving it). I wouldnt be against migrating to it but I am concerned that it would require a longer learning curve (than angular or vue) for existing devs.

Decision?

I am afraid that setting up the upgrade to Angular will take us some time but setting up VueJS or React will also be a challenge. I am really not sure how to proceed. I am only sure we must make a decision and slowly get on with it.
What are you thoughts? Do we flip a coin?

This is related to the thread about the new BackOffice UI where I have also posted now.

1 Like

Thanks for raising this @luisramos0!

The only contribution I have is that an important consideration is also about attracting contributors. An investment in learning a new framework for the core team might be well repaid if it makes the platform more attractive to new devs.

For this reason I wouldn’t be opposed to React. Though I get the drawbacks considering our current position. There is no obvious answer, obviously.

For me this raises the question about the skills in the core team.
@devs - who knows which framework to what level already?

1 Like

Personally, I don’t like Angular. I just can’t understand what the code wants to say (this problem can be with me, that’s why I said “personally”). On the other side, I learned some time ago both Vue and React, and I liked both. From the time I think the learning curve of React was quicker, mainly because the framework is on the hype, and there is an uncomparable amount of material to learn it on the Internet. I’m also working with React and Rails, and this could be a reason to learn to React faster.

React and Vue are both excellent options, and I think they will not be so hard to learn, but for Angular developers, Vue probably will be more comfortable. Both are well maintained and have good communities. This would help a lot to attract new contributors.

1 Like

thanks @lin_d_hop yes, that’s a very important point, I think Angular looses quite a bit to both React and Vue in terms of popularity, Vuejs is also very popular among devs as you can see by the github trend/stars.

thanks @jeduardo824 that’s valuable feedback!

My dev profile:

  • I know AngularJS really well, no hands-on experience with Angular, React or VueJS
  • I know what are the problems of Angular and that’s why I’d prefer to jump to vueJS or React
  • I’d prefer to jump to vueJS because I now believe the learning curve will be a lot easier than React

There is another option: don’t implement an SPA and use server-side rendering instead. Might be worth considering the pros/cons of that approach too?

Thanks @jonleighton for you idea!

Yes, that is an alternative. My assumption was that the current core devs agree on the basic future architecture of the solution: we want to keep using JS but not for so many things as current code is doing right now. We want to build the basic rendering of pages in rails and then use a JS framework to fetch the data from an API endpoint and populate the page with that data.

We can definitely challenge this assumption.

Pros:

  • simple architecture, no need to understand the mix of client/server code structure
  • project would be more attractive to rails devs - we stick to rails and it’s community, we would not have rails devs feeling very unconfortable looking at JS code as we have right now
  • better UX, no JS processing time making the user wait (this point is debatable, we probably dont need to go into it)

Cons:

  • wouldn’t support the growth of the OFN API - it would not foster the API first mindset in devs
  • project would not be attractive to frontend devs (I mean, angularJS 1.5 is obviously not attractive to anyone, but latest vuejs or react will attract some valuable frontend devs)
  • more server side CPU needed (no leverage of the client CPU power), this could be balanced with cache, but we all know cache is painful (this point is debatable, we probably don’t need to go into it)
  • we would still need javascript and it’s libraries to do some of its UI magic

In my mind the first con is massive, we have to put API front and center of this project and an architecture that supports it’s internal use and evolution is critical for that.

I like to discuss @jonleighton idea too. It’s very tempting to focus the debate on a solution but I’d like to step back and think about the needs and problems. What is it that a OFN UI does and what will it need to in the future? what’s the level of UI complexity needs to support will need to provide? How changeable will it be as the product evolves? what else should we consider here? Depending on these we might find other suitable solutions. There are a bunch of other approches beyond SPAs. I have Stimulus in mind, but I know there are others. I’m just not familiar with them. Thoughts?

Other than this, agree with @lin_d_hop on attracking talent as a criteria and with @luisramos0 that we need and approach the makes us consider the API a product in itself.

I need to put some more thought on all this.

As for tech itself, I share @jeduardo824’s ideas around these three frameworks. I’d add that React feels like OOP principles (this dev team is very good at) to frontend-land. That’s why I believe this team would get up to speed with it very quickly.

My dev profile:

  • I don’t know AngularJS as much as I should
  • I have some experience with React. Nothing production-facing other than fixing a couple bugs in the past and a side project.
  • I have 0 vueJS know-how. I’ve just seen a bunch of code snippets.
  • No other framework experience other than jQuery or the good old Backbone hahaha

In my mind the first con is massive, we have to put API front and center of this project and an architecture that supports it’s internal use and evolution is critical for that.

Yes, this does seem like a key point for OFN. I am not familiar enough with the goals/use cases of the OFN API to really comment on it with regards to this decision. Though I would pose a question: if using JS for web rendering is necessary to ensure that enough attention is given to the API, how do you know that the API will be solving its other use cases? If the ultimate goal is to have a usable/useful API, are there other ways to achieve that without relying on it ‘falling out’ of the web UI?

(BTW, I don’t have a settled opinion on the matter, I’m just trying to ask questions to unpick this further.)

If the decision is made to go with an SPA architecture, I do agree with the general momentum in this thread towards React. I think choosing the most popular thing is likely the best decision for a low-resource project like OFN.

FWIW, I have used React on two projects. One was a web app but not an SPA – I used it to build a complex UI on one specific page. The other was a React Native mobile app. So I don’t have experience of building a (web) SPA with React specifically. But in general I think React is pretty easy to get to grips with, there are some nuances to learn for sure, and the SPA architecture/framework would need some research, but the basics are pretty simple. (I’ve never used Angular/Vue so can’t compare with those.)

We would have to build the pages in the server side and then build API endpoints for everything in parallel. I see two major problems with this:

  • not leveraging the effort to build the UI to develop the API, here I am being very specific: building pagination in the products list in the backoffice gave us pagination on the products API (this PR) and building a paginated shopfront gave us a new endpoint with the paginated products in a given order cycle (this PR)
  • one other major point for me is dogfooding, there’s an extra cost in building an API that you don’t use. In our context I am afraid the API would grow stale in many parts and would be seen as a burden to be miantained. If we use it for our own pages, it’s will be more organic as we evolve/maintain the UI (example recent PR where we add shipping method filter to the orders API endpoint: here).

Instead we can continue to create synergies and use our limited resources to build the UI and develop the API at the same time. I think your point about API goals/planning is very important and we need to make sure we grow/design the API so it fits its goals, not just our internal goals. I think we are slowly starting to do this as the API starts to be used externally.

Re SPA, I may be mistaken but I dont see OFN as an SPA. Our routing is on the server and every URL is mapped to a rails controller and a rails view, inside each page we do have angular controllers for that specific page to do JS magic (too much in some cases). I thought an SPA is when the routing is done on the browser (I have worked with that in the past and it felt like a completely different game).

Looking forward seeing feedback from more devs @Matt-Yorkley @kristinalim @maikel @mbudm, this is definitely going the react way so far…

Great discussion, I have been following and waiting for a bit of spare time to dive in to this. I’ve grabbed the key concepts being discussed and adding my 2c for each.

Domains and breaking up into SPA sized pieces

The domains as discussed are pretty big, and probably beyond a single SPA. If we wanted to go the SPA route then some of these domains would be broken up further. To me a SPA is good for a cohesive single UX, something that a user would consider a single job. This is because a lot of the benefits of SPAs are needed in those UX cases. Think things like seamless back and forth between steps in a workflow, allowing things like undo and autosave or options of different non linear approaches to workflows - the user can do things in a way they want.

SPAs (along with APIs) are also good for discrete development, which can make the open source community contributions easier to get set up and do, You may not need to install the whole OFN ecosystem, especially if a staging API can be used and you are just doing front end changes. I think this is particularly good for short term open source contributors, such as hacktoberfest or new coders looking to get some experience.

Choosing safely for the future

This is tough, rally tough. It’s now 2020 and we’re talking about changing from a tech choice made in 2012, that’s a lot of pressure to make the right choice until another chance comes along.

I have used React, Vue, AngularJS (ages ago, although the memories are now flooding back) but have never used Angular.

I lean towards React in terms of future safety as, it’s been around longer than Vue, and probably has better docs/vested interests than Angular. I also know that React is very cleanly isolated, it works with a lot of other things whereas I found Vue to be a bit opinionated (much like AngularJS) which concerns me as it makes modifying parts very difficult, you are always locked in to changing the whole.

Now part of this could just be the architectures I’ve seen - it is probably quite possible to have a well separated front end architecture, that is open to extension/change in all 3 of the ecosystems we are looking at.

I’m a big fan of this testing library that has been adapted to all 3 frameworks. This along with tools like Storybook that also work across ecosystems give me confidence that it is possible to create clean, well-isolated front end components, mini and major SPAs with all 3.

Encouraging community involvement

As I touched on in the SPA section, good architecture and ease of dev experience in setting up is key here. Again I think this is possible to be done well with all three. Thinking about the profile of community contributors may help here, are they wedded to a particular framework? Or are they keen to try new things? This may give us different answers than looking at the overall trends. @lin_d_hop are you a good person to ask about the people who have volunteered contributions? Of course past experience may not predict the future so this may be hard to figure out.

Server side rendering (rendered template views)

This is an interesting discussion - there is definitely a bit of a turning back time to before the SPA era that I’ve seen, and it’s a fair point - what was so bad about simple rails/django/laravel/.NET rendered views !
Well I guess the main thing is what I mentioned in the SPA section, those ‘app-like’ UX features that SPAs really help with. However I wonder how much is really ‘not possible’ with routes rendering forms that POST. I’d also shout out here that the Tailwind atomic CSS library and component set is pretty damned good, allowing pretty nice UI in simple html templates. We used it with Alpine which is a very light touch way of adding interactivity to straight HTML (a bit like Stimulus perhaps @sauloperez)

In case I’ve missed the point of this section entirely, I should also mention NextJs - server side rendering of react, with a bonus of data retrieval as part of the render. This is a nice use of react that I’ve experienced which really helps with performance, which is something to think about if the growth in OFN audience is towards more low bandwidth users.

Component libraries

I’d definitely be very wary of a component library as a big time saver/silver bullet for one task that then gets used everywhere, or dictates a tech choice. I had the misfortune to work with ExtJS for a few years, primarily because people were wowed with the component set. Apart from the perf issues as the library bloated, it was the customisations that really killed us. Must have features were often very hard to do as customisations. I lean towards using more atomic components that can be built up to something complex, or that give you the option of doing a large bit of custom work when needed.

Caveat - ExtJS was just bad in many ways so this may just be my scar tissue showing.

OFN API

This is great that the discussion has pulled in the API as well, as I agree it is super important to make it a core part of the work (dogfooding as @luisramos0 said). I’ve loved this approach ever since Flickr did it back in 2005, it’s just a no brainer that this is how you get a good API and I’d argue a better app experience.

I say a better App is likely because I think that API/separate front end just gives you more options, more deployment options, more customised curation of workflows that we haven’t thought of yet - a flatly designed API is a good hedge against a beautiful domain structure being thwarted by reality coming in and blurring the divisions you’ve created. Whereas I’m not familiar with but suspect from my experience with other MVC backends that rails engines and server rendered views may be more work to adapt to something wild that crosses the sensible boundaries that have been created.

My experience

I’ve used React quite a lot, and have found it quite easy to onboard non JS devs and get them productive quickly and enjoying it… “Oh, it’s just a simple state machine” it still one of my fave comments from a backend dev 2 days into using React.

I also want to fly the flag for TypeScript here - I’ve found TypeScript much easier to use with React than with…

…Vue, which I used last year. It was an inherited project and there was a bit of cleanup to do so not the best starting point. As part of that cleanup I introduced TypeScript to get a hold on the complex data model and untested code. I don’t think Vue and TS were a great combo. However I believe that Vue 3 has much better TS support. I can see the appeal of Vue, but I was a bit thrown by some of the magic/convenience. I’d say it’s a bit slower to onboard to Vue than React but Vue is faster (less boilerplatey) once you know what you are doing.

1 Like

I am adding here an extra point about having multiple frontend technologies at the same time (for some time) and the size of the codebase, I think this is relevant for the decision.

Upgrading to Angular will consist on setting up the AngularJS/Angular ngUpgrade bridge that will enable us to build modern Angular components together with our existing AngularJS. No major changes in the tech stack.
On the contrary, one problem of adopting now React or Vue is that OFN will be for some/many years an application with two frontend technologies, for example, AngularJS and Vue. At first it sounds like a big drawback… to counter this point I thought of lines of code: maybe we have a small AngularJS app that we can replace fairly quickly.

So, OFN is today ~30kLOCs production ruby (plus ~50kLOCs of ruby specs). Plus maybe 30% of this size for all the Spree code we rely on/decorate. Plus ~15kLOCs of haml templates.
While in AngularJS we have admin (all backoffice JS code) with ~7kLOCs of JS (plus ~7kLOCs of js specs) and darkswarm (all frontoffice JS code) ~3kLOCs of JS (plus ~2kLOCs of JS specs).
So, indeed, I think it’s a fairly small JS code base (although quite complex) that we can plan to replace. But it all depends on the dev capacity available.

I agree with your definition of an SPA, but I didn’t understand that this was the proposal.

Aside from the benefit of ‘dogfooding’ the API, I think that doing server-side routing but client-side rendering probably obtains a lot of the downsides of an SPA without many of the upsides. The typical trade-off with SPAs is that it’s more expensive to get to the point of the initial render, but once you’ve downloaded that blob of JS the app can be quite responsive because you don’t need to do any more full-page renders. This solution would require the cost of doing full-page renders as well as the cost of client-side rendering. Though on the plus side, it would be a bit simpler architecturally than having a client-side routing layer too.

thanks @jonleighton good points.
This server side routing and basic rendering plus the client side data rendering (without routing, so, no SPAs) is the current architecture: it’s what we are doing in most pages now.
The data that is loaded through the API is not loaded on the server, so we are really just moving the work from server to client.
I was all for the SPA style when I started in OFN, now I really enjoy the simplicity of the good old server side routing.

There are some really good points in this discussion.

I learned AngularJS because of OFN and I never liked it. There are some concepts I like and maybe that’s where Vue is going but I have no experience with Vue, React or newer Angular.

The discussion about the API is good to consider but I think it detracts a bit here. Yes, if we use the API in our JS code, it will be better for the API but if we decided that we don’t need JS at all then the API would be build differently. That’s a separate discussion and I do think that we will always need some kind of Javascript. So which one do we go with?

I like focusing on the long-term sustainability. We should choose the best framework for us and not the one we know the best. All core devs are happy to learn new technologies. And learning a compromise sounds less exciting to me.

Luis’ point about Vue being more similar is valid if we think that Vue and React are an equally good fit for OFN. The popularity of React seems to speak for itself though. While I have no experience with it, I found Steve’s comment convincing:

We want to be flexible. One day there will be a new solution and if React plays better with other things then it will make it easier. And it sounds like it will be nicer to use React for little things without all the overhead that comes with AngularJS.

Maybe we could choose a small example from the frontend which we could try to implement in React and Vue, for example the login modal. The process and the resulting code may tell us more about the fit for OFN.

Just another thought: our struggle with AngularJS may just come from the fact that AngularJS was built for Single Page Apps and OFN is currently not an SPA. There may be parts that will become more like an SPA.

1 Like

Wonderful! I think it’s time for a React Typescript POC.
If Steve has experience with React and TS, we could decide that Steve can build his next assignment with React instead of following the existing AngularJS structure? :heart_eyes:
We would just need to see what are the things coming in the pipe that could fit here and what would be the impact on the time estimate for that job. :smiley:

1 Like

I’m glad I read to the bottom of this even though I was lost for much of it - enjoyed the last comment though :laughing:

So that would need to be a relatively discrete component / page that could then sit inside the app but be built totally different? Should it be front-end or admin side? just for my brain to be rolling around with it

Sorry @Mario - looks like maybe React is beating Vue, and therefore Vuetify