Why All Low‑Code Platforms Rely on Declarative Code: A Deep Technical Dive

What Is Low‑Code?

Low‑code is defined by the presence of visual editing; without a visual editor a product is not low‑code. Visual editing requires a declarative description of the UI, because declarative code describes the final result rather than the steps to achieve it.

Declarative vs. Imperative Code

Declarative code directly describes the desired output (e.g., <div style="background:red; height:50px">), while imperative code details how to draw it (e.g., Canvas API). The key differences are:

Declarative code can be reverse‑engineered from the rendered result.

Imperative code cannot be reverse‑engineered, making visual editing impossible.

Because low‑code must support visual editing, all low‑code platforms ultimately use declarative languages such as HTML+CSS, SQL, Kubernetes YAML, or NGINX config.

Advantages and Drawbacks of Declarative Languages

Easy to learn : Simple syntax describes results, allowing non‑engineers to create UI or queries.

Supports visual editing : Tools like FrontPage (HTML) or BI software (SQL) enable direct manipulation.

Optimizable : Browsers and databases can automatically improve performance (e.g., parallel execution).

Portable : Older declarative specifications remain runnable on newer runtimes.

Drawbacks include:

Domain‑specific : HTML+CSS only renders documents, SQL only queries data.

Limited flexibility : Complex logic often requires imperative code.

Debugging difficulty : Lack of tooling makes tracing errors hard.

Runtime dependence : Features depend on the environment (browser, DB engine), leading to compatibility and performance variance.

Front‑End Low‑Code Implementation

Most front‑end low‑code platforms wrap HTML+CSS in a higher‑level DSL. The open‑source project amis converts JSON into a custom React component library, which then renders the UI.

{
  "type": "page",
  "title": "页面标题",
  "body": {
    "type": "form",
    "title": "用户登录",
    "body": [{
      "type": "input-text",
      "name": "username",
      "label": "用户名"
    }]
  }
}

JSON is transformed into a React component tree, allowing the editor to modify JSON directly. JSON is chosen because:

Web‑based editors can easily manipulate JSON with JavaScript.

JSON supports bidirectional editing (read/write mapping).

YAML, by contrast, loses reference information when converted to JSON, making visual editing of YAML impractical.

Interaction Logic

Three common approaches:

Graphical programming : Attempts to represent code visually, but abstract concepts (loops, recursion) lack spatial form, leading to higher cognitive load.

Fixed interaction actions : Platforms predefine actions (e.g., dialog, request) that can be configured visually. Example configuration for a dialog:

{
  "label": "弹框",
  "type": "button",
  "actionType": "dialog",
  "dialog": {
    "title": "弹框",
    "body": "这是个简单的弹框。"
  }
}

Custom JavaScript : Allows full flexibility but loses visual editability; similar to legacy IDE code generators.

Back‑End Low‑Code Storage Solutions

Five major schemes are surveyed:

Direct relational DB : Generates DDL from visual model changes. Pros: high performance, direct external DB integration. Cons: requires DDL permissions, may lock tables, limited transactional DDL support.

Document‑oriented DB (e.g., MongoDB) : Stores each custom table as a collection; fields are mapped to internal IDs. Pros: simple implementation, good UX. Cons: no external DB integration, limited SQL‑like queries.

Row‑instead‑of‑column (meta‑table) pattern : Uses a wide table with many valueX columns and a separate metadata table to map logical fields to column indices (similar to WordPress wp_postmeta). Pros: no DDL, works on SaaS. Cons: poor query performance, limited SQL features, security risks due to shared rows.

Meta‑info + wide table : Pre‑allocates hundreds of generic columns and stores field definitions in a metadata table (as used by Force.com). Pros: avoids DDL, works with relational DBs. Cons: cannot support full SQL, data‑leak risk, complex indexing and uniqueness handling.

Single‑file storage : All data resides in a JSON/Excel‑like file processed on the front‑end. Pros: simple, low deployment cost. Cons: poor scalability, no row‑level permissions, no transaction support.

The author’s platform, 爱速搭 , implements schemes 1 and 2, choosing relational DB for enterprise integration and MongoDB‑style JSON fields for simple forms.

Back‑End Logic Execution

Two practical approaches are highlighted:

JavaScript custom code : Embedded JS engine (e.g., Rhino) executes user scripts, offering flexibility.

Simplified DSL : Expression language for rule evaluation (e.g., approval thresholds) that the engine parses and executes.

An additional “execution tree” model visualizes the flow of multiple API calls, similar to a BFF layer, but the author recommends using a full‑stack framework like Spring Boot for complex logic.

Workflow Engine

Low‑code platforms typically support BPMN‑style visual workflows. The engine stores the workflow as a directed graph (nodes and edges) and determines the next node based on the current state. The author’s platform implements its own engine to handle approval patterns, parallel execution, and edge cases such as missing approvers.

Future of Low‑Code Platforms

Two directions are identified:

Zero‑code (highly standardized) : Easy to use, low per‑customer cost, but limited flexibility; likely to dominate the market due to economies of scale.

Professional‑developer‑oriented (highly flexible) : Complex, higher cost, suitable for large enterprises; less prone to winner‑takes‑all dynamics.

The author believes zero‑code will grow faster, especially “online‑Excel” style products, while professional‑oriented platforms will remain niche but essential for complex domains.

Conclusion

Key takeaways:

All low‑code platforms are fundamentally declarative; visual editing is only possible with declarative specifications.

The strengths and weaknesses of low‑code stem from the nature of declarative languages.

Front‑end low‑code is relatively easy (HTML+CSS DSL); back‑end low‑code involves trade‑offs among several storage schemes.

Choosing a storage scheme determines the platform’s target market and technical constraints.

The author, Wu Duoyi, is a senior architect at Baidu Cloud with 14+ years of experience, creator of the open‑source amis framework and the low‑code platform 爱速搭 .