If we were still in 2003, we could simply substitute variable data for PHP variables, wrap this into <?php> tags and call it a day. However, in this scenario, we are in 2019, but adamantly opposed to using front-end frameworks.

I will ignore the AJAX part of this task for reasons of space, and also because it’s not very relevant to the topic at hand. We’ll keep our data inside a JSON const in our script file.



{

name: 'Anna Komnene',

avatar: '

description: '"The truth is all barbarians are usually fickle and by nature unable to keep their pledges."',

},

{

name: 'John the Grammarian',

// ... const data = [name: 'Anna Komnene',avatar: ' https://i.imgur.com/dE1Xhg4.png' description: '"The truth is all barbarians are usually fickle and by nature unable to keep their pledges."',},name: 'John the Grammarian',// ...

Let’s begin with a very naïve approach, converting the hypothetical PHP example to JavaScript. We could do something very stupid like this:

This is fairly straight-forward. We can utilize template literals to render strings directly to HTML. It’s fairly easy to implement and understandable at a glance.

However, any seasoned JavaScript developer will cringe at this implementation. We do not sanitize user input and do not do anything besides echoing out what is in the strings. If our data contained any user-generated content, we’d be wide open for a cross-site scripting (XSS) attack. Sanitizing this data would not be particularly difficult, but if you were to attempt it on a larger scale you would realise quickly that it does not scale well.

On top of that, innerHTML essentially recreates the DOM tree from scratch every time. This means that if we had any existing event listeners attached to these nodes, they would be overwritten. We can do better.

This is a much cleaner approach, although it still requires quite a lot of repetition. Using textContent ensures that any stray XSS code that would find its way into our data does not get executed. Also, building the DOM manually is much more efficient and clean than doing it with innerHTML .

However, you’ll notice that there is a lot of repetition in this as well. For each of these elements we repeat the same code: each uses createElement and each uses appendChild . We can create a function to simplify this.

This helped slightly: we created a function called createElement which takes an element type (basically the HTML tag), the reference to the element’s desired parent and a function which allows us to operate on this element further.

Theoretically, because we are using a function to operate on the newly created element, we could also do something like this:

However, you’ll notice that we only really do two things here: assign attributes and modify the text content. So we could generalize this even further.

Our code is starting to get more complex. Our createElement function has gained two new pieces: first we iterate over the attributes object passed into it and add them to our DOM element. Then, if there is content to add, we add it.

However with this approach, you’ll notice that we lost the interesting property of chaining createElement functions together. That would be a desirable feature — because since the function is now more robust, we could, ideally, create an approximation of the DOM tree by nesting these functions.