Websites Revamp Frontend Framework

The Websites and Apps team is in the early stages of a websites revamp. At this time we are deciding how we are going to set up and maintain our community’s websites in the future.

As part of this process, the front-end developers in the W&A team intend to refactor the websites to use a javascript framework. This initiative will start with key sites such as and Along with the development work, we will be writing clear documentation so that future refactoring, editing, and updating front-end code will be easy for people to do.

We are deciding between ReactJS and VueJS as the two leading frameworks that we want to use. However there are lots out there and we want to put this to some community discussion.

Content regarding pros and cons between different frameworks can be outlined in the following discussion, however some important questions for this decision are:

  • Will this technology be relevant in 5 years?
  • Will this improve our front-end development potential? --how?
  • WIll new contributors be able to get involved? – how will we manage the learning curve?
  • Will this choice empower contributors with greater front-end dev skills?
  • How does this effect the maintainability of our code base?
  • What limitations will be caused by this technology?
  • How much work will be needed to maintain this?

Our goal with this thread is to determine the best approach moving forward, to gain an understanding of how we should approach building training materials, things that we should watch out for, and of course, for people who would be interested in working with us on this!


1 Like

I propose using VueJS. As it is progressive, we can implement it over time, it will allow contributors who aren’t comfortable with jsx to participate, and its approach to manage components and styling is easy to organize.

As it uses html templates, it will be easier for contributors without framework experience to contribute, and will give newer contributors the ability to learn about how to use frontend frameworks.

Vue also has a growing user base and active community so it should be a good system for time to come. Plus it is scalable.

Vue is known for being better at organizing projects, and for requiring less lines of code then some of its contemporaries - which should be beneficial to the code’s maintainability


At the moment, the only point I have in defense of ReactJS is that it does have a huge community for support. Other than that, both have pretty similar pros and cons. JSX could be slightly hindering when it comes to ReactJS.

Another point that I would like to stress is, whatever framework we decide on, it should be easily implemented across all websites in the Fedora community. Be it a simple website or a complex one, the framework we choose should be scalable and easily to maintained.

All this being said, I would like to vote for VueJS as our choice of framework.


+1 for VueJS. My employer was deciding between Vue and React and we ultimately went with Vue and it was a great choice. The learning curve is not at all a hindrance, it can be implemented over time, and it can do a lot while writing very little. It is also definitely a growing tech in terms of usage and community.

1 Like

+1 for VueJS for scalability.


