Can Visual Page Builders Turn Front‑End Development into a Low‑Code Powerhouse?

1. From Visual Page Building

Since 2016, visual page‑building systems have proliferated, both open‑source and internal, to free front‑end engineers from repetitive markup work and increase page production efficiency. For example, Youku’s internal marketing activity builder generates over 2,000 pages annually, relying on a large library of reusable components that must be continuously maintained and expanded.

2. Pain Points

Two main issues limit further gains:

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

New business components must be developed from scratch.

Even with shared component libraries and standardized APIs, the current visual‑building workflow has reached a bottleneck, prompting the need for a new production model.

3. Proposed Solution

Visual page building already splits a page into reusable components, assigning component creation to developers and component configuration to product/operations. This yields two benefits:

Component reuse eliminates duplicate development.

Product/operations can intervene in the page‑creation process, reducing communication overhead and sharing workload.

To push efficiency further, the proposal suggests allowing non‑developers to participate in component production by decomposing each component into UI and logic layers.

UI Layer

The UI is assembled from fine‑grained elements such as text, images, sliders, etc.

Logic Layer

Logic handles API calls, data processing, and capability invocation. Common APIs (e.g., navigation, login‑state queries) are wrapped with semantic descriptions so that non‑technical users can drag‑and‑drop them into a flowchart, forming a complete business component.

4. Concrete Example – Simple Lottery Activity

A page needs a prize pool (five prizes displayed horizontally) and a lottery button. The required logic consists of two parts:

On page load (componentDidMount), fetch the prize pool.

On button click, check login status; if not logged in, show the login panel, otherwise call the lottery API and highlight the winning prize.

Both logic fragments are pre‑packaged as reusable components that can be dragged onto the flowchart and linked to the appropriate UI events.

5. Logic Is Core

Logic orchestration is the heart of the system. It is implemented as a lightweight library (iMove) that provides a flexible, customizable runtime for front‑end workflows. Unlike service‑side orchestration, front‑end orchestration must handle diverse UI scenarios, multiple user roles, and tight UI integration.

6. How Logic Executes

Execution requires two pieces: a DSL that describes the workflow and a Runtime that interprets the DSL. The DSL is based on a Directed Acyclic Graph (DAG), where each node represents a logic component and edges define execution order.

Raw graph JSON contains many unnecessary fields (coordinates, labels) that bloat size and obscure execution flow. A converter transforms this JSON into a concise DSL, which the runtime’s interpret method can execute in various contexts (e.g., useEffect, click handlers, scroll events).

Logic Component Definition

type

: Start | End |

Custom

func

: For Custom nodes, either a function body or a registered function name. payload: Configuration data supplied by the UI, passed to the function at runtime. next: One or more UUIDs of downstream nodes.

Unlike traditional flow‑based programming, value passing between nodes is omitted to keep the model understandable for non‑technical users.

7. Runtime Design

The runtime stores generated data in an internal context and uses a publish‑subscribe mechanism to notify UI components of changes:

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

The implementation is tiny (under 10 KB) yet provides sandboxed execution, isolated child contexts, lifecycle hooks for business intervention, and a component manager that registers and validates logic components during DSL execution.

8. Production Flow

Component production follows a pipeline: developers create components → components are published to a marketplace → product/operations select and configure components via drag‑and‑drop flowcharts → the runtime executes the resulting DAG. This fine‑grained pipeline reduces error rates and enables non‑developers to contribute safely.

9. Closing Thoughts

Multiple iterations of the logic‑orchestration platform were built, from an early iMove prototype to attempts at co‑building with external platforms, finally resulting in a self‑developed lightweight solution tailored to Youku’s needs. Future articles will dive deeper into component design, UI integration, and other front‑end specifics of the orchestration system.