Core idea
read/write batching
Platform under construction
Memory Leaks & Layout Thrashing
Memory leaks keep unused objects alive, while layout thrashing repeatedly forces the browser to recalculate layout.
const width = element.offsetWidth;
requestAnimationFrame(() => {
element.style.width = `${width + 20}px`;
});
Security & Performance
Memory Leaks & Layout Thrashing is part of shipping JavaScript responsibly.
Memory leaks keep unused objects alive, while layout thrashing repeatedly forces the browser to recalculate layout.
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.
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 width = element.offsetWidth;
requestAnimationFrame(() => {
element.style.width = `${width + 20}px`;
});
Avoid the risky shortcut
items.forEach(item => {
item.style.width = item.offsetWidth + 20 + "px";
});
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 width = element.offsetWidth;
requestAnimationFrame(() => {
element.style.width = `${width + 20}px`;
});
Risky pattern
This version introduces security, performance or maintenance risk.
items.forEach(item => {
item.style.width = item.offsetWidth + 20 + "px";
});
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.
- Find the risky line in the weak example.
- Rewrite it using the safer pattern.
- Add one measurement or review step before shipping.
Try it yourself
Experiment with Memory Leaks & Layout Thrashing
Self-check
Before you continue, prove that you understand Memory Leaks & Layout Thrashing.
Answer these before moving to the next security and performance lesson.
- What is the main risk in Memory Leaks & Layout Thrashing?
- Which API or habit reduces that risk?
- What would you measure or review in production?
- How can this affect users directly?
- Why is the weak example dangerous or slow?
Senior audit upgrade
Extra production context for Memory Leaks & Layout Thrashing.
Cleanup checklist
- Remove event listeners when a component is destroyed.
- Clear timers and abort pending async work.
- Disconnect observers.
- Avoid detached DOM references.
- Batch layout reads before layout writes.
Source references
Use these references when browser support, syntax details or proposal status matters.
Chapter checkpoint
Security & Performance checkpoint
Finish this chapter by turning the lessons into a small practical proof.
Build
Trace one untrusted value through a UI and measure one interaction with the Performance API.
Deliverables
- input-to-output trace
- safe output decision
- performance mark/measure
Quality checks
- textContent default
- no eval/string timers
- cleanup plan for listeners/timers
Review question
Can you prove the value is not executed as code?