This article first appeared on our blog in July 2021, and has been moved to community and updated in August 2022.
React, Vue, Angular, Ember, another day another front end framework…But what does Xibo use for our Content Management System (CMS) and why? Before we answer this, let’s take a step back.
Some background
First of all, this topic is highly opinionated! Ask 10 developers about frameworks, SPAs, MPAs or native and you’ll get 10 different opinions. At Xibo we don’t use any of the most popular front end frameworks, and depending on where you draw the line, we don’t use a framework at all.
The benefits of adopting a front end framework are extensive and compelling, however adopting one does have to be weighed against the current state of both the software and the core team that maintains it, and that is what we’ve based our decision on at Xibo.
Xibo is a multi page application rather than a single page application. There are plenty of resources to find out what that means and I’ll link a few below. We use jQuery, Bootstrap and a number of plugins for both. There is some debate over whether either of these are frameworks and the general consensus is that they aren’t, although Bootstrap says they are a framework, and jQuery says that they are a library. My view is that jQuery is a library, Bootstrap is a presentation framework and therefore Xibo does not use a front end framework in the sense that most front end developers would recognise.
What does Xibo use?
Xibo has a basic set of common functions contained within xibo-cms.js which are reused across each page and function. This is by no means a framework, but there are functions used throughout the user interface to initialise the dynamic parts of pages, and this allows us to have some consistency with a very light touch. Each page itself can include JavaScript and we make extensive use of jQuery’s $(document).ready(); to do something when the DOM is ready. Being multi page the back end web entry-point handles routing and rendering HTML to output via Twig, and we have some macros in Twig which define components and ensure those are output in a consistent way.
A good example is a date/time picker - in Xibo we use a Twig macro to output consistent HTML each time we want a picker, including a defined class name. On page load, or on form load we call XiboInitialise from inside xibo-cms.js, which looks for picker classes and uses a bootstrap plugin to render the picker. We do this for all sorts of form fields, forms themselves, dialogs, etc. This is a “light touch” way of having a very simple framework for our small team of developers.
Furthermore, we use webpack to build some of our JavaScript into a bundle, and have aspirations to build all of our JavaScript in this way in the future, but currently some page specific JavaScript is rendered into HTML by the server from Twig. The Layout and Playlist editors are predominantly ES6 native JavaScript.
Xibo Players can all embed a web browser, and most of our JavaScript on the player is native, although we sparingly use jQuery here too. The web engine included in player hardware is usually old, so we can’t make use of most of the new language features yet.
So, why no front end framework?
We have certainly explored switching to a front end framework, but there are two key reasons we haven’t done so yet:
- Xibo predates the front end framework concept by a number of years and we have a lot of user interfaces to replace.
- Xibo has an in-house development team with expertise in the approach outlined above - switching to a front end framework would mean some retraining.
- It would be an extensive project to re-implement using a framework and the benefits of doing so haven’t been as great as implementing other features.
Of course there are many other considerations, some of which are worth mentioning:
- Front end frameworks on the player are not practical or necessary, so we will always be dealing with native JavaScript
- The Layout and Playlist editors are sufficiently unique to require native JavaScript even if the rest of the user interface used a front end framework
As Xibo reaches more users worldwide, we periodically review these decisions to make sure we’re still doing the right thing for the platform.
Into the future?
It is hard to imagine a future where we decide to replace the CMS user interface with something completely new, but if we did, it would likely make use of a front end framework at that point.
Topics discussed in this article: