Lowcode & Micro‑Frontend: Shaping the Next‑Gen Front‑End Framework

1. Lowcode

Lowcode is not new; it replaces hand‑coded programming with GUI and configuration, from SQL to Dreamweaver. Its recent rise is driven by mature front‑end tooling, developer shortage, and B‑side business demand. Unlike earlier tools, current platforms aim to solve ordinary users’ programming problems rather than just improve developer efficiency.

1.1 Domestic lowcode platforms

Popular platforms include Yiqixiu, Taobao Tianma (page‑template building), Alibaba Cloud Fengdie, Baidu Aisudap, which let operators configure pages without code, satisfying rapid site‑building needs when time or manpower is limited.

1.2 Can lowcode solve everything?

Lowcode improves efficiency for simple front‑end scenarios, but the key challenge is judging the appropriate use case and timing. Questions include who decides which platform to use, which business can be built on it, who builds the pages, and how to handle the 99%‑coverage problem.

Who decides the platform – R&D or product manager?

Who determines which business can use the platform?

Who actually builds the pages?

What to do when the platform only meets 99% of requirements?

Often a platform is chosen, a page configured, and then a requirement cannot be fulfilled, leading to abandonment. Even when custom components are supported, the efficiency gain may disappear.

1.3 Scenario example

When a new app needs a simple promotional page with a background image and download button, the platform can configure it. If the product manager later requests that the button opens the app instead of downloading when already installed, a decision must be made whether to develop a custom action or implement it outside the platform.

1.4 Serverless

Lowcode platforms also offer serverless functions, but the same questions of evaluation, usage, and handling unsupported cases arise.

2. What micro‑frontend solves

Micro‑frontend borrows the service‑oriented architecture from backend micro‑services. It aims to split large applications into independent parts, enabling agile development, deployment, and mitigating the risk that a bug in one business crashes the whole system.

2.1 Scenario example

Two teams—e‑commerce and video‑PC publishing—need to be merged into a single site where users can publish videos and attach products in one flow. As complexity grows, challenges appear: unified tech stack, coupled development/deployment, and runtime bugs affecting the whole system.

2.2 Why micro‑frontend

The rise of micro‑frontend reflects increasing front‑end complexity and the need for higher‑level application frameworks that address architecture concerns such as isolation and modularity.

3. Front‑end frameworks and engineering

3.1 Front‑end frameworks

Frameworks like jQuery, React, and Vue were created to solve view‑layer problems. Over time, engineering concerns (modularization, componentization, automation) have become integral to framework adoption.

3.2 What is front‑end engineering?

Engineering is a mindset to improve efficiency by reducing repetitive work. It includes modularization, componentization, standardization, and automation.

4. Next‑gen front‑end application framework

Using a highly engineered application framework to further advance componentization and reshape development practices is the envisioned next‑generation front‑end framework.

In other words, it should make solving componentization, automation, and standardization easier, enabling rapid creation of lowcode, procode, or micro‑frontend platforms.

5. What we are building

We extracted the architectural ideas of lowcode and micro‑frontend into a developer‑centric front‑end framework and built an internal lowcode platform on top of it.

The implementation consists of two parts:

Data‑driven front‑end application framework that organizes pages via JSON configuration.

Lowcode visual configuration platform that maps JSON to user‑friendly configuration items.

The underlying UI layer uses a mature framework; the upper layer turns page development into JSON configuration, allowing developers to focus on component development and page configuration.

Front‑end work thus splits into:

General component development.

Page configuration development.

In short, the framework lets developers organize pages through JSON.

5.1 Some framework details

5.1.1 Conventions

We defined naming conventions for component properties (e.g., data, children, label) to enable validation, testing, and pre‑compilation optimization, reducing the learning curve and promoting component reuse.

5.1.2 Solving custom development

Custom development is divided into custom components (deployable independently) and custom actions (publish‑subscribe style, centrally managed).

5.1.3 Faster backend interaction

Recommended data interaction flow: write an action (or use generic getData), component triggers action (init/click/scroll), data is fetched and mounted, component subscribes to data and updates.

5.2 Advantages

Following micro‑service principles, styles, custom components, and methods can be injected via third‑party npm or online links, improving modularity and isolation.

Page development becomes component development plus configuration, facilitating automation and standardization.

Component development follows a common, extensible specification, enhancing componentization.

JSON‑based automated testing, deployment, and hot‑updates further support engineering.

6. Vision

We aim to find a balance between lowcode platforms and traditional front‑end development, boosting efficiency while empowering lowcode growth.

Our goal is to incubate the next‑generation application framework that solves more architectural challenges encountered in development and engineering practice.