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.
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.
Xibo has a basic set of common functions contained within
$(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.
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:
As Xibo reaches more users worldwide, we periodically review these decisions to make sure we’re still doing the right thing for the platform.
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: