How StackLiberate Works

A visual website builder should feel simple.

Choose a starting point. Change the content. Adjust the design. Publish the result.

The system beneath that experience cannot afford to be simplistic.

Visual editors operate at the intersection of several representations of the same website: the page currently visible in the editor, the project saved on the server, the version a user may restore later, the site being previewed, and the files eventually published or downloaded.

When those representations are allowed to evolve independently, they drift.

An edit may appear in the canvas but disappear after a reload. A restored version may not match its original preview. A downloaded site may behave differently from the site that was approved in the editor. Two closely timed saves may silently overwrite one another.

StackLiberate is designed around preventing that class of failure.

The product is a visual builder for static websites, but the architectural premise is broader:

A website should remain coherent throughout its entire lifecycle, and ownership should be a property of the system—not merely a download button.

Ownership begins with the artifact

Many website platforms describe ownership in contractual terms. StackLiberate also treats it as a technical requirement.

A completed StackLiberate project can be materialized as an independent website containing the HTML, CSS, JavaScript, images, fonts, and other assets required to run it. The published result is not intended to require the editor in order to continue operating.

That distinction influences decisions throughout the product.

If the exported site depends on an undocumented runtime controlled by the builder, the user does not fully possess the operational artifact. If a page can only be interpreted by the original editor, portability is limited. If moving the site elsewhere means rebuilding it, export exists in name more than in practice.

For StackLiberate, the independent website is not an afterthought created at the edge of the system. Exportability constrains how editing capabilities are introduced, how assets are handled, and how changes are represented from the beginning.

The canvas is not the database

The most tempting way to build a visual editor is to modify the page directly.

A user selects an element, the editor changes its DOM node, and the screen updates immediately. This works well for a demonstration. It becomes unreliable when the same change must survive reload, undo, version restoration, publishing, and export.

The document rendered inside the StackLiberate editor is therefore not treated as the authoritative project state.

It is a projection.

The canvas shows what the website should currently look like, but the visible DOM is not trusted as the sole record of how the project reached that state. Instead, meaningful edits are represented as structured operations against known parts of the website.

Conceptually, the flow is:

User action
    ↓
Typed edit operation
    ↓
Validated project state
    ├── Editor preview
    ├── Reload
    ├── Version restore
    ├── Published website
    └── Portable export

This separation matters because rendered HTML is optimized for presentation, not for preserving editing intent.

Two pages may look identical while representing different operations. A heading changed by the user is not equivalent to an arbitrary fragment of HTML inserted into the page. Reordering a section is not the same operation as replacing the entire document. Updating a link should not require treating unrelated content as modified.

By retaining that distinction, the system can reason about changes more precisely.

Stable identity before mutation

Structured operations are only useful when they target stable entities.

Position alone is not a reliable identity. “The third paragraph in the second section” may refer to a different element after a section is reordered or a repeater item is inserted.

StackLiberate assigns canonical identity to declared editable surfaces. Text fields, links, images, sections, pages, and repeatable items can be addressed without depending exclusively on their temporary position in the rendered tree.

This allows an operation to express intent:

• Change this declared text surface.
• Update this link destination.
• Replace this image reference.
• Move this identified section.
• Duplicate this repeatable item.
• Hide this specific section.

The implementation is more disciplined than transmitting arbitrary page mutations, but the result is easier to reason about.

Stable identity supports replay. It supports targeted validation. It makes undo more precise. It also makes failures more visible: when a target no longer exists or its declared capability has changed, the system can reject the operation rather than applying it somewhere that merely looks similar.

Templates declare what they can preserve

A visual editor can easily display more controls than it can support honestly.

A style picker may modify the current canvas while producing a change that cannot survive export. A structural control may work for one template but corrupt another. A generic inspector may assume that two visually similar components share the same underlying contract.

StackLiberate avoids treating editability as an inference based only on appearance.

