How Visual Page Builders Revolutionize Frontend Development with Logic Orchestration

From Visual Page Building

Since 2016, visual page‑building systems have proliferated, ranging from open‑source tools to internal platforms that generate thousands of activity pages each year. By encapsulating reusable components, these systems free front‑end developers from repetitive UI work and boost page production efficiency.

Pain Points

Existing components need new capabilities (UI changes or logic updates).

New business components must be developed.

Continuous demand pushes developers to maintain and extend a growing component library, yet the current visual‑building workflow has reached a productivity ceiling.

Solution

Visual page building splits a full page into reusable components. Developers create components, while product and operations configure them, forming a simple production pipeline that reduces communication overhead and lets non‑engineers participate.

Business components are reusable, avoiding duplicate development.

Product and operations can intervene in the page‑creation process, sharing workload with developers.

The next bottleneck shifts from page‑level to component‑level efficiency. By further decomposing components into UI and logic, non‑technical users can drag‑and‑drop logic blocks to compose workflows.

Example

A simple lottery activity illustrates the approach: the UI shows a prize pool and a draw button; the logic handles page load (querying the prize pool) and button clicks (checking login status, invoking the draw API, and highlighting the prize).

The UI is assembled from fine‑grained elements (text, images, sliders). Logic consists of API calls (e.g., navigation, login‑state queries) wrapped in semantic descriptors that non‑developers can connect in a flowchart.

Logic Is Core

Logic orchestration differs from service orchestration because front‑end scenarios are more diverse, involving both C‑end and back‑office modules and requiring tight UI integration.

The iMove library exemplifies a lightweight, customizable solution for varied business needs.

How Logic Executes

To run a composed logic graph, a "runtime" interprets the DSL (domain‑specific language) and executes the defined steps. The runtime follows a rule set (DSL) that maps graph nodes to actions.

Each logic component (or "meta‑component") is published with a semantic name and description. Users select components, connect them, and produce a complete workflow.

Exported graph JSON contains many irrelevant details (coordinates, labels). A converter transforms this graph into a concise DSL, which the runtime executes via its interpret method in contexts such as useEffect, click handlers, or scroll events.

Logic Component Production and Consumption

The production line now includes: component creation → component marketplace → page assembly, with logic orchestration adding finer granularity.

As the process matures, product responsibilities shift from developers to product managers and eventually to operations teams, reducing error rates in the production line.

Logic Orchestration Design

Three core parts form the orchestration stack: components (meta‑components), the orchestrator (compiler), and the runtime. The design question becomes how to implement each.

DSL

The DSL is based on a Directed Acyclic Graph (DAG). A DAG consists of vertices (nodes) and directed edges, guaranteeing no cycles and a clear execution flow from a start node to an end node. Components may have multiple outgoing edges (e.g., a login check).

Each vertex represents an instance of a logic component. Types include Start, End, and Custom. Custom components specify a function (either inline code or a registered name), a payload of configuration data, and a list of next node IDs.

Runtime

The runtime stores generated data in an internal context and uses a publish‑subscribe model to notify UI components. When the context updates, React state is set, triggering UI re‑rendering.

runtime.subscribe('context', (val) => {
  // handle data
  this.setState({ data });
});

The runtime is lightweight (under 10 KB) yet flexible, supporting sandboxed execution of each workflow instance, isolated component outputs, and optional inter‑component communication.

By defining clear lifecycle hooks, the runtime allows business logic to intervene at various stages without becoming tightly coupled to specific product shapes.

Conclusion

The visual page‑building platform, combined with a DAG‑based DSL and a minimal runtime, enables non‑technical users to participate in front‑end development, dramatically improving component reuse and overall production efficiency. Future articles will dive deeper into component design, orchestrator implementation, and UI integration.