Technology choice for upcoming frontend-development

[steffen]

Hello everyone,

as some of you might know Wandelgut has received funding via DigitalHub.SH for developing the Foodcoops app. One of the main milestones is to improve to usability of the application. We see three approaches, you can find them below along with their advantages and disadvantages. We think that these options are in line with the previous discussions.

Option A: Complete Overhaul with JS Framework

• Description: Rebuild the entire application using a JavaScript framework.
• Advantages:
  • Clear separation between frontend and backend.
  • Complete redesign of the application.
• Disadvantages:
  • Significant amount of work required to recreate views and API endpoints.
  • The available budget may not cover the transition of the entire existing frontend.
  • High risk of project failure.

Option B: Update Existing Views to Bootstrap 5

• Description: Update all existing views to Bootstrap 5 while improving user experience (UX). Consider using “Turbo” for faster loading times. Additional API endpoints can also be added as a separate work package.
• Advantages:
  • Easier implementation, allowing more time for detailed UI/UX improvements.
• Disadvantages:
  • May feel “less modern.”
  • A large number of views will need to be revised.
  • Potential for inconsistent UX if some processes are updated while others are not.
  • It may take a long time before any changes are available to users.

Option C: Maintain Old App and Build New Frontend

• Description: Keep the old application, possibly updating it to Bootstrap 5, while simultaneously developing a new frontend focused on specific user groups (e.g., end users, finance team, order team).
  • C1: Implementation with Rails + Turbo + HTML + CSS
    • Advantages: Utilizes only one technology.
    • Disadvantages: May result in a slower application.
  • C2: Implementation with React/Vue as a single-page application
    • Advantages: More app-like experience, faster performance, and access to numerous libraries/components.
    • Disadvantages: More complex project requiring knowledge of both Rails and JavaScript; increased workload.
• Overall Advantages:
  • Focus on a smaller scope for the frontend rewrite, allowing for a high-quality implementation.
  • Iterative development enables relatively early releases.
  • Easier for the community to contribute.
• Overall Disadvantages:
  • Distinction between views needed for different user groups (e.g., “end users” vs “admins”) may not always be clear.
  • Two applications will need to be hosted.

We would prefer option C, but are not sure whether option C1 or C2 (probably with React) is the way to go. If we go with C2 are there enough active developers in the community that know their way around with Javascript frameworks?

What features resp. user groups do you think we should focus on first? It could make sense to focus on end user (average Foodcoop member) features as those features can work well as a stand-alone solution and more people would gain from it. On the other hand the UX/UI for admin features could definitely need improvement, though used by less people.

We invite your thoughts and feedback on these options. Which approach do you think would work best?

As we (the contracted developers) want and need to keep the work inside the timeframe, we would like to decide how to proceed until the next foodsoft community call on the June 26th.

Looking forward to your insights!

Veronika, Henning, Steffen

[steffen]

A list of previous discussions on the topic:

• Topics tagged frontend
• Responsive frontend · Issue #1125 · foodcoops/foodsoft · GitHub

[RayO]

I would be in favor of C2 morphing into A, at some point. I have experience with (also testing of) React Native (creating iOS/Android apps) as that is what we did in my day job - although I haven’t been a main developer. And older JS frameworks earlier. So any JS would work for me, although I am not a big fan of JS As note: I think that for this purpose, going the mobile app route, is not sensible as that will compound a lot of additional requirements/handling/maintenance.

Having said that: I am surely not a fan of the current HAML solution, but that is likely me not understanding its ‘secret sauce’?

Looking at the usage in our coop, mobile needs to front and center. Although I don’t have conclusive data, a quick sample of a small user base I could ask, most use either their mobile phone or tablet to do the ordering. Only our treasurer uses his laptop for the financial/maintenance options. Many complaints do exist about the less than stellar user experience on mobile (which for us got worse when moving from the Adam fork to the main project).

So any language (I am not familiar with Turbo and only limited with Rails at this stage) which is able to create “mobile first responsive” experience would be fine with me.

I think that, again from our board and my tech perspective, we would be fine with a usable “old” admininstrator version (e.g. what is there currently) for the time being. Although we would welcome a transition to something nicer interface when possible, later.

In short: moving/redoing parts to new with an outlook of a complete (enough) overhaul in the future looks the most promising to me.

Edit: would it not be wise to revisit/improve the API regardless of which direction is chosen?

[twothreenine]