Templates and section recipes declare their supported capabilities. The editor uses those declarations to determine which actions it may safely offer.

This creates an important invariant:

The interface should not offer an edit unless the system knows how to persist, replay, restore, and export it.

That does not mean every part of every template must be editable. It means supported editing should be explicit.

A narrower capability that remains correct across the full lifecycle is more valuable than a broad control that only works in the current browser session.

This is what we mean by honest editability.

Changes are operations, not snapshots of accidents

StackLiberate uses a patch-based editing model.

A patch represents a bounded change to project state. Different operations carry different data and validation rules because changing text is not the same as moving a section, and moving a section is not the same as modifying page metadata.

Operations are typed, validated, and designed to be reversible where the product promises reversal.

This allows the system to preserve intent without replacing the entire project on every interaction. It also provides clearer boundaries for autosave, history, and server-side validation.

The objective is not to create the largest possible event system. The objective is to ensure that each accepted change has an understandable meaning and can move through the lifecycle without being reinterpreted differently by each subsystem.

One project state, several projections

Preview, reload, restore, publishing, and export are different experiences, but they should not be different implementations of the website.

StackLiberate derives them from the same persisted project model and the same accepted operations.

This does not mean every projection is byte-for-byte identical. An editor preview may include selection overlays and communication machinery that must never appear in a published site. A downloadable project may organize assets differently from the live preview environment.

The underlying authored result, however, should remain consistent.

A hidden section should remain hidden after reload and should not unexpectedly reappear in the ZIP. A moved section should preserve its new position in preview, restore, and export. A replaced image should resolve to the same intended asset. A restored checkpoint should reconstruct the corresponding authored state rather than approximating it from the current DOM.

Keeping these projections aligned is a continuing engineering constraint, not a one-time export feature.

Revisions prevent silent overwrites

Saving introduces another class of problems.

Requests can complete out of order. A browser can retry. A slow response may arrive after a newer operation. Two tabs may hold different understandings of the current project. A rapid sequence of actions can produce overlapping writes.

StackLiberate uses explicit project revisions and optimistic concurrency controls to detect stale writes.

A change is accepted against an expected revision. If the authoritative state has advanced, the system does not quietly pretend that both writers modified the same version.

This pattern is commonly described as compare-and-swap, or CAS.

The important user-facing property is simpler: newer work should not be silently replaced by a request created from older state.

Checkpoints also carry identity and verification information so that version history refers to concrete project states. Restore is treated as a state transition with revision semantics, not as an informal copy operation.

No concurrency model eliminates every possible failure. The goal is to make conflicts explicit and recoverable rather than invisible.

The editor and the website are isolated

The website being edited runs inside an isolated iframe. That boundary allows templates to render as websites while keeping the application interface, authentication context, and editing controls outside the page itself.

Communication across that boundary occurs through a defined bridge protocol.

The bridge does not make the iframe authoritative. It reports selections, requests supported operations, and receives instructions necessary to render the current project state.

Messages crossing the boundary are treated as untrusted input.

The backend independently verifies important conditions before accepting persistent changes, including project ownership, revision expectations, declared capabilities, and content safety constraints. Client-side checks improve the experience, but they are not the final authorization boundary.

The same principle applies to exported output: machinery required only by the editor should not leak into the autonomous website.

Isolation is useful only when the boundary remains clear.

Export is a materialization process

Exporting a website is not equivalent to saving the current iframe contents.

The editor contains temporary state and runtime behavior that should never become part of the user’s site. The current DOM may also reflect transient UI conditions, loading states, or editing instrumentation.

StackLiberate instead materializes the project from its canonical authored state.

During this process, the system applies the accepted operations, resolves assets, preserves supported interactions, removes editor-only behavior, and produces the files required by the independent website.

The export pipeline is designed to be deterministic: given the same template, project state, and asset set, it should produce the same authored result.

