Last week, in the "Inside Xibo" Series, we looked in detail at XMR and Push Messaging. In part 2 of the series, we will look at Front End Frameworks.
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.
What does Xibo use?
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.
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. 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:
If you’re thinking how this might not work with a larger engineering department, with more developers and more independent teams, then I’d wholeheartedly agree… but we aren’t there… yet!
Have you found a place for any frameworks?
Yes, we have!
- We were designing from scratch so had a clean slate to work with
- We are lucky enough to have a dedicated front end developer on the team with extensive experience in both Vue, React and Angular
- Adspace is a central service covering a global audience, so client side performance and responsiveness is a much higher priority
A future “Inside Xibo Adspace” series will look at this and also our decision to use Kubernetes and micro services for Adspace.
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:
Inside Xibo is a series of articles written by the Xibo Development team to give users, system administrators and developers an insight into how Xibo works and the architecture decisions we take to make Xibo the best in class. We welcome your comments below!