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

Next lesson playing in 5 seconds

  • Overview
  • Transcript

1.2 Create a New JavaScript Framework: 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.

Code Snippet

The following snippet demonstrates the interface for data i/o for Milo models.

var m = new milo.Model();
m('.a.b.c[3].d').set('Safe deep data access.');
m.on('.a.b.c[*]', function (msg, data) {
    //Deep data change subscriptions including wildcards

Now, to establish a data binding between the model and a UI component, all that’s needed is a call to Milo’s data minder. The following snippet establishes a two-way binding, two levels deep (e.g. between arrays of objects).

milo.minder(m, '<<<->>>', todos.data);

Below is an example of how to declare a Milo component. This showcases Milo’s facetted component architecture, a strategy that allows for versatility and flexible composition of functionality.

var ComponentClass = milo.createComponentClass({
    className: 'ComponentClass',
    facets: { 
        data: {}, // empty object or undefined means no config needed
        item: {},
        css: {
            classes: { // css facet is linked to the model to allow
                       // data driven design
                '.userHandle': isAuthor
    methods: {
        init: init,
        start: start

Related Links

1.Create a New JavaScript Framework: How We Built the Daily Mail CMS
2 lessons, 11:57


Create a New JavaScript Framework: How We Built the Daily Mail CMS

1.2 Create a New JavaScript Framework: How We Built the Daily Mail CMS

[SOUND] Hi and welcome to this coffee break case study video about building the CMS of the MailOnline 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 MailOnline and talk about what it requires from a content management system. The MailOnline 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 MailOnline, you find a lot of similar features in them. But there is no one single pattern that has 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 WYSIWYG 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'll 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 quite a complex model and different parts of the article will have their own models that will need to connect up to it so what are we to do? Well we have to look at some existing frameworks at the time we looked at angular JS 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 call-backs 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 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've 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 lay out. App 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 have ended up writing our own framework over the top of it anyway. So we decided to roll their own. This is something that we could have only done at the my online or similar working environment. Projects a 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. Well that 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 mother JS and how they helped us build the same mess of the MailOnline. Right now, in the to tutorial 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 my lower 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 cold, will return a model path. The 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.street. 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 mylar 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 or return an object with the property address and that will be an object that will return the property street set to Victoria Street. So the Milo model automatically creates all of the build the structure for you. We can also do array syntax, interpolation, more complex form of interpolation. And we can also listen to changes in models using Milo's built in messenger. In Milo 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 going to fire out a 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 a 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 model's tutorial page you'll see all the various messages firing. So here we can see where 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. And 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 X 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 n 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, each facet will have a reference to its own a component and through that can operate on the DOM element. Some of the basic facets that come with Milo are data facet and the container facet. Contain a 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 dumb data and the ability to set dumb data. Here the container is creating a hierarchy. It means if we set on the data facet an 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 and 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 an 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 it 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 to 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, user model and we've bound it deeply to user profile data. User profile data is this user profile component which has a data facet and these two values here. So, by setting Jason Green and then later on setting the last name of this user model to Verde. You can see it's green and then it becomes their day. This shows how we can work on data rather than having to work on the DOM by binding it a mother 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 form model, and then binding that form model, to a second form, We've also set up a listener on all changes of the form model, so we can see a change, via putting it string of fight data, into another component. So here's our first form and here's our second form. As I type, you can see not only are we populating the second form, but we're also populating the form model. 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 has 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