Determinism makes failures reproducible. It makes parity testable. It also makes ownership more meaningful because the exported project is derived from an explicit state rather than captured from an opaque browser moment.

Failure is part of the design

Users do not interact with software in perfectly spaced sequences.

They double-click. They change pages quickly. They refresh during a save. They navigate backward. Networks pause and resume. Tabs remain open. Requests arrive late. Browsers terminate.

A system that only works when every action completes in ideal order is not reliable.

StackLiberate therefore treats rapid interaction and partial failure as normal design conditions. Depending on the operation, this means revision checks, transaction boundaries, idempotent behavior, guarded state transitions, deterministic replay, or failing closed when the system cannot prove that a change is safe.

Failing closed does not mean displaying an error for every unusual condition. It means refusing to invent success.

When an operation cannot be applied to the intended target, when its revision is stale, or when a capability is not declared, preserving the existing known state is safer than silently producing a new unknown one.

Deliberate constraints

StackLiberate is not designed to be every kind of website platform.

Its focus is professional static websites: sites that benefit from visual editing, high-quality starting points, straightforward publishing, and the ability to leave the platform with a usable result.

That focus permits stronger guarantees.

A system that supports arbitrary server-side applications, unrestricted third-party code, collaborative document editing, ecommerce transactions, and every possible content model would require a different architecture and a different risk profile.

StackLiberate chooses controlled templates, declared capabilities, bounded operations, and portable outputs.

The constraints are not incidental limitations around the product. They help define the product.

The trade-offs we accept

Honest editability is intentionally bounded

StackLiberate is not a freeform design canvas where every object can be dragged to any coordinate or transformed without limits. It is a template-first website builder.

That means users receive substantial control over declared content, styles, images, sections, pages, navigation, and repeatable structures, but only where the template and editor can preserve those changes reliably.

This is a real constraint. A completely unrestricted canvas can offer more immediate creative freedom. It also makes responsive behavior, accessibility, template coherence, restore, and portable export significantly harder to guarantee.

StackLiberate chooses bounded flexibility over controls that work only under ideal conditions. We expand those boundaries through additional templates, section variants, style capabilities, and explicitly supported operations—not by presenting arbitrary mutation as reliable editing.

The objective is not to prevent customization. It is to ensure that customization remains valid after reload, across screen sizes, through version history, and outside StackLiberate.

Parity does not mean byte-for-byte identity

The editor preview and the exported website are not expected to be byte-for-byte identical.

The iframe contains editor-specific instrumentation: selection handling, communication hooks, temporary state, and other machinery that must not appear in the user’s independent website. Asset paths and build output may also be represented differently across environments.

The parity contract applies to the authored result:

• content;
• structure;
• section order and visibility;
• styles;
• assets;
• navigation;
• and supported interactive behavior.

Those properties should remain consistent across preview, reload, restore, publishing, and export, even when the surrounding runtime and generated bytes differ.

Maintaining that contract does require continuous work. New editing capabilities must be supported by persistence, replay, restoration, and export—not merely made visible in the canvas. StackLiberate uses shared operations, deterministic materialization, capability checks, and parity tests to reduce the risk of divergence.

This does not make regressions impossible. It makes parity an explicit, testable product invariant rather than an assumption.

Simple on the surface, disciplined underneath

Most users should never need to think about canonical identity, patch replay, concurrency control, materialization, or iframe isolation.

They should select a website, edit it, publish it, and own the result.

The engineering exists to make that simple experience truthful.

When StackLiberate says that a website is portable, the export pipeline should support that statement. When the editor offers an action, the state model should be capable of preserving it. When a version is restored, the result should correspond to a known checkpoint. When two writes conflict, the system should not silently discard one.

A visual builder is ultimately a state-management system with a design interface attached to it.

We are building StackLiberate so that the design interface feels approachable while the state beneath it remains explicit, verifiable, and portable.

That is how visual editing and real ownership can coexist.