Inside Xibo - Front end framework

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.

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. 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.
• At the time of writing we have a team of 4 full time developers - 2x back end, 1x front end and 1x full stack. Our excellent front end developer specialises in native JavaScript. Taking on a front end framework would mean retraining for the team.

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

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!

Xibo Adspace is the newest product in our suite and has a front end written in Vue.js. Various factors fed into this decision, but the key considerations were:

• 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

We rolled this decision out into the public facing website too, so the Xibo Adspace website is written in a Jamstack framework called Gridsome.

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:

• Single Page vs Multi Page [stackoverflow]
  

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!