DOMHelpers

Appearance

Sponsor

Sponsor

The Pain of Plain JavaScript Element Creation ​

Quick Start (30 seconds) ​

Before learning how Dom Helpers helps, spend 30 seconds looking at what creating elements in plain JavaScript actually looks like when you need to build something real:

javascript
// Plain JavaScript: creating a simple user card
const card = document.createElement('div');
card.className = 'user-card';

const avatar = document.createElement('img');
avatar.src = user.avatar;
avatar.alt = user.name;
avatar.style.width = '80px';
avatar.style.borderRadius = '50%';

const name = document.createElement('h3');
name.textContent = user.name;

const email = document.createElement('p');
email.textContent = user.email;
email.style.color = '#666';

const button = document.createElement('button');
button.textContent = 'View Profile';
button.addEventListener('click', () => openProfile(user.id));

card.appendChild(avatar);
card.appendChild(name);
card.appendChild(email);
card.appendChild(button);

document.body.appendChild(card);

That is 21 lines of code for a simple card with four elements. Now imagine doing this for a whole page.

What is the Problem? ​

The browser's native method for creating elements is document.createElement(). It has existed for decades and it works — but it was never designed with developer experience in mind. It was designed to be a minimal, low-level primitive.

This section walks through the specific pain points that appear when you use it in real projects.

Pain Point 1: One Property at a Time ​

document.createElement() creates an element, but it creates it completely empty. You have to set every property manually, one line at a time.

javascript
// Creating a heading in plain JavaScript
const heading = document.createElement('h1');    // Create — empty
heading.textContent = 'Welcome!';               // Set text
heading.id = 'page-title';                       // Set ID
heading.className = 'title title--main';        // Set classes
heading.style.color = '#333';                   // Set one style
heading.style.fontSize = '2rem';                // Set another style
heading.style.fontWeight = 'bold';              // And another

What's the problem?

Every new property requires a new line. If you need 10 properties, you write 10 lines. The element and its configuration are spread across many statements instead of expressed as one clear unit.

The intent is fragmented. You cannot look at one thing and understand what this element is meant to look like. You have to read through seven separate assignments to build a mental picture.

Pain Point 2: Creating Multiple Elements is Exhausting ​

Real UI components are not single elements — they are trees of elements nested inside each other. Creating a navigation bar, a form, a card grid, or a modal means creating many elements and wiring them together.

javascript
// Creating a simple three-field form in plain JavaScript
const form = document.createElement('form');

const nameLabel = document.createElement('label');
nameLabel.textContent = 'Name';
nameLabel.setAttribute('for', 'name');

const nameInput = document.createElement('input');
nameInput.type = 'text';
nameInput.id = 'name';
nameInput.placeholder = 'Enter your name';
nameInput.style.width = '100%';
nameInput.style.padding = '8px';

const emailLabel = document.createElement('label');
emailLabel.textContent = 'Email';
emailLabel.setAttribute('for', 'email');

const emailInput = document.createElement('input');
emailInput.type = 'email';
emailInput.id = 'email';
emailInput.placeholder = 'Enter your email';
emailInput.style.width = '100%';
emailInput.style.padding = '8px';

const submitButton = document.createElement('button');
submitButton.type = 'submit';
submitButton.textContent = 'Send';
submitButton.style.padding = '10px 20px';
submitButton.style.backgroundColor = '#007bff';
submitButton.style.color = 'white';
submitButton.style.border = 'none';
submitButton.style.cursor = 'pointer';

form.appendChild(nameLabel);
form.appendChild(nameInput);
form.appendChild(emailLabel);
form.appendChild(emailInput);
form.appendChild(submitButton);

document.body.appendChild(form);

That is 30 lines of code for a form with two fields. Look at the pattern: create, set properties, repeat. The signal-to-noise ratio is very low — most of the code is boilerplate, not meaningful logic.

The flow looks like this:

createElement('form')
    ↓
createElement('label') → set text → set for
    ↓
createElement('input') → set type → set id → set placeholder → set style → set style
    ↓
createElement('label') → set text → set for
    ↓
createElement('input') → set type → set id → set placeholder → set style → set style
    ↓
createElement('button') → set type → set text → set style × 5
    ↓
appendChild × 5
    ↓
appendChild to body

The actual structure and intent are buried under layers of repetitive mechanics.

When you create elements one by one in plain JavaScript, there is no natural way to group them. You end up with a collection of loose variables:

javascript
const header = document.createElement('header');
const nav = document.createElement('nav');
const logo = document.createElement('div');
const menu = document.createElement('ul');
const homeItem = document.createElement('li');
const aboutItem = document.createElement('li');
const contactItem = document.createElement('li');

Seven variables floating in scope. Now you have to remember what each one is and what it belongs to. If you make a typo in a variable name, the error only appears at runtime when you try to use it.

There is no structure that says "these elements belong to this component."

Pain Point 4: The innerHTML Temptation — And Its Cost ​

Faced with the verbosity of document.createElement(), many developers reach for innerHTML:

javascript
// Tempting shortcut
container.innerHTML = `
  <div class="card">
    <img src="${user.avatar}" alt="${user.name}">
    <h3>${user.name}</h3>
    <p>${user.email}</p>
    <button onclick="openProfile(${user.id})">View</button>
  </div>
`;

