Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m

Next lesson playing in 5 seconds

  • Overview
  • Transcript

2.1 How We Built the Daily Mail CMS

In this lesson, I’ll explain why the Daily Mail team decided to roll their own JavaScript framework. We’ll take a look at the scope of the project, its requirements, and why the Daily Mail didn’t think any of the existing frameworks would be a good solution.

After that, I’ll show you some of the features that make the Milo framework unique, such as its powerful models, deep two-way data binding, and facetted component architecture.

Related Links

2.1 How We Built the Daily Mail CMS

At a time when there are more JavaScript frameworks than you can count on two hands, why would we decide to roll our own? To answer that, let's take a look at the Mail Online and talk about what it requires from a content management system. The Mail Online is the most visited English speaking online newspaper in the world. When we were tasked with rebuilding the CMS from scratch, Daily Mail journalists were publishing about 600 new articles every day. That number has now risen to closer to 1,000 new articles every day. The site gets around 200 million unique monthly visitors, and it has probably the longest home page on the web. If you take a look at the articles of the Mail Online, you find a lot of similar features in them, but there is no one single pattern that is followed consistently for article layout. There are a lot of different little features and inserts that they can use such as this one here, images can be placed as single images like this or split in two or three. You can put pull-quotes in, often different text formatting is used for the different sections, female for example, likes to use pink text. And while we try to push for a more ordered approach, something that could be driven by data and have maybe an arrangement of different templates to choose from, this was a no go. The CMS had to be completely with wheezy wiki and as intuitive as possible. So everything in the article editing experience should be interactive with a drag drop interface,and all the various parts of the article need to have their own functionality and their own contextual inspector, that shows up when selected. So when thinking about how we would implement this, we saw a lot of functionality that was not offered by any existing frameworks. We would need live dynamic UI, we would have a lot of similar components with slightly different needs. So a paragraph is quite similar to a bullet point but it will have its own configuration and be different in subtle ways. We also saw the need for complex, deep data connections, since the article itself has quit a complex model, then different parts of the article will have their own models that will need to connect up to it. So what were we to do? Well, we had a look at some existing frameworks at the time, we looked at AngularJS. We all enjoyed using Angular for small to medium sized applications, but found it became quite cumbersome in large applications. It doesn't offer model to model connections, you end up replacing listeners and callbacks with watches instead. Another thing we didn't like about Angular was a lack of introspection. Directives themselves end up becoming black boxes. You don't get back an instance of something that you can play with and manipulate in the console for debugging purposes. The CMS that we were replacing was written In Ext JS and I think the version was 3.4. I'd personally worked in Ext JS quite a few times and found it quite a heavy and cumbersome framework. It's definitely very powerful but I don't like the steep inheritance hierarchy that it encourages, as this approach would have made it very difficult for us to plan out our component class structures. I'm also not a fan of using JavaScript to build all of my layout. As Ext JS abstracts away from you, the need to build HTML layouts, some people like this but I prefer to work with HTML directly. We did also consider using Backbone, but given how simple it is we would've ended up writing our own framework over the top of it anyway. So we decided to roll our own. This is something that we could have only done at Mail Online, or a similar working environment. Projects are very much developer driven, with very little oversight on the technical details by project managers or the CTO. You choose the right technology for the job, even if that means writing your own framework. While it means we have a lot more freedom in the way we work, we also have a lot more responsibility. Let's take a look at some of the features of Milo JS and how they helped us build the CMS of the Mail Online. Right now, I'm in the tutorials folder of the Milo JS repository. I made these tutorials to help with the on boarding process of new developers to the team. Let's take a look at some of the features of Milo models, here you can see we're creating a new model, new Milo model. Milo models allow you to access any point in the model, using the usual syntax you would use for property access. The model itself acts as a function, which when called will return a model path. A model path is just like a model and will have all of the same properties and methods as a model. So we can call the get method of this model path user.address.straight, now in this case it's going to be undefined because we haven't set any data on this model yet. So we were able to do deep safe property access using Milo models. So we can also set to the model directly like this, drilling down to the property we want to set, and setting Victoria Street. Now when we call get, it will return an object with a property address, and that will be an object, and it will return the property street, set to Victoria Street. So the Milo model automatically creates all of the structure for you. We can also do array syntax, interpolation, a more complex form of interpolation, and we can also listen to changes in models using Milo's built in messenger. In Mil,o just about everything gets the messenger class methods mixed into it. So all of the components in the models and all sorts of other things will have a messenger attached. So, in the case of a model, we can write user.on and listen to the change in the friends property of the user model. Whenever it changes, we're going to get information on the data change. So, we can push Superman into friends, and Milo's not only going to automatically set up an array, because you've used push which is an array method, but it's also gonna fire at whole bunch of messages about all the various changes that are happening to the model. We can also subscribe using a regular expression or we can subscribe to messages using star patterns. So he would be listening to not the changes of the actual friends array but each of the child elements in the array. And as I said before, the model path has all the same valid functionality of a model. So, we can get ourselves the path of friends and then listen to all changes from that point down. If I open up this models tutorial page, you'll see all the various messages firing. So here we can see, when we pushed into the friends array, we had added count of 1, index 3, the new value of the array, anything that was removed, and the operation that happened on the array. Here we can see the Queen of England being added to the friends array. And we see that it was a changed operation, with the old value being Superman. I mentioned before that we wanted to avoid the steep hierarchy of component classes that we saw in frameworks like Ext JS, this is why for Milo we took a faceted approach to behavior sharing for components. A component is basically a JavaScript class that manages a DOM element rather than having a hierarchy, where something like moving panel inherits from panel, which inherits from container, which inherits from box or something like that. We decided to go for a more plug and play approach with facets which can basically be attached to the component and can be configured to create different behaviors using the same classes. I like to think of facets as being configurable mix-ins on steroids. Each facet will have a reference to it's owner component, and through that can operate on the DOM element. Some of the basic facets that come with Milo are the data facet and the container facet. Container facet is what creates scope around child components. It means that this nested parent component, will have access to these child components. And the data facet is what allows access to DOM data and the ability to set DOM data. Here the container is creating a hierarchy, it means if we set on the data facet and object with title and description, then this title and description will be propagated to the DOM and you'll see them here in this heading in paragraph. When you create a component class such as this one for the header of an article, you can see we can configure the facets such as drop and editable facet making them very reusable. So for the editable facet, which manages all editable elements in the article, we can prevent Enter key for headers. Whereas the paragraph, editable facet would not do this because when you hit Enter in a paragraph you should create a new paragraph. We can also subscribe to messages in the facet configurations. Possibly the most powerful part of Milo, however, is the milo.minder, and the connectors that we can use to deeply connect any two data sources. So when we call milo.minder, we need to pass it in one data source, which can be a model or it can be a data facet of a component, or it can also be a model path which is a subset of a model. And then we choose a direction and depth, so in this case, it's one level of depth which basically means linking scalar values and the direction of the data binding. So this is one way direction from the name input to the name label. This creates a one way connection from this input up here to this label over here. Here we've joined a model, userModel and we've bound it deeply to userProfile.data, userProfile.data is this user profile component which has the data facet and these two values here. So by setting Jason Green and then later on setting the lastName of this userModel to Verde, you can see it's Green and then it becomes Verde. This shows how we can work on data rather than having to work on the DOM by binding it a Milo model to the DOM. And then of course we can have two way data connection. So here we're binding our first form to a formModel and then binding that formModel to a second form. We've also set up a listener on all changes of that formModel, so we can see it change by outputting its stringified data into another component. So here is our first form and here is our second form. As I type you can see not only are we populating the second form, but we're also populating the formModel. We have basically created a data graph, connecting all three of them together in a two way deep data connection. I could go on and on about the depth of features that Milo JS offers, but I'll leave it there for now. Well, I hope this video is answered some of the questions as to why anyone would be crazy enough to roll their own fully featured JavaScript framework. In other videos, I'd like to cover some of the challenges we faced. And exactly what's going on under the hood of Milo.JS. Thanks for watching and bye for now.

Back to the top