FSM Full Stack Masterclass
Platform under construction
JavaScript course badge

Security & Performance

Advanced

Safe DOM Updates

Safe DOM updates keep data as text unless trusted HTML is explicitly needed and sanitized.

const item = document.createElement("li");
item.textContent = label;
list.append(item);

Security & Performance

Safe DOM Updates is part of shipping JavaScript responsibly.

Safe DOM updates keep data as text unless trusted HTML is explicitly needed and sanitized.

Security and performance are not cleanup tasks at the end. They influence which APIs you choose, how you update the DOM and how much work runs on the main thread.

The goal is practical judgement: safe output, measured code, controlled permissions and browser work that does not punish the user.

Core idea

createElement()

Security boundary

Treat input, network data and third-party code as untrusted until proven otherwise.

Performance boundary

Measure before optimizing, then remove unnecessary work.

Production habit

Use defaults that are safe, explicit and easy to review.

Examples

Safe and fast JavaScript is a design choice.

Prefer the safer production pattern

const item = document.createElement("li");
item.textContent = label;
list.append(item);

Avoid the risky shortcut

list.innerHTML += `<li>${label}</li>`;
// Data is mixed directly into HTML.

Code patterns

Reusable examples for quick reference.

Use these examples as a practical reference for safer DOM updates, browser policies and performance habits.

Safer pattern

Use this direction in real code.

const item = document.createElement("li");
item.textContent = label;
list.append(item);

Risky pattern

This version introduces security, performance or maintenance risk.

list.innerHTML += `<li>${label}</li>`;
// Data is mixed directly into HTML.

Measure first

Performance work should start with numbers.

const start = performance.now();
runWork();
console.log(performance.now() - start);

Prefer explicit trust boundaries

Keep unsafe operations rare and visible.

function renderText(element, value) {
  element.textContent = value;
}

Rules that matter

Production JavaScript needs boundaries.

Every script runs inside a browser, on a real device, with real data. That makes security and performance part of the feature.

Never trust user input

Render untrusted values as text unless sanitized by a proven process.

Avoid string-to-code execution

eval and similar patterns expand the attack surface.

Understand browser security boundaries

CORS and CSP are server/browser policies, not client hacks.

Measure performance

Use browser tools and APIs before guessing.

Reduce main-thread work

Batch DOM reads and writes, debounce noisy events and avoid unnecessary loops.

Review dependencies and third-party scripts

Security and performance problems often enter through packages.

Production thinking

Ship code users can trust.

Why does this matter?

Security bugs and slow interfaces both destroy trust. Users may not see the code, but they feel the consequences immediately.

Accessibility

Fast, stable JavaScript helps keyboard users, screen readers and users on lower-powered devices. Security UI also needs clear messages.

Production note

Production JavaScript should use CSP, safe DOM updates, measured performance and code review around risky APIs.

SEO note

A fast, stable page is easier for users and crawlers to process. Critical content should not depend on fragile client code.

Live code lab

Change the HTML, CSS or JavaScript and run the result.

The preview runs inside an isolated iframe. The JavaScript is placed inside the HTML editor for now, so every example stays together and remains easy to understand.

Mini assignment

Try this now.

  • Change the input or value and run the example again.
  • Explain which boundary is being protected.
  • Name one production check you would add.

Practice assignment

Do this before moving to the next topic.

  1. Find the risky line in the weak example.
  2. Rewrite it using the safer pattern.
  3. Add one measurement or review step before shipping.

Try it yourself

Experiment with Safe DOM Updates

Live preview

Self-check

Before you continue, prove that you understand Safe DOM Updates.

Advanced

Answer these before moving to the next security and performance lesson.

  1. What is the main risk in Safe DOM Updates?
  2. Which API or habit reduces that risk?
  3. What would you measure or review in production?
  4. How can this affect users directly?
  5. Why is the weak example dangerous or slow?

Senior audit upgrade

Extra production context for Safe DOM Updates.

Safe DOM default

Prefer textContent, createElement, templates and replaceChildren for normal UI rendering. Reach for innerHTML only when the markup is controlled and the risk is understood.

const item = document.createElement("li");
item.textContent = userInput;

list.replaceChildren(item);

Safe rendering checklist

  • Use textContent for plain text.
  • Use createElement or template cloning for markup.
  • Use replaceChildren for repeatable rendering.
  • Avoid concatenating untrusted strings into innerHTML.