One of the major highlights of the upcoming Fedora Websites 3.0 is the fact that we are doing away with our classic barebones JavaScript function-only-based approach in favour of a more comprehensive implementation using JavaScript frontend frameworks. The following are the cardinal of all the factors attributed to us deciding that we indeed need these for our refreshed implementation.
Standardized and efficient workflows suggested by the frontend framework significantly reduce the amount of code to be written and are a lot more dynamic to accommodate for solving multiple problems simultaneously with reusability.
Consistent and reliable approach leads contributors who join later in the development and maintenance cycle to stick to a standard way of doing things, thus making the codebase a lot more welcoming to the newcomers to the community.
Definitive and supported ways of fetching the frontend framework dependencies mean that they would circumvent possible security flaws, enhance contributor experience and provide enriching features by constantly staying up-to-date.
Seamless functioning of the application frontend while using an active backend or even in the absence of one would lead to smoother animations and quicker interactions, adaptable to localization and internationalization workflows.
In the presence of a variety of frontend frameworks developed, maintained and released frequently, it is essential for selecting the toolsets that would enable/help our contributors to achieve the development purpose as effortlessly as possible. Our decision on which ones to settle on for our refreshed implementation was attributed mostly to the following of all the factors considered.
Quality documentation and an expansive set of examples are foremost for the contributors to understand how they can best utilize a certain frontend framework.
Pleasant learning curve would encourage/challenge contributors to use a certain frontend framework as they constantly get to learn stuff and contribute.
Frontend frameworks with reliable support would be production-tested and the community is likely to onboard more contributors acquainted with the technology.
Exposure to working with popular frontend frameworks that are actively used within the industry might help reward newbie members and incentivize contributors.
Elaborate set of features present in a frontend framework while not being a one-stop solution to everything is vital for developing flexibility and dynamic workflow.
In-practice productivity is a different yet crucial ball game altogether as that would indicate how fast contributors can come up with designs and effective prototypes.
Tendency to support other JavaScript libraries and include flexible styling using custom CSS elements would determine the extent of our creative implementation.
Playing well with a Pythonic backend and infrastructure to facilitate seamless deployment and maintenance would state how two different technological stacks bind.
Accommodating a diverse community with the presence of reliable localization and internationalization support that works well with our existing workflows.
Possibility of implementing accessibility-related support and efficient load times to support working on weaker internet connections would help enhance user experience.
Which frontend framework do we commit ourselves to?
Now that we were able to determine that our refreshed implementation would be benefitted from the inclusion of frontend frameworks, it is now time for us to understand which frontend frameworks and supported libraries would better suit our workflow. We accounted for the factors stated above to help decide which to pick and for what it’s worth - we started with the most popular three (as of composing this writeup) - AngularJS, ReactJS and VueJS.
AngularJS
Why would we want to use it?
Being one of the most widely used frontend frameworks and recognized due to being backed by Google, it has a huge community of developers and maintainers.
It is comparatively easy to find an answer to questions/concerns regarding the frontend framework in the presence of a lot of supporters and great popularity.
Framework takes care of the intricacies of a certain operation where the developers need to state only the task that needs to be performed in their frontend code.
Data is instantly and automatically exchanged between the data models and the UI, thereby minimizing the complexities of handling/modifying DOM elements.
Why would we not want to use it?
Scaling high with a large-sized single-page application can be an issue and hence, this would instead necessitate the creation of a multi-page application.
With the mandatory requirement of TypeScript (a strongly-typed dialect of JavaScript), contributors would have to spend time/effort into learning that first.
Being a one-stop solution framework with features like form processing and validation, and HTTP communication, this might bind us down to an ecosystem.
Diverse features available in Angular are better suited for enterprise-grade projects and might be an overkill for the smaller-scaled websites/applications.
ReactJS
Why would we want to use it?
Being one of the most widely used frontend frameworks and recognized due to being backed by Facebook, it has a huge community of developers and maintainers.
With the use of Virtual DOM, a high-quality user experience is achieved which can work effectively faster due to changes taking place on a copy of DOM.
As the components of a ReactJS project are isolated, the changes to one part of the UI can be implemented quickly without repercussions on other elements.
Being a library and not a full framework, ReactJS keeps the door open for other functionalities to be implemented via helper libraries and an active backend.
Why would we not want to use it?
Documentation could be made better with the inclusion of examples that make developers understand how the library can be used in the best possible way.
JSX syntax, involving mixing templating code with logic, can be confusing and therefore potentially make the codebase difficult to maintain in the long run.
Without the implementation of class-based components, the codebase can become long very quickly and can hurt an Object Oriented Programming based development.
While not being template-centric in nature, this essentially necessitates the need of having advanced JavaScript knowledge among the contributors to make changes.
VueJS
Why would we want to use it?
VueJS is quickly catching up to the popularity levels of the likes of AngularJS and ReactJS and has a big community of developers and maintainers.
Being a view-oriented library, VueJS not only keeps the door open for other functionalities to be implemented via integration but also does so seamlessly.
Simplicity and low entry barrier with the use of HTML and JavaScript code, make it worth the while for people to learn quickly and implement interfaces.
Just like AngularJS, the library supports two-way data binding and the DOM changes take effect in real-time, with similar speeds to that of ReactJS.
Why would we not want to use it?
VueJS is a free and open-source project which is backed by community funding, and hence, this can be a source of concern for those committing to a library.
Lack of market adoption and lesser requirement of experienced VueJS developers might hurt incentivizing contribution from the newcomers to the community.
Lesser number of contributors to the project can also mean that there might be barriers to researching new features and possible stagnation of development.
Scaling high with a large-sized single-page application can be an issue and hence, this would instead necessitate the creation of a multi-page application.
The lightweightedness of the VueJS library is one of its advantages over other well-known frameworks. It has the added benefit of speeding up development by making it quick to load and install libraries, which benefits user experience and search engine optimization. Furthermore, optimizing the projects will not take up additional development time. How does it help?
Our websites/applications accommodate slower internet connections.
Our websites/applications provide a much snappier and smoother user experience.
Time spent on optimizing the file elements of the dependencies is reduced.
The frontend library renders objects using HTML and integrates easily by using a template system. It is a flexible framework when compared to its rivals since it lets the contributors create templates using HTML, JSX, or JS. The structure is comparable to that of AngularJS and ReactJS. Consequently, switching to VueJS from its competitors is simple. How does it help?
Our contributors can implement other functionalities using other libraries.
Our members with the knowledge of the rivals have a likeliness to contribute.
Community members are encouraged to contribute due to the ease of doing so.
Contributors might compare the engineering of VueJS to that of ReactJS development. It renders a view using a virtual DOM, just like in ReactJS. The idea is that if the virtual DOM has to be modified, it can be done without having to draw the actual DOM. The library would only need to display the differences between virtual DOM and actual DOM. How does it help?
Our websites/applications accommodate browsers on slower devices.
Our websites/applications provide a much snappier and smoother user experience.
Testing out the websites/applications with DOM changes becomes easier.
The components in VueJS can be reused effectively when programmers can find a variety of components/views that are simple to include in an already constructed website/application. The library helps developers in writing their code so they can segment an application into numerous distinct functions that can collaborate with one another as needed. How does it help?
Our contributors would have greater productivity and development experience.
Our websites/applications would look/feel consistent with the design guidelines.
Community members are encouraged to contribute due to the ease of doing so.
Please feel free to provide your opinions on the thought process the team has had in selecting a frontend framework. While this writeup culminates the discussions that have gone into making this thing happen, it also opens up those for selecting a component library to base ours upon. The Fedora Websites 3.0 effort ensures that even the discussions are bound by timelines, thus eliminating any possibilities of analysis paralysis or decision fatigue.
This looks very thorough and full of detail. Thanks for documenting. I think we should discuss whether to lift and shift this post to our documentation in the longer term.
A couple of additional points I’d make…
You mention multi page applications. This can be done with VueJS in a variety of ways. There’s potential for server side rendering which I’m not convinced we’ll need, or a simpler static build of a multi page app. Arguably the way to go for a static build approach would be Nuxt which does for VueJS what Next did for React. It requires a slightly different design approach as state isn’t passed between pages in the same way you get with the routes of an SPA.
The other thing to mention is that for contributors, having a JavaScript toolkit such as any of those under consideration on their CV is a huge plus over and above pure JavaScript skills (assuming the contributor in question is keen on showing front end skills on their CV). I’ve recently been recruiting a front end developer to my team, we were specifically looking for toolkit skills and thus any CV that didn’t show aptitude for at least one of these was considered weaker than those that did.
Hi everyone! Just my two cents - as discussed on Fedora Chat and was asked to post here.
Using a frontend framework sounds great, especially a well-known framework so that any developer can propose changes and fixes easily. But may I suggest we use something “batteries included” like the Vue-based Nuxt framework (mentioned above) over vanilla-Vue as it’s widely supported, well-documented by hosting solutions, we won’t have to use plug-ins for features like static site generation for SEO and file-system routing, and it’s more likely to be around in 10 years time than custom plug-ins we find on github.
Basically, I’d vote that we hand-roll as little as possible if we’re going with Vue and go with the most boring and non-custom thing we can find that fulfills our needs, so we can be radical and experimental in what we actually care about: creating a cool web presence for fedora
.