Websites Revamp Frontend Framework

It would be good for our sites to be more interactive to improve the UX aspect of our web presense. We can do this without adding too much weight, and in many cases, having our sites rendered server side would make more sense. for applications where users are going to move around from page to page a lot, client side rendering makes more sense because the load time between pages will be much less.

Maintenance of plain html can become quite tedious, for SSR sites, taking advantage of jinja templating resource, and improving our documentation on how to work with jinja for new frontend dev contributors - of whom many are likely going to have more experince with JS based sites.

For sure. Regarding performance and loading, we can do a lot to improve that by optimizing site assets like images (converting to webp or jpg and setting sizes correctly can go a long way to improve loading times).

On navigating sites and loading. This is an interesting topic, a framework would make the initial load a bit slower, but then moving around the site quicker, especially if there is a lot of user interaction. So this is something we should keep in mind. But I think one of our biggest issues for loading is and will be proper management of static content.

I’m fine with Vue for interaction heavy sites, but I think we shouldn’t use JS when we can do without it. Right now we are using jquery which is no longer necessary for the most browsers and could be replaced with some plain js or small parts from vue. The most important part is: we need a system that works good with translations. If I would decide just for my own sake I would produce plain html files from pugjs files mainly because of the ease of use and one can produce good documentation site for newcomers to css/sass and html code with the help of Asciidoctor (or Antora just not as easy).

Btw what do you all think about some form of styleguide for scss/html? It can serve as both standard, documentation and even have a playground for new ideas etc. It’s much easier to implement something like that as you go along building sites than trying to create it after the sites are allready finished, case in point.
Another good thing with a styleguide is that everyone agrees in some form of concensus in design so that not everyone would pull in different directions. I mean something in the lines of examples listed here.

I would suggest that we don’t start with getfedora/start.fp.o but with fedoracommunity.org then move on to building styleguide which would be the basis of our design decisions.

Fedoracommunity.org is a good candidate because it can use i18n and it could have some interactivity and isn’t used as frequently as some other pages.

1 Like

Just noticed: a bunch of community sites do not resolve so it would be a good opportunity to do some link cleaning.

1 Like

Building on points already mentioned here, statically generating sites could be a good option. I’ve had a lot of luck personally with Hugo, but would probably be more comfortable with a Python based generator like Pelican. Additionally for a Vue option, Nuxt.js is a static generator for Vue.js.

What is still missing then is a CSS framework to make styling content easy and streamlined. Bootstrap is a bit dated at this point and a newer lightweight framework might be worth pursing such as Bulma or Pure.

2 Likes

I think it might be interesting to decouple the build system from sundries. While RHEL 7 is still supported, upgrading to RHEL 8 would requires coordination (even if I guess a plan could be to have sundries2 on RHEL 8 and move workload).

Using openshift for build would IMHO help a lot since it also let us open the log on a per application basis, and that was a problem we faced in the past in others projects. This also force us to use container for build, which also make it easier for CI.

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

Curious in what way ?

Empirically, rewriting is what people want to do (volunteers or not), maintaining existing code is not.

But rewriting and maintaining are the same process of creating content, as there is a spectrum from “no constraint at all” on one side, and “this need to use that stack in that version, that css, follow that guidelines with that content” on the other.

If the rewriting side of the spectrum is seen as more desirable (since that’s what everybody want to do each time ), we need to know why the alternatives are not.

I am too sleepy right now to be able to drop a novel sized message with a great theory, but I suspect it has to do with the agency of the people in charge, and because it seems simpler to rewrite than to learn/discover the legacy codebase (or just more fun).

So if you want volunteers, then what attract them (making new website) should be easy to do. If my hypothesis regarding constraints and agency is right, we need to increase the agency of the future volunteer by having the least amount of constraint, eg ruthlessly remove everything that could be seen as such.

For example, not mandate a specific build stack, just “it should generate static pages using a container”. Not mandate to use a specific footer HTML code, just “we need those links”. Not mandate a specific format and extraction of strings system for translation, just “we do not care as long as it output something compatible, and take this in input”.

The more constraints we have, the closer we move to the undesirable side of the spectrum. I might be controversial, but I think that a common css, a common js library, a mandatory footer (as opposed to the mandatory presence of the information) would remove some agency, and add more complexity, so might be undesirable long term.

2 Likes

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.

It would make a lot more sense to work on the client-side JavaScript code for DOM manipulation and not on rewriting them with a frontend framework because they would most likely not be benefitted by their addition. To add to that, attempting to streamline all the sites and applications to make use of a single frontend framework can seem monolithically sound in theory but would require a lot of effort and painstaking planning in practice.

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.

Having worked on the ancient fedora-websites repo, I can see that we are likely to hit a lot of walls with using both of them in most cases. Of course, that can be avoided by rewriting a large chunk of the frontend code (by large, the extent can go up to ~75%), which makes me want to think that even though this can be beneficial for the team down the line - unfortunately, we do not quite have the number of folks to keep doing this consistently for a longer period of time. Please note that the transience of contribution has been something we have been discussing about since the last couple of meets. :slight_smile:

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.

A big +1 to this!

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.

A clear documentation would certainly add viability to the approach but at this point in time, the feasibility of sparing a folk or two just for the documentation - does not seem like a good idea to me. We already have folks working on the wiki page, making sure that we are visible to the newcomers, writing steps to add/remove banners etc. and adding one more documentation task would mean that we are swiftly drifting away from the primary goal.

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?