Here are some points we would want to consider while picking up a front-end framework of choice for certain sites/applications.

  1. We need to check if at all there is a need for one in certain sites or are we trying to provide a solution for a problem that does not yet exist? Static sites can do away with plain HTML/CSS/JavaScript stack and it can help a long way in maintaining the same, albeit applications like Mote and Badges could make use of some frontend framework magic.

  2. As most contributors here are volunteers, we would not want to mangle around multiple frontend frameworks for multiple projects and hence, we need to coincide with just one choice by the end of the discussion and stick to it for most applications. (Why most, and not all? The fallback option which stays viable at all times is written in point #1)

  3. Many apps under the Fedora Infrastructure are software packaged into RPMs and then distributed/deployed, (albeit that is slowly changing with the adoption of containerized deployments but it would be some time before that becomes the primary way of deployment). We need to consider the difficulties that would (most likely) come into the picture when packaging the static JavaScript assets as a part of the package.

  4. As much as a frontend framework can make things easy for the applications (although, the “ease” is not immediately apparent but might be so, in the long run), this raises the initial requirement to be a part of the team. Of course, we can help folks with learning these as a part of our apprenticeship approach of the objective but being a volunteer-driven team, the attention would be hence greatly divided.

  5. Localization/Internationalization is a big issue to consider here as with the likely adoption of frontend frameworks, translation pipelines would be needing curation (and who knows they might need a complete rewrite?) to figure out the template strings among the (now, restructured) static assets. Plus the last time I checked, JavaScript template literals did not play well with Jinja directives.

  6. The frontend of some websites are hugely backend-dependent - to a point that the entire website is rebuilt and redeployed every after equal intervals of time to reflect the most recent updates. Some notable examples of these are Easyfix and Mirrors. Using front-end frameworks in these would not add much value as the provisions that these bring to the table would be disregarded due to the backend-first approach.

  7. With the likely adoption of a frontend framework, pipelines for locally building, translating and testing the sites would need to be rewritten. For that, we need to check the availability of the required packages on a fedora(:latest) base image - which further makes us dependent on the packaging side of things to see if the sought frontend framework is maintained as a package or not.

There could be a lot more things to consider here that I did not but with these in mind, I would want for us to stick with plain HTML/CSS/JavaScript for the most parts, but use Vue as and when it can be “feasible” and “viable”. Adopting frontend frameworks to places where it is not needed would not only give an “undesired” solution but also arise a lot of problems as a result.


I believe we should ask question why we need any JS framework or even JS code part at all. Are we going to have some highly interactive areas in our website?
Maybe going with plain HTML/CSS is the way to go. There is clear trend on the Internet to go with static pages as they are lightweight and fast, maintenance also looks easier.
I’m aware that many frontend developers like JS but maybe we don’t need it.
I’m not an expert here but just want to look at this revamp from different perspective.


To dovetail on what you’ve said… with respect to frameworks, I think it’s wise to keep in mind that not everyone lives in 1st world countries with fantastic internet speeds. Requiring a person to download a ton of libraries works well when you’re sitting at the end of a 4G or a +100mbit land line connection, but not well at all when you’re at the end of a 2mbit one. We should probably keep in mind that our websites should run well with very little bandwidth.
I realize frameworks are liked by devs because it makes their job easier, but this seems like a case where the users needs are more important than developers needs. If our sites are slow to load and hard to navigate on slow connections, people wont use them.
Just my 2 cents.

1 Like

I don’t know what bandwidth gobbling features particular frameworks being discussed bring to the discussion. I understand the desire for a ReactJs solution, I do a bit of coding with the Quarkus framework and like how easily I can connect to a containerized PostgreSQL backend and in my uses make a real nifty bit of containerized java apps, all talking in the same POD and webpage too. But to your point, I live in one of those wonderful countries which still lags in bandwidth depending on your geographic location therein. So minimal front end with the ability to easily see the path to get to where I want to go is my user mind. Sustainability, morph-ability (within reason), FOSS based solution, and ease of ongoing upkeep is my community support persons mind on this.

1 Like

I think translation support is a must have. Weblate is flexible, there is plenty of supported formats, but we also need to make sure that the format do not break the existing workflow, by supporting what the I18n teams need. Ideally, something that extract a file for gettext (so .mo/.po) and use them would be fine. No need to do it at run time for most website should be ok.

And I think also than rather starting with key sites, it might be better to start with a smaller one (in term of number of pages to convert or content) so the various problems can be ironed out without pressure or anything. If there is a problem found down the road during a rewrite, then it will be easier to restart with 1 or 2 pages rather than 30 pages.


I also wonder what should be done in term of accessibility. I do not think we do much right now, but maybe a rewrite is the moment to think about what can be done to make it easier to support, and/or incorporate directly in the process


I think at this point, my only thoughts are: in order to keep it easy for operators we should standardize with an already made template like the one linked below or something similar that is likely to be maintain for a long time into the future: GitHub - Splode/jekyll-vue-template: A starter template for Jekyll projects with Vue.js and Vue Single File Components, complete with webpack.


I completely agree on working on smaller ones first to get an idea about the kind of road blocks we might have. This came up in today’s meeting and I am up for it.


So I went to stroll in the bad weather ( artist rendition ), and I have now more thoughts (controversial ones).

I do not think we need to think if the tech will be relevant in 5 years. I mean, in a ideal world, we should do that for sure, but practice showed me that this is not important. People from today do not want the tech from 5 years ago (exhibit 1: the date on Overview - fedora-websites - , exhibit 2: the date on Overview - fedora-web/websites - ), so I do not see why people in 5 years will want to use the tech from this year.

And each time someone new volunteered or was hired to take over the maintenance of a existing website in the last 6 years of my professional life, it went in 2 ways. Either the new maintainer say “this framework/CMS/etc is bad, we should rewrite” and rewrite in a different system. Or they say the same words, but do not finish the rewrite so the old website is still here.

So dropping the tech stack and restarting from scratch is the norm, and so we should optimize for it rather than trying to avoid that.

For example, what we can do is to make sure that websites can evolve without trouble, by being separate enough that a volunteer can take one and just change the whole system without having to port all others. If we can’t be sure that people will have enough time for a future big rewrite of everything, then we should make sure there is never a need for a complete rewrite of everything. And since maintenance of existing websites is usually not what people favor, then the only option is to have smaller rewrite events, with smaller separate websites, with decoupled code bases, even different frameworks.

Eg, maybe not refactor under 1 big umbrella, because then we will face the same problem as we did in the past.

And to be clear, I am only speaking of the static websites, so what is in this repo and this repo. Frontend for more dynamic websites (like pagure, badges, etc) might need to be discussed with the maintainers, who might have constraint on their own. For example, we can’t expect people to rewrite pagure easily, so the argument of separation do not apply at all.


So, I’ll toss in my thoughts as well. :slight_smile:

I think it’s important to keep in mind how the current system works and the constraints it has/was created under. For those that don’t know, here’s a summary:
Source is checked into git repos, then a job on backend machines (called sundries01 or sundries01.stg for staging) clones that repo and builds the site. Then, it’s rsynced to our network of proxies. This allows users to get served static content from a proxy “close” to them. We may want to change that, but it’s worked pretty well over the years I think.
So, if we do keep this model, we will need to be able to build on sundries. Right now those are RHEL7 machines. They could be upgraded to RHEL8 or even Fedora, but maintaining a esoteric build env is added burden that infrastructure may not wish to take on. Additionally, in the current model the proxies serve static content for the most part, so if you need to run some application to serve things that also will be difficult/burdensom.

As far as look and feel, we have Overview - fedora-bootstrap - which is a variant of ‘bootstrap’ created by our own @ryanlerch So, applications that use that look similar at least.

Finally as to scope, I would guess this is mostly getfedora/alt/secondary/etc sites right? Applications are going to be made in their own frameworks, etc.

Exciting to see all the ideas floating around and energy! Look forward to helping you all out in making this happen.


Those are good points.

Perhaps it would then make more sense to many of our static websites as SSR sites and focus revamp efforts to updating our css/scss, and frontend javascript code to improve user experience.

I agree with your point #2 that we should only choose 1 framework. Regarding application of a framework, it would likely make sense to do so for web applications.

on point #5, it’s not 2 hard to make JS template literals work with jinja, we would have to set up how we aim to do that, and I believe that it would be of value as template literals are really nice to work with.

For our decision making on what approach we use for each app and site, we should have a bigger conversation of which applications may benefit from a CSR approach. apps where users interact with site content a lot more could benefit from a UX and speed perspective by using frontend frameworks.

Regarding points 2 and 4. I do especially agree on making participation accessible. I also want to make the point that it is important that we take a frontend development approach that will keep our team current with modern design standards. I think clear documentation will be essential for this end.

On point #7, do you see this as an issue that will have a short term period of challenge but even out to a comfortable normal? or be something that will pose a general increased level of difficulty and complexity?

1 Like

Great points. I think it would be really cool if fedora’s web dev team could be a relevant part of Vue’s broader community. Having good documentation and an effective place for contributors to learn and improve their skills etc.

1 Like

jekyll could be a useful tool for our static content generation. This jekyl-vue-template looks really interesting!

1 Like

I’m curious about your point on optimizing for restart from scratch sized overhauls. I’ve seen that issue happen as well.

It would be useful to consolidate some of the static site codebases (something that is a currently unfinished project), and have a clear visual approach for contributors to note the state of sites. So we can avoid some sites being updated and kept current while others fall to the bottom of the stack.

from a front end perspective, perhaps it would be effective to put energy into updating scss for fedora bootstrap to make broad scoped changes consistent, and then follow up with smaller site/page focused changes as we go (while keeping track of them).

After doing some lighthouse tests on a few of our sites, we certainly do have some opportunities to improve our approach to accessibility.

Thank you for bringing up this point, we can improve some of our site semantics, alt text, tabindex, and some other stuff for screen readers etc.