Reinventing Low‑Code: How Vision’s New Gems Engine Reduces Complexity and Boosts Flexibility

In recent years, the frontend field has seen a surge in low‑code solutions, and after several iterations the market is now crowded with many competing platforms. The next‑generation low‑code platform Vision and its core building engine Gems have entered this race. We should examine and design our low‑code platform from both business and technical perspectives. On the business side, the platform must cover a wide range of scenarios, from C‑side operation activity pages to B‑side management back‑ends. On the technical side, capabilities such as page editing, version management, permission control, preview publishing, and business logic are all packaged into a single platform, raising questions about how to organize and separate these functions. This article discusses Vision’s core upgrades, the birth of Gems, and typical visual‑building scenarios, offering solutions to the above problems.

Vision is a one‑stop universal operation platform for online education that has been refined for over two years, helping product operators efficiently build and publish activity pages while improving development efficiency and experience. It now supports three major online‑education businesses and 18 external departmental services.

During a year of development, Vision added features such as convenient A/B testing and out‑of‑the‑box online data perspective capabilities.

1. What Is the Problem?

Team members often wonder where to start adding new capabilities. The core value of Vision is visual building, but the system’s design does not clearly reflect this, and the boundaries of capabilities are vague.

Without clear abstractions, adding features like rendering protocol checks becomes difficult, requiring developers to read extensive code to find insertion points, and often needing changes in both front‑end and back‑end modules.

We need a design that makes Vision’s core capabilities explicit and keeps software complexity growth under control.

Other Team Demands

The B‑side (management back‑end) demand is growing, with many repetitive form‑heavy systems that are internally used and have lower performance requirements than C‑side pages. Existing low‑code solutions like XPage are limited to internal use.

Attempting to extend Vision to cover both C‑side and B‑side would lead to compromises; therefore, a dedicated platform for management back‑ends is preferable, while Vision’s core visual‑building engine can be shared.

2. New Thinking

We decompose Vision and focus on the boundaries of visual‑building capabilities, defining three independent core libraries: Renderer, Editor, and Material Library.

The core idea: pages are assembled from material pieces; the assembled result is a protocol description, and rendering interprets this description.

Renderer – parses and renders the protocol.

Editor – provides visual assembly of the protocol.

Material Library – supplies the assets needed for rendering.

These three libraries form the micro‑kernel of the visual‑building engine, named Gems.

3. Capability Expansion Under the New Architecture

Grid Layout

Grid layout solves horizontal arrangement of materials, common on PC pages. A grid container adds “slots” (holes) where components can be placed.

Renderer needs an extra field in the rendering protocol to indicate which slot a child belongs to.

Materials define how many slots a container has.

We abstract slots as a generic concept, applicable to tabs, tables, modals, etc.

Implementation in the editor uses an

EditableEnhancer

higher‑order component:

<code>const withSlots = (View) => {
  return function WithSlots({ instance, children, ...otherProps }) {
    const { slots } = instance;
    return (
      <View instance={instance} {...otherProps}>
        {slots(instance).map((slot) => (
          <SlotContainer>
            {children.filter((child) => slot === child.props.slot)}
          </SlotContainer>
        ))}
      </View>
    );
  };
};</code>

Material Data Linking

Previously, Vision used an event‑driven model for data linking (e.g., button click opens a modal). For complex form scenarios, a data‑driven approach is needed.

We introduce an Open Data Interface for materials, allowing runtime data to be accessed by other materials.

Implementation involves three modules:

Materials – define data interfaces.

Editor – configure data variables and UI.

Renderer – create runtime data objects, distribute data, and resolve variables.

Component Templates

Templates allow components to have default behavior when added to the canvas, such as a modal with a default footer (confirm/cancel buttons) while keeping the footer customizable.

Templates balance fine‑grained atomic components with high‑frequency building efficiency.

4. Results and Future Outlook

Gems has replaced Vision’s original core logic, adding grid layout, data linking, and other capabilities while keeping software complexity manageable.

Based on Gems, the team launched the Hulk system focused on management back‑end page building, now used in several internal systems, saving significant development effort.

Gems continues rapid iteration and will be opened to other teams and eventually open‑sourced.