The latter.

Point #3 might change in some time but I am not holding my breath, and we should definitely still stick to the previous workflow of package-and-deploy for at least some eight months to a year. I understand that it might not look like a big issue on the face of everything else but one would have to take a look at how the deployments work in order to understand the dire nature of it.

1 Like

@misc,

I completely concur with what you think. We have been on this path previously as well with another one of such revamps and a discussion about JavaScript frameworks back in the day (it can be found here About JS framework - infrastructure - Fedora Mailing-Lists). What intrigues me (and scares me at the same time as well) is the fact that we might just be repeating the loop - without having much on-ground activity and thus, trapped in (what I like to call) an “analysis paralysis”.

But rewriting and maintaining are the same process of creating content, as there is a spectrum from “no constraint at all” on one side, and “this need to use that stack in that version, that css, follow that guidelines with that content” on the other.

From a newcomers perspective, these constraints would definitely look like a higher entry point to the community and from that of ours, these would be the factors why someone would refrain from working on these technologies with us. Apprenticeship is fine - but at this point in time, we are not quite in a position to offer that while possibly rewriting a huge chunk of the sites in any said frontend framework.

If the rewriting side of the spectrum is seen as more desirable (since that’s what everybody want to do each time ), we need to know why the alternatives are not.

I am too sleepy right now to be able to drop a novel sized message with a great theory, but I suspect it has to do with the agency of the people in charge, and because it seems simpler to rewrite than to learn/discover the legacy codebase (or just more fun).

We dubbed it “standardization-by-bringing-every-application-to-the-same-stack” during one of our very earliest meets but we, of course, knew where we were heading with that. It would not be wrong to state that a majority of the teammates might not know what a certain site is built on, and while it is not necessarily a bad thing - the circumstances and factors considered while making a suggestion from their end, as a result, would be superficial at best.

Having worked alongside @thunderbirdtr for some time now on the fedora-websites repo and a plethora of others with the help of other contributors, it has become quite apparent to me what can be added and what can be termed as a distant dream. I would ask folks to please consider the engineering perspective - to materialize the stilts, that the team would be rebuilding their house on.

So if you want volunteers, then what attract them (making new website) should be easy to do. If my hypothesis regarding constraints and agency is right, we need to increase the agency of the future volunteer by having the least amount of constraint, eg ruthlessly remove everything that could be seen as such.

For example, not mandate a specific build stack, just “it should generate static pages using a container”. Not mandate to use a specific footer HTML code, just “we need those links”. Not mandate a specific format and extraction of strings system for translation, just “we do not care as long as it output something compatible, and take this in input”.

We would begin with minimizing the constraints to a bare minimum of what, we cannot do without (which I think has been done by the team which has worked on previously). With the introduction of a frontend framework, we are risking adding back a lot of those constraints for our sanity’s sake but at the cost of the contributor’s participation. I am a lot inclined to make minimal changes to improve upon something that works fine, than to open up and lose all the screws/bearings while trying to fix something that is not broken in the first place.

The more constraints we have, the closer we move to the undesirable side of the spectrum. I might be controversial, but I think that a common css, a common js library, a mandatory footer (as opposed to the mandatory presence of the information) would remove some agency, and add more complexity, so might be undesirable long term.

A huge +1 to this. My practical thinking at Websites Revamp Frontend Framework - #6 by t0xic0der which I acquired with my interaction with the repositories might be seen as scepticism and I understand that, but these are the very minimum that we would want to keep in mind while discussing the short-term feasibility and the long-term viability of starting from a clean expensive slate.

Postponing upgrade from RHEL7 to RHEL8 is not a good idea in my opinion. Sooner we do this faster we can mark this as done and avoid any incompatibility in the future. Maybe instead of doing upgrade it will be faster to setup clean VMs with RHEL8 and deploy new stack there. When we are live with new website we can make decommission of RHEL7 machines.
I’m not sure how it looks from cost perspective but for sure it will mitigate risk of upgrading.

Finally! 1+ for semantic HTML +CSS without much JS. it’s not only for lightweight pages, but for accessibility sake. having a click of a button taken over by some JS behaviour is shitty implementation.

1 Like

I think this is a good opportunity to move all those websites to Openshift. This will make thing much easier for everyone, and most of them already have a working Dockerfile for the build. It should be rather quick to set this up now.
Additionally, the ongoing py2-py3 migration will need the build system to move away from rhel7 sooner than later and the container approach will make sure you have everything you need, whatever stack you choose, for the revamp.

I only pointed out that sundries was rhel7 currently because if it needs to be upgraded thats more work and on the infrastructure teams time permitting. :slight_smile:
I think the idea of moving builds into openshift is good, we already do this for docs and others.

Hey folks,

I’m pretty familiar with ReactJS but not opposed to going with VueJS if it has upsides that we want to take advantage of. Ryan used to know some ReactJS too if I remember correctly.

I’ve been advocating the use of ReactJS for our apps for a while now (years?) but in places where I think it makes sense: apps that have a lot of user interaction and forms. I think it would be a much more relevent addition to Bodhi than to getfedora, for example.

2 Likes

Just FYI. I think there is a known problem with ReactJS and Google Translate.

https://bugs.chromium.org/p/chromium/issues/detail?id=872770

If that means of translating web pages is important, that might be a reason to avoid such JS.

1 Like