Copying an HTML File Per Deployment Variant Is Not a Starting Point. It Is a Decision to Maintain N Codebases.

TLDR

The "copy it for now, consolidate later" plan is never executed. The copies become load-bearing before the consolidation happens. A web component takes 30 minutes to set up at the start and eliminates the maintenance debt permanently. The 30 minutes is almost always worth it.

What the Industry Does

Copy-paste is the path of least resistance for most variant-page patterns. One working page becomes the template. New domains, new clients, new themes each get a copy. This is universal because it is fast and because the copies start identical.

The "consolidate later" plan sounds reasonable. The copies are small. The differences are minor. The consolidation can wait until the feature is proven.

It almost never happens.

Why It Fails for This Problem Class

Consolidation requires that both copies be updated to a common baseline before the shared module is extracted. After two months of independent changes, the copies are no longer identical. They have different bugs, different features, and different assumptions baked into the same functions.

Consolidating two diverged copies means merging: understanding what each copy changed, deciding which version of each difference is correct, and writing the unified version. This is more work than writing the shared module from scratch would have been.

The consolidation cost grows monotonically with time. It is cheapest on day 1 (when the copies are identical) and most expensive when the team finally decides it cannot be deferred any longer.

The Better Approach

Write the web component before the first copy. This costs 30-60 minutes. The component reads configuration from an attribute and adjusts its behavior accordingly. The first domain page is a 15-line shell. The second domain page is also a 15-line shell. There are no copies.

The effort-to-correctness tradeoff is obvious in retrospect and non-obvious before you have experienced copy drift. The argument against the component is always "we can do that later when we know what the second domain needs." But the second domain always needs the same canvas engine as the first. The attribute configuration is always straightforward. The delay has no benefit.

What You Give Up

A web component requires understanding the Custom Elements API. For a team not already using web components, there is a learning curve: connectedCallback, observedAttributes, attributeChangedCallback. This is a legitimate cost, especially early in a project.

Alternatively, a shared ES module (not a custom element) achieves the same goal with less API surface: all domain pages import from canvas-engine.js and call initCanvas(container, config). No Custom Elements knowledge required.

Either way, the first hour of establishing the shared pattern eliminates months of potential drift.

When the Common Pattern Is Right

Copy-paste one page per variant when: the variants are genuinely independent with no shared logic (not just shared configuration), the project is a prototype that will be discarded if it does not succeed, or the team has a reliable mechanical process (enforced by tooling, not by convention) for propagating changes across copies. That last condition is rarely met in practice.