I’d tend to either option B or a very limited option C.
Would a Haml + BS5 frontend really collide with responsiveness?

My opinion is influenced by the “coOps” project, where we long-term plan a new software which could replace Foodsoft completely in some years. Personally, I plan to focus on coOps for the next years and can only imagine myself contributing to short-term improvements to Foodsoft. We’re currently working on a website for coOps and will present it here when finished.

@steffen

What features resp. user groups do you think we should focus on first?

I think, anything that is necessary for making order placement mobile-friendly and easier:

• dashboard with a link/jump to placing orders on top
• list of current orders with more details like supplier picture and description
• overhaul of the placing orders view (I’d suggest collapsible article details and eventually article pictures)
• view for personal order results
• staying logged in

Apart from that, I’d rather focus on

• finishing the article unit project (including slight improvements to the balancing menu)
• finishing existing PRs
• extending the API
• refactoring?
• possibly enhancing stock articles (separate view for taking; statistics; etc.)
• other long-time feature requests like ordering cycles

than investing a lot of work in a more modern look and feel.

@steffen

[Option C]
Distinction between views needed for different user groups (e.g., “end users” vs “admins”) may not always be clear.

I don’t think there even should be a clear distinction. Food coops are thriving from “regular” members engaging in organization, be it managing articles/orders, stock articles, balancing, finances, or administration. Having a separate frontend for organizational stuff would move it further away. It could also cause confusion where to find certain features (because it’s in the other frontend).

But if this issue is regarded carefully, I don’t have any strong feelings against option C. I’d tend to limit it to placing orders and a new view for taking stock articles, though. I think, for things like managing articles and finances, you would usually use a desktop PC anyway.

Btw I guess you’ve looked at Foodsoft-shop? A JS frontend for Foodsoft based on React and redux-saga, mainly written in 2016-17, probably outdated itself, but there could be some things to learn from it.

@steffen

are there enough active developers in the community that know their way around with Javascript frameworks?

I’m only currently learning the basics of JS, and React soon. But I didn’t know anything about Ruby either before I started coding for Foodsoft.

[RayO]

@twothreenine

Btw I guess you’ve looked at Foodsoft-shop? A JS frontend for Foodsoft based on React and redux-saga, mainly written in 2016-17, probably outdated itself, but there could be some things to learn from it

This is what coops using the Adam fork have been using until Dec 24. Some are still using it, to date. Some will or have (I am not up to date at this time) moved to the main line too.

[RayO]

@twothreenine

“coOps” project,

For my information: what is the rational for this project? Is this different than Foodsoft? Is the plan to replace FS with it? Is it solving specific ‘problems’ that currently exist with FS?
I am curious how to place this in the grand scheme of things

[twothreenine]

coOps is a concept for:

1. A tool for internal organization, be it in a food coop, an open (cultural) space, an activist group, a farm, a household etc.
   • Workflows consisting of both manual and automated “operations” (tasks), including forms and an intuitive soft-programming environment. So you could custom-build pretty much anything with it, including collective orders. Incl. a Git-like “library” to share workflow blueprints with other organizations, which they can adapt for their custom needs.
   • Managing human resources, availability and skills and fairer distribution of workload; incl. auto-assignment of (recurring) tasks to members of a group
   • Managing resources like stock, but also rooms or utensils
   • Structured communication integrated with workflows and resources
   • possibly managing finances
2. A “fediverse” where those organizations can interact (cross-server), like
   • collaborating in workflows/projects
   • sending each other offers, (collective) orders, and invoices by a standardized protocol
   • sharing resources

[steffen]

Thanks for your helpful feedback. I want to put something into context:

Apart from that, I’d rather focus on

• finishing the article unit project (including slight improvements to the balancing menu)
• finishing existing PRs
• …

These are important tasks. We have received funding for the implementation of other specific tasks. One of these is the renewal of the front end. So our capacity to work on your suggestions is very limited. This has to be done by the community.

[wvengen]

This is what coops using the Adam fork have been using until Dec 24. Some are still using it, to date. Some will or have (I am not up to date at this time) moved to the main line too.

Just to clarify: the coops using the foodcoop-adam fork have been using a fully server-rendered implementation of the same concept - but I was not happy with its implementation. Foodsoft-shop was created to give a similar experience on foodcoops/foodsoft, without making the Foodsoft code too complex.

One possible benefit of using a ‘separate’ JS-based application using the API, is that foodcoops can use a hosted instance, but still host their own (fork of the) JS-based application somewhere as static files, without having to maintain their own Foodsoft install. (With a bit of tech to allow replacing certain routes.)