This is shorter and it looks like HTML — which is familiar. But it has real problems.

The issues with innerHTML:

Problem 1: Security Risk
- If any user-provided data is inserted into an innerHTML string,
  attackers can inject malicious HTML or JavaScript
- This is called Cross-Site Scripting (XSS)
- Example: if user.name is '<script>stealData()</script>'
           it will execute as code

Problem 2: Destroys Event Listeners
- Any event listeners attached to existing child elements are removed
  when innerHTML is set
- This causes subtle, hard-to-find bugs

Problem 3: Logic Inside Strings
- JavaScript logic is embedded inside HTML string templates
- This mixes concerns and makes code harder to test and maintain

Problem 4: No Element References
- After setting innerHTML, you have to query the DOM to get references
  to the new elements if you need to manipulate them later
- Example: container.querySelector('button').addEventListener(...)

innerHTML trades one set of problems for another.

Pain Point 5: Event Listeners are Separate from Their Elements ​

With document.createElement(), event listeners are attached after the element is created:

javascript
const button = document.createElement('button');
button.textContent = 'Click Me';
button.style.padding = '10px 20px';

// The event listener is attached separately, away from the element definition
button.addEventListener('click', handleClick);
button.addEventListener('mouseenter', handleHover);
button.addEventListener('mouseleave', handleHoverEnd);

When you are reading this code, the element's appearance and its behavior are described in different places. To understand what the button does, you have to read both the element creation block and the event listener section — and in a real codebase, those might be far apart.

Pain Point 6: Updating Elements Requires Finding Them Again ​

After you create an element and add it to the DOM, updating it later means either keeping a variable reference or querying the DOM again:

javascript
// Create and append
const button = document.createElement('button');
button.textContent = 'Submit';
document.body.appendChild(button);

// Later, when you want to update it...
// Option A: Hope you still have the reference
button.textContent = 'Submitting...';
button.disabled = true;

// Option B: Query the DOM again (slower, and what if there are multiple buttons?)
const btn = document.querySelector('button');
btn.textContent = 'Submitting...';
btn.disabled = true;

// Option C: Give it an ID and use getElementById
const btn2 = document.getElementById('submitBtn');
btn2.textContent = 'Submitting...';
btn2.disabled = true;

None of these approaches give you a clean, structured way to update multiple properties at once.

The Pattern of Problems ​

When you step back and look at all these pain points together, a pattern emerges:

Plain JavaScript createElement has:

❌ No way to express an element as a single unit
❌ No grouping of related elements
❌ No declarative property configuration
❌ Verbose, repetitive syntax for every property
❌ Event listeners separated from element definitions
❌ No structured way to manage multiple elements together
❌ No built-in way to update elements after creation

None of these are bugs. Plain JavaScript does exactly what it promises. The issue is that it is a very low-level API, and building real applications directly on top of it requires a lot of manual, repetitive work.

What Dom Helpers Does Instead ​

Dom Helpers solves each of these pain points with a single, coherent approach:

The same form as before — with Dom Helpers:

javascript
const form = createElement.bulk({
  FORM: {},

  LABEL_NAME: {
    textContent: 'Name',
    setAttribute: { for: 'name' }
  },

  INPUT_NAME: {
    type: 'text',
    id: 'name',
    placeholder: 'Enter your name',
    style: { width: '100%', padding: '8px' }
  },

  LABEL_EMAIL: {
    textContent: 'Email',
    setAttribute: { for: 'email' }
  },

  INPUT_EMAIL: {
    type: 'email',
    id: 'email',
    placeholder: 'Enter your email',
    style: { width: '100%', padding: '8px' }
  },

  BUTTON_SUBMIT: {
    type: 'submit',
    textContent: 'Send',
    style: {
      padding: '10px 20px',
      backgroundColor: '#007bff',
      color: 'white',
      border: 'none',
      cursor: 'pointer'
    }
  }
});

form.FORM.append(
  form.LABEL_NAME,
  form.INPUT_NAME,
  form.LABEL_EMAIL,
  form.INPUT_EMAIL,
  form.BUTTON_SUBMIT
);

document.body.appendChild(form.FORM);

What changed:

Before → After

❌ Scattered one-by-one property assignments
✅ Each element is expressed as a single configuration object

❌ No grouping of related elements
✅ All elements are accessible by name on the returned object

❌ Event listeners separated from element definitions
✅ addEventListener lives inside the element config

❌ Verbose, repetitive syntax
✅ Declarative — describe what you want, not how to build it

❌ No structured way to manage multiple elements together
✅ The returned object holds all elements with named keys

The Core Insight ​

The pain of plain JavaScript element creation is not that any individual step is hard. Each step is simple. The pain comes from doing all those simple steps manually, every time, for every element.

Dom Helpers removes that manual work by accepting a configuration object that describes everything about your elements at once. Instead of commanding the browser to do one thing at a time, you describe the result you want — and Dom Helpers does the work.

One-line rule to remember:

Plain JavaScript tells the browser how to build elements, step by step. Dom Helpers lets you describe what you want the elements to be.

What's Next? ​

Now that you understand the problem clearly, let's look at the solutions — starting with the simplest entry point.