That said, I think the choice for server-based updates with Turbo vs. JS-client using the Foodsoft API, is mostly a developer preference. For small projects, I would generally recommend the Turbo-route, as you only need to learn one stack. But there could also be more potential contributors having only experience in front-end development, then JS-client + API could also make sense.

One question that could also determine the choice, is whether offline clients are important. If yes, then a local-first JS-client would make sense. If no, then Turbo is fine (and it would be a small step to real-time streaming updates with Turbo Streams, which I think would make sense for an application like this).

p.s. Interesting to hear about the coOps project, curious to see how it will be going.

[lentschi]

I would vote for Option A: complete overhaul with JS Framework, if we’d have enough developers to do this in reasonable time, which I feel we don’t have. Or do we?

So, failing that, I vote for Option C: Maintain Old App and Build New Frontend C2 - PWA. (Though I personally would do it neither in react nor in vue, but I think we should discuss the framework elsewhere.)

(Option B: Update Existing Views to Bootstrap 5 seems possible, but also like it’s a dead end (wasted effort).)

We could also consider Option D: Build a microfrontend host. That way we might be able to mix frontend technologies, thus being able to preserve old views in a seamless way. It might mean a lot of bootstrapping effort though.

@wvengen

One question that could also determine the choice, is whether offline clients are important. If yes, then a local-first JS-client would make sense.

Good point - an offline client would be nifty. However, syncing all the data also is a lot of effort to implement and I wonder how often people really want to work offline with foodcoop related tasks.
But local-first still seems like a good option - in the sense that you can also install it as an app on a mobile device. (I’d just not have it persist many things locally.)

[wvengen]

[sorry for my long post, tldr vote for option C]

Good point - an offline client would be nifty. However, syncing all the data also is a lot of effort to implement and I wonder how often people really want to work offline with foodcoop related tasks.

Yes, would be nice, but it brings more complexity / another mindset.

A mobile client can work in many ways, either as an app using just the API, but if we’re requiring a server connection anyway, then an HTML view is just as fine, and the choice of option A/B/C could all work well (except when connections are bad, but then you’re slowly crossing over to the offline case).

In any case, I would think it’s important to have a low development barrier where possible and keep complexity low, which means not too many different technologies that need to work together. On microfrontend: I think new developers will often start fixing things they need, this could be anywhere, so having clear technology choices within Foodsoft could help (i.e. not multiple JS frameworks in the same app, so you can learn one thing and be productive - as in “Avoid Framework Anarchy”). Like legacy jQuery + JS routes, and Turbo / React-or-whatever can easily work together on the same page.

Going back to the vote: I would vote for C. With all these years of business logic, doing everything from scratch is doomed to never reach the end, in my view - especially with us not being a large pool of full-time developers. I think C1 has lower complexity. We can see if we can leave the option for C2 open for people to make things independently (just as is possible now with the API, minus the route overrides), but perhaps not within the Foodsoft core. Open to both, though.

p.s. I think the speed question depends on what is meant with speed. For initial page load and low-end devices, Turbo is faster (provided stable connection); for unreliable connections and expensive API calls, a JS-based app can be faster (provided client with enough resources). Attention to caching details is relevant in both cases.

[twothreenine]

@steffen

These are important tasks. We have received funding for the implementation of other specific tasks. One of these is the renewal of the front end. So our capacity to work on your suggestions is very limited. This has to be done by the community.

I know. But a front end renewal requires at least some feedback/review from other community members and therefore shifts our resources away from those other tasks. Also, if your team can’t finish it within your funding, it would lie on the community to finish it.

That’s why I’d suggest to chose an option that’s both realistic for you to finish (in a deployable state) and realistic for the rest of the community to review.

[yksflip]

Thanks for pointing out the different options!

I have strong objections with A, as I also find a complete rewrite unrealistic.
I have slight objections with B, as it might take much longer until users can benefit from it.
I have no objections with C. I think foodcoop-shop is a greate case-study that this approach will let users benefit from a better flow.
Regarding C1/C2 I don’t have a strong opinion. C2 would require more api design work and project-setup, deployment etc… On the other hand C2 is less coupled which might make other things easier …
Regarding a potential JS-Framework, I don’t have a strong opinion, as long as it’s one of the popular frameworks (react/vue/angular/svelte), it should be possible for anyone with JS experience to pick it up